Software Testing Part-5-Types of software testing.

Test Case Design Techniques,Defect Management Process and Bug Life Cycle Status.

In this article lets see a couple of software testing techniques:
1)Adhoc Testing: This is a type of software testing which is performed without proper planning and documentation.
*This testing is carried out with the knowledge of the tester about the application and the tester tests randomly without following the specifications/requirements.

2)Monkey Testing:This is type of test in which the functionalities are tested randomly without any knowledge on the application and test cases.

3)Re-Testing:When a test fails and we determine the cause of the failure which could be a software fault or any other and if the fault is reported then we can expect a new version of the software that has the fault fixed.

*In simple words, Retesting is testing a specific bug after it is fixed.

*When retesting, it is important to ensure that the test is executed in exactly the same way as it was the first time, using the same inputs, data and environment.

4)Accessibility Testing : The aim of Accessibility Testing is to determine whether the software or application is accessible for disabled people or not.

Here, disability means deaf, color blind, mentally disabled, blind, old age and other disabled groups. Various checks are performed such as font size for visually disabled, color and contrast for color blindness, etc.

5)Input Domain Coverage(BVA,ECP):During this input domain testing, test engineers validate data provided to the application with respect to values and length.
This has 2 techniques
a)Equivalence class partition.
b)Boundary value analysis.

Example:
In a text box with field user name.
The requirements for the text box are:
a)It allows min 4 to max 8 charterers
b)It allows only lower case letters.

Based on the requirements we need to prepare the test data which have both positive and negative inputs.

6)Database Testing: In this testing,test engineers validates the data with respect to database.
Validates DML operations (Insert,update,delete)
SQL language: DDL,DML,DCL etc.,
We have seen more about this in the DBMS article series.

7)Error Handling Testing:This validates error messages thrown by the application when we provide invalid data.
*The error message should be clear and easy to understand by the user

8)Calculations/manipulations Coverage:This validates mathematical calculations.

9)Links Existence & Links Execution:
Links Existence : This checks if the links are placed in the appropriate location or not.
Links Execution: This checks if the link is navigating to appropriate page or not.
Types of links:
a)Internal Links
b)External Links
c)Broken Links.

10)Cookies & Sessions:Cookie is a temporary internet file which is created at client side when we open the website and these files contain user data.
Sessions are time slots which are allocated to the user at the server side.

11)End to end testing:This is a kind of testing where overall functionalities of the system including the data integration among all the modules is called end to end testing.

12)Exploratory testing:In this testing we explore the application and understanding the functionalities adding or modifying the existing test cases for better testing is called Exploratory testing.

13)Globalization testing or internationalization testing:In this we Check if the application has a provision of setting and changing languages date and time format and currency etc., if it is designed for global users, it is called Globalization testing.

14)Localization Testing:This Checks default languages currency date and time format etc., if it is designed for a particular locality of users is called Localization Testing.

15)Positive Testing:Testing conducted on the application in a positive approach to determine what system is supposed to do is called Positive Testing.
*This helps in checking if the customer requirements are justifying the application or not.

16)Negative Testing:Testing a software application with a negative perception to check what system is not supposed to do is called negative testing.

Note:

The above-mentioned Software Testing Types are just a part of testing. However, there is still a list of more than multiple testing techniques, but all testing types are not used in all types of projects.

Software Testing Life Cycle STLC:
STLC has the following phases as explained below.

• Phases are dependent on

1. Nature of the Software
2. Product
3. Time and resources allocated for the testing
4. The model of SDLC that is to be followed.

STLC phases:

1. Requirement Analysis
2. Test Planning
3. Test Designing
4. Test Execution
5. Defect reporting and Tracking
6. Test Closure

*STLC starts as soon as requirements are defined or SRD (Software Requirement Document) is shared by stakeholders.
*STLC provides a step-by-step process to ensure quality software.
*In each phase we need different inputs and we perform different activities and get the outputs.

1. Requirement Analysis: During this phase, test team studies and analyzes the requirements from a testing perspective.

*This phase helps to identify whether the requirements are testable or not.

*If any requirement is not testable, test team can communicate with various stakeholders (Client, Business Analyst, Technical Leads, System Architects etc) during this phase so that the mitigation strategy can be planned.

2. Test planning: In this phase test team plans the strategy and approach.
A document describing the scope,approach,resources and schedule of testing activities.
This step also involves Inputs like:
1)What to Test?
2)How to Test?
3)When to test?

*This step also involves activities like Identify the resources,team formation,test estimation,preparation of test plan,review on test plan,test plan sign-off.
Output will be:
Test Plan Document

A test plan contains the following list of details:
a)Objective
b)Features to be tested
c)Features not be tested
d)Test Approach
e)Entry and exit Criteria
f)Suspension and resumption
g)Test environment
h)Test deliverable’s & milestones
i)Schedules
J)Risk and Mitigation
K)Approvals

3.Test Designing :In this phase we develop the test cases based on scope and criteria’s.
This step also includes Inputs like:
1)Project plan
2)Functional requirements
3)Test plan
4)Design documents
5)Use cases
It has Activities like:
a)Preparation of test scenarios,
b)Test cases,
c)Reviews on test cases,
d)Tractability matrix
e)Test cases sign off
Output will be:
Test case document
Tractability Matrix

4.Test Execution :In this phase real-time validation of product and finding bugs is done.
This step also includes Inputs like:
1)Functional requirements
2)Test plan
3)Test Cases
4)Build from development team.
The following are the Activities involved in this phase:
a)Executing test cases
b)Preparation of test report/test log
c)Identifying defects
Output will be:
Status/test report

5.Defect reporting and Tracking: Defect tracking is an important process in software engineering as complex and business critical systems have hundreds of defects.
*One of the challenging factors is Managing, Evaluating and Prioritizing these defects.
*The number of defects gets multiplied over a period of time and to effectively manage them, defect tracking system is used to make the job easier.
This phase includes Inputs like:
1)Test cases
2)Test reports/test log
Also, Activities like
a)Preparation of Defect report
b)Reporting defects to developers
Output will be:
Defect Report

6.Test Closure/Sign Off :Once testing is completed, matrix, reports, results are documented.
The Inputs will be:
1.Test reports
2.Defect reports
Activities are:
a)Analyzing test report
b)Evaluating Exit Criteria.
Output will be:
Test Summary reports

What is a use case?
A use case is a list of actions or event steps, typically defining the interactions between a role and a system, to achieve a goal. The actor can be a human or other external system.

What is a test scenario?
The possible areas to be tested like what to test?

*This is a test procedure and are derived from use cases.

What is test case?
This is something that describes How to test and describes test steps,expected and actual results.
*Test case contain set of input values,execution precondition,expected results and executed condition,developed to cover certain test condition.

Test Case Design Techniques :
1)Boundary value analysis
2)Equivalence class partitioning (we have seen these in the previous article )

Decision table testing : This has actions and conditions columns.
*If condition is valid action will be passed else it will be failed and will be listed in decision table.
Example:

If an email id and password are valid then action is passed.
If an email id is valid and password is invalid then action is failed.

State Transition:

What is this all about?
Every time we do a action the state will be changed.

Testing an ATM machine this has 4 steps:
The procedure starts now

1. User will insert the card first. Later the system will wait for pin and user will enter the pin (state is changed from start to wait for pin)
2. In the 1st attempt to enter the pin, if pin is valid user will get access to account and if invalid, 2nd attempt and 3rd attempt to enter the valid pin will be provided by the system.
3. In the 2nd attempt if pin is valid then the user will get access to account if invalid 3rd attempt will be provided by the system.
4. In the 3rd attempt if the pin is valid user will get access to account, if invalid card will blocked.
   *Hence all the actions done by the system are called as states.
   *Based on actions states can be changed.

Use Case Testing: This is a part of requirement document it contains actor action and outcome.This can be used to write a test case.
Example:

Consider an ATM machine
Actor and system are interacting and performing actions.
A:Insert card
S: Validates card and ask for pin and validates the pin and allow access to account.
Extensions is the 3rd part of use case after actor and system.
Extension:
If the pin is not valid then?
S: Displays message and rejects the transaction.
If card is not valid then?
S: Displays message and rejects the card.
Pin invalid for 3 times then?
S: Cancels the transaction and exit.
So based on use case we can write the test cases.

Test Suite: This is a group of test cases which belong to the same category.
*We have a test plan document with which we create more number of test cases.
*We can divide Sanity test cases as one category and Regression as one and Functional as other.
Every same category of test cases comes under one test suite like:
1)Regression test suite
2)Sanity test suite
3)Functional test suite.
When we get a new built after fixing the issues what test suite we need to execute?
Regression.
When we get a new built what test suite we need to execute?
Sanity test suite
What next after sanity and regression test suits’s?
Functional test suite.
*We need to choose test suite based on test criteria.

Test Case Contents:
To prepare a test case we need the following details:
Test case ID:Every test case has a unique id called test case ID.
Test case title: Every test case has a title which explains/defines or gives an idea of the test case in single term.
Description:This is in detail explanation of the test case.
Pre condition: This specify the setup needed for a test case to be executed successfully.
Priority(p0,p1,p2,p3):Every test case has a priority and based on priority we will decide when to execute the test case.
*All sanity test cases comes under p0 that is high priority test cases
*p1 is regression test cases
*p2and p3 are the functional test cases.
Expected Result: The expected result of the test before executing the test.
Actual Result: The actual result of the test to be filled after executing the test. *The Actual and Expected results should be the same.
Test Data: Use of test data as an input for this test case. We can provide different data sets with exact values to be used as an input.
Status:Pass or Fail. Other statuses can be ‘Not Executed’ if testing is not performed and ‘Blocked’ if testing is blocked.
Remarks : Any comments on the test case or test execution.
Test Procedure:Step-by-step procedure to execute the test.

Characteristics of good test case
A good test case has certain Characteristics that are listed below:
1)Features of test cases must have a Unique.
2)Should be accurate and tests what it is intended to test.
3)It should be reusable.
4)It should be traceable to requirements and should be compliant to regulations.
5)It should be independent,clear,simple and understandable

Test Execution:
During this phase test team will carry out the testing based on the test plans and the test cases prepared.
*Also, bugs will be reported back to the development team for correction and retesting to be performed.

Defect Reporting:
Any mismatch in the functionality found in application is called Defect/bug/issue.
Defect reporting tools:
jira
bug jilla etc.,

Defect/Bug Report Contents:
While reporting the bug to developer, the Bug Report should contain the following information

1. Defect_ID : This is a Unique identification number for the defect.
2. Defect Description : This has the detailed description of the Defect including information about the module in which Defect was found.
3. Version: This will have the Version of the application in which defect was found.
4. Steps : A detailed steps along with screenshots with which the developer can reproduce the defects.
5. Date Raised :Date when the defect is raised
6. Reference:This is where in you provide the reference to the documents like : requirements, design, architecture or maybe even screenshots of the error to help understand the defect
7. Detected By :Name/ID of the tester who raised the defect
8. Status :Status of the defect , more on this later
9. Fixed by :Name/ID of the developer who fixed it
10. Date Closed:Date when the defect is closed
11. Severity: Which describes the impact of the defect on the application
12. Priority :Which is related to defect fixing urgency.

*Severity Priority could be High/Medium/Low based on the impact urgency at which the defect should be fixed respectively

Defect Management Process in Software Testing (Bug Report Template)

Defect management can be defined as a process of detecting bugs and fixing them. It is necessary to say that bugs occur constantly in the process of software development.

*Hence, every software development project requires a process that helps detect defects and fix them.

Defect management process is a step by step process as show below:

DISCOVER….>CATEGORIZATION…..>RESOLUTION….>VERIFICATION…….>CLOSURE……>REPORTING

1)Discovering :A defect is said to be discovered when it is brought to the attention of the developers and acknowledged (i.e., “Accepted”) to be valid one.
2)Categorization: Defect categorization help the software developers to prioritize their tasks.

*That means that this kind of priority helps the developers in fixing those defects first that are highly crucial.
*The defects are Categorization as Severity & Priority.
Severity: This described the seriousness of the defect.
*In software testing defect severity can be defined as the degree of impact a defect has on the development or operation of component application being testes.
Defect Severity can be categorized into 4 classes:
Critical: This defect indicated complete shit down of the process.
High: It is highly severe defect and collapse the system,however certain parts of the system remain functional.
Medium: It causes some undesirable behavior but the system functioning remains constant.
Low: It will not cause any major break down of the system.
Priority : This describes the importance of defect and the order in which the defect should be fixed.
Defect Priority can be categorized into 3 classes:
P1 High: The defect must be resolved as soon as possible as it effects the system severely and cannot be used until it is fixed.
P2 Medium: During the normal course of the development activitied defect should be resolved. It can wait until a new version is created.
P3 Low: The defect is an irritant but repair can be done once the more serious defect have been fixed.
Also, we have 4 types of classifications on Priority and Severity as explained below:
Low Priority and Low Severity : A spelling mistake in a page which is not frequently navigated by user.
Low Priority and High Severity: Application crashing.
High Priority and Low Severity:Slight change in logo color or spelling mistake in company name.
High Priority and High Severity:Issue with login functionality.

3)Resolution:Once the defects are accepted and categorized, we can follow the following steps to fix the defect.
1)Assignment
2)Schedule fixing
3)Fix the defect
4)Report the resolution
4)Verification:After the development team fix and report the defect, the testing team verifies the defects if they are actually resolved.
5)Closure: Once a defect has been resolved and verified, the defect status will be changed as closed. If not, a notification has to be sent to the development team to recheck the defect.

What is Defect Life Cycle?
Defect Life Cycle or Bug Life Cycle is the specific set of states that a Bug goes through from discovery to defect fixation.

Bug Life Cycle Status:
The number of states that a defect goes through varies from project to project. Below life cycle structure which covers all possible states.

0)New: When a new defect is logged and posted for the first time. It is assigned a status as NEW.
Also, the bug is reported however it not yet assigned to the developer.
1)Assigned: In this step the tester would post the bug and once the approval is given by the lead the bug is assigned to the developing team.The bud is in process to be fixed.
2)Open: The developer starts analyzing and works on the defect to be fixed and the bug status will be open.
3)Fixed: The bug status is changed to fixed once it is resolved and will be waiting for validation.
4)Pending testing: Once the defect is fixed the developer gives a particular code for retesting the code to the tester. Since the software testing remains pending from the testers end, the status assigned is “pending retest.”
5)Retest: Tester does the retesting of the code at this stage to check whether the defect is fixed by the developer or not and changes the status to “Re-test.”
6)Verified: The tester re-tests the bug after it get fixed by the developer. If there is no bug detected in the software, then the bug is fixed and the status assigned is “verified.”
7)Closed: If the bug is no longer exists then tester assigns the bug status as “Closed.”
8)Reopen: If the bug persists even after the developer has fixed the bug, the tester changes the status to “reopened”. Once again the bug goes through the life cycle.
9a)Duplicate: If the defect is repeated twice or the defect corresponds to the same concept of the bug, the status is changed to “duplicate.”
9b)Rejected: If the developer feels the defect is not a genuine defect then it changes the defect to “rejected.”
9c)Deferred: If the present bug is not of a prime priority and if it is expected to get fixed in the next release, then status “Deferred” is assigned to such bugs
9d)Not a bug:If it does not affect the functionality of the application then the status assigned to a bug is “Not a bug”.

That is all about Testing types in software testing and STLC phases and details on Bug life cycle.

This is end of Software Testing(Manual).

Thank you for referring the entire article series.