This Presentation is basically on the steps before any testing phases starts. The Slides have brief's regarding BRS, SRS, TSS, DTPS and few best practices.

1. TC’S CREATION AND
REVIEW
-Nikhil S.

2. Topic’s Covered -
■ Business Requirement (BR).
■ Software Requirement (SR)/User Story.
■ Test Scenarios (TSS)
■ DetailedTest Plan(DTPS)
■ Document Review Best Practices.

3. BUSINESS
REQUIREMENT'S
Brief Explained

4. BRTID-BIT:

5. What usually
it contains -

6. SOFTWARE
REQUIREMENT/USER
STORIES
Brief Explained

7. SRSTID-BIT:

8. Contents of SRS
■ Introduction
– Purpose:Set the expectations for the outcome of the product.
– Intended Audience:Who is the software for?Who is the end-user?Will the software be used internally at a company or
externally?
– IntendedUse:What is the software for?What problem is it solving?
– Scope: Explain the scope of the software.What are the main goals and objectives? How do they relate to the company’s
goals?
– Definitions and Acronyms: Provide an overview of any definitions the reader should understand before reading on.
■ Overall Description: Describe what you are building and for who.
– User Needs: Explain the user needs for this software.
– Assumptions and Dependencies:What assumptions are you making that could cause an error in your approach? Is the
project reliant on any other factors that could affect the development of the software?
■ System Features and Requirements
– Functional Requirements:Take time to define the functional requirements that are essential for the software to build.
– External Interface Requirements: Are there any UX andUI requirements that you must keep in mind as you build?
– System Features:What features are required for the software to even work.
– Nonfunctional Requirements:Are there any non-functional requirements that you need to address (i.e. budget, team,
etc.)

9. User StoryTID-BIT:

10. Some Example:
■ As a teacher, I want to organize my lesson plans by topic and age group, so that I can
handily refer to them in the future if needed..
■ As a writer, I can hide all menus and buttons, so that no distractions will remain on the
screen.
■ As a marketer, I can find and browse through successful campaigns so that I can gain
inspiration for my own concepts and endeavours.

11. TEST SCENARIO’S(TSS)
Brief Explained

12. Test Scenario’sTID-BIT:
A TEST SCENARIO is defined as any
functionality that can be tested. It is also
calledTest Condition orTest Possibility.
As a tester, you should put yourself in the
end user’s shoes and figure out the real-
world scenarios.

13. Why createTest Scenarios?
Test Scenarios are created for the following reasons -
■ CreatingTest Scenarios ensures completeTest Coverage.
■ Test Scenarios can be approved by various stakeholders like Business Analyst,
Developers, Customers to ensure the Application UnderTest is thoroughly tested. It
ensures that the software is working for the most common use cases.
■ They serve as a quick tool to determine the testing work effort and accordingly create
a proposal for the client or organize the workforce.
■ They help determine the most important end-to-end transactions or the real use of
the software applications.
■ For studying the end-to-end functioning of the program,Test Scenario is critical.

14. DTPS
Brief Explained

15. DetailedTest Plan
■ Test Plan is a dynamic
document.The success
of a testing project
depends upon a well-
writtenTest Plan
document that is
current at all times.Test
Plan is more or less like
a blueprint of how the
testing activity is going
to take place in a
project.

16. DOCUMENT REVIEW
BEST PRACTICES
Brief Explained

17. Best Practices: