Doc2Test Guardian

Problem Statement Software testing is an essential part of software development, but creating test cases from requirement documents is often slow, repetitive, and difficult. QA engineers and testers must read Software Requirement Specifications (SRS), Product Requirement Documents (PRD), user stories, or feature descriptions and manually identify test scenarios, input validations, expected results, boundary conditions, and error cases. This manual process creates several problems: It takes a lot of time to analyze long documents. Important positive, negative, and edge-case scenarios can be missed. Different testers may write test cases in different formats. Beginners may find it difficult to convert requirements into proper test cases. Incomplete or unclear requirements can lead to incomplete testing. Small teams may not have enough time or QA resources to prepare detailed test documentation. Repetitive test-case writing delays the testing phase and software release. For example, a simple login requirement may state that users should sign in using an email address and password. A tester must still manually create cases for valid login, wrong password, invalid email format, empty fields, password length, error messages, and other possible conditions. If these cases are missed, users may face issues in the final product. Therefore, there is a need for a smart system that can read requirement documents and automatically generate structured, useful, and complete test cases. Proposed Solution Doc2Test is an AI-powered web application that converts software requirement documents into structured test cases. It helps QA engineers, developers, students, and project teams reduce the effort required to analyze requirements and create testing scenarios. The user provides a requirement document, feature description, user story, or plain-text input. Doc2Test analyzes the text and identifies important information such as user actions, functional requirements, input fields, validations, business rules, expected outputs, and error conditions. Based on this analysis, the system generates organized test cases that can be reviewed and improved by the user. The application can generate different types of test cases, including: Positive test cases for expected successful behavior. Negative test cases for invalid inputs and incorrect actions. Validation test cases for required fields and format checks. Boundary test cases for minimum and maximum allowed values. Edge-case scenarios for unusual or unexpected conditions. Each generated test case can include fields such as test-case ID, test title, preconditions, test steps, test data, expected result, priority, and test type. This structure makes the output easier to understand, review, share, and use in the software-testing process.