Software Testing and Test Cases

Agenda1.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

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

Bugs Found at different stages of SDLC

Bug Cost at different stages of SDLC

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!!

Role of Tester in Agile

Developer vs Tester Thinking

3. Different Types of Software Testing (Majorly)

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

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

5. Sanity vs Smoke Testing

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

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)

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)

Bugs Stats from May Month

Average days where issue was unresolved=11Average number of days taken to resolve an issue=4

Average response time taken to response on the issue(1st comment)-~10 days

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.

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) Then 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.

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

Questions