1. The document discusses the importance of testing in the software development lifecycle (SDLC) to improve quality and identify defects before deployment. Testing helps verify requirements are implemented correctly and that components integrate properly. 2. It explains why separate testers are needed to test software in a neutral, unbiased way. Testers have a "negative" approach to find bugs, which developers lack due to implementation pressures. 3. The document outlines different types of software testing like unit, integration, system and acceptance testing. It also describes testing techniques like boundary value analysis, equivalence partitioning and comparison testing.

1. Software Testing and Test Cases

2. Agenda
1.Why Testing is important in sdlc? 2.Why do we need Testers to test the product?
3.Different Types of Testing 4.Testing Techniques
5.Smoke vs Sanity Testing 6.Regression vs Retesting
7.Bug, Bug and more Bugs-Logs, test data, no. of users, type of users....
8.Test cases and Test Scenarios 9.Test Cases Execution Flow
10.Differentiating between Test Cases that are required and the ones that aren’t

3. 1. Why Testing is important in sdlc?
1. Testing in SDLC helps to prove that all the software requirements are always implemented correctly or not.
2. Testing helps in identifying defects and ensuring that testing are addressed before software deployment. If any
defect is discovered and fixed after deployment, then the correction cost will be much higher than the cost of fixing
it at earlier stages of development
3. Whenever several systems are developed in different components, different levels of testing help to verify proper
integration or interaction of all components to rest of the system.
4. Testing in SDLC means that testing always improves the quality of product and project.
5.Testing not only improves the quality of the product, but it also improves the company quality also

4. Bugs Found at different stages of SDLC

5. Bug Cost at different stages of SDLC

6. 2. Why do we need Testers to test the product?
1. Developer-How Can I make it? ... Tester-How Can I break it?
Testing needs a NEGATIVE approach, which a developer doesn’t have.
TESTING IS DESTRUCTIVE PROCESS : A CREATIVE DESTRUCTION
2. A software should be tested in a neutral way to have unbiased testing results. This can be done only by a third
person (not developer himself).
3. A developer is usually working under high pressures to implement requirements asap. Due which quality can be
compromised a lot many times. So, it’s better to have a separate tester.
4. Testing is not about just validating that system is performing what it is supposed to, but importantly it is also about
assuring that the system is not performing what it is not supposed to perform.
Because We don't need a Satisfied Customer, We need a Delighted customer.
5.If we’re perfect, there’d not be tester or QA and we know that nobody is perfect including Tester!!
Note:Testers pursue defects, not the people behind the defects!!

7. Role of Tester in Agile

8. Developer vs Tester Thinking

9. 3. Different Types of Software Testing (Majorly)

10. 4. Different Types of Software Testing Techniques (how to select test data/test
cases)
Graph Based Testing Methods:
Each and every application is build up of some objects. All such objects are identified and graph is
prepared. From this object graph each object relationship is identified and test cases written accordingly to
discover the errors.(Identification of features relationship and then gathering the test cases)
Error Guessing:
This is purely based on previous experience and judgment of tester. Error Guessing is the art of guessing
where errors can be hidden. For this technique there are no specific tools, writing the test cases that cover
all the application paths.
Boundary Value Analysis:
Many systems have tendency to fail on boundary. So testing boundry values of application is important.
Boundary Value Analysis (BVA) is a test Functional Testing technique where the extreme boundary values
are chosen. Boundary values include maximum, minimum, just inside/outside boundaries, typical values,
and error values. Values-Min – 1, Min, Min +1, Nom, Max -1, Max, Max +1

11. Equivalence Class Partitioning:
Equivalence partitioning is a black box testing method that divides the input domain of a program into
classes of data from which test cases can be derived.
(Ex-for a test data which can have values from 1 to 100 we test it for 1 one digit number, 1 two digit
number, 1 three digit number)
Comparison Testing:
Different independent versions of same software are used to compare to each other for testing in this
method

12. 5. Sanity vs Smoke Testing

14. Regression Testing Types (Decide Test Cases Execution based on Impact Areas)

16. 7.Bug Format
DESCRIPTION OF ISSUE
(Please describe the issue in detail along with screenshot or recorded session attachment)
PRIORITY
(High, Medium, Low)
FREQUENCY/LIKELIHOOD OF ENCOUNTERING/REPLICATION RATE
(Frequent, Occasional, Rare)/2/2 or ⅓)
STEPS TO REPLICATE
(Please describe how can the issue be replicated)
EXPECTED RESULT
(Please describe what was exactly expected)
ACTUAL RESULT
(Please describe what was observed)

17. Bugs…...
INTERFACE INVOLVED
(Interface(s) on which this issue can be replicated)
WHICH OTHER INTERFACES INVOLVED
(Interfaces which get affected by this bug)
SERVER / INSTANCE INFORMATION
(Which instance/server was the issue found on)
BROWSER/OS
(Which Browser-OS was the issue found on)
LOGS IF ANY
(Provide server/client side logs, exceptions/error info and stacktrace )
DATASET
(Data with which issue can be replicated along with user credentials,user type,number of users)

18. Bugs Stats from May Month
Average days where issue was
unresolved=11
Average number of days taken to resolve
an issue=4
Average response time taken to response
on the issue(1st comment)-~10 days

19. 8.Test cases vs Test Scenarios
Scenario-General description of a particular functionality/requirement
Test Cases-It's a interpretation of scenario with actual steps and data. These are written in detail.
Example: Gmail Login Functionality
Scenario:
Verify that login functionality is working.
Test cases:
a) Verify that user is able to login with valid credentials
b) Verify that login functionality does not break in case user enters Invalid credentials.

20. 9.Test Cases Execution Flow
Prioritization of test cases is required while executing test cases. The cases with higher priority should be
listed 1st and should be followed by test cases with lower priority. There should be a flow in which testing
will be conducted and test cases should reflect that flow.
Example: Test cases for Water Bottle
a) Test cases for bottles Ability to hold water, no leakage, properly concealed should be written first.
b) Then test cases for Shape and size should follow.c) Th
en ability to hold cold or hot water should be there.
d) Then Color, Brand and negative scenarios like testing on extreme temperatures should be listed.

21. 10.Differentiating between Test Cases that are required and the ones that aren’t
QA, BA and Dev teams should be in Sync
about the functionality. QA needs to make
sure effective test cases are written to cover
the functionality as per the specification
hence following should be followed:
TEST CASE WRITING COVERAGE:
Section A, Section D, Section E, Section F
Out OF SCOPE TEST CASES: Section C,
Section G

22. Questions