Software Testing

Software testing is a process of verifying and validating the software application. The application should meet the business requirements and mainly focused on three categories.

Software testing is a process of verifying and validating the software application. The application should meet the business requirements and mainly focused on three categories.

1. Verification
2. Validation
3. Defects

Verification: It’s a process to make sure that the software meets the technical Specifications.
Validation: It’s a process to make sure that the software meets the Business Requirements.
Defect: It’s a valiance between the Expected Result and the Actual Result.

Manual Testing:
A tester conducts any test on application without using any testing tool; it’s called manual testing.

Automation Testing:
A Tester conducts any testing on application build using any test script. i.e. A software is going to test another software. It’s called Automation testing.

Software Quality:
The software satisfies quality when it meets the Customer Requirement / Customer Satisfaction. Meeting Customer Requirement refers to the proper output and Customer Expectation refers to the good interface, user friendly and good functionality.

Software Quality Assurance:
It’s one of the concepts followed by the companies to test the quality of software. This team will monitor and measure the quality and the performance of the development process.

Software Development Methodologies:
It’s a framework that is used to organize, plan and monitor the process of developing the software or system.

The below are the common methodologies used for the Software Development.

1. Waterfall Methodology
2. Spiral Methodology
3. Prototyping Methodology
4. Rapid Application Development Methodology
5. Agile MethodologySoftware Development Life Cycle / Life Cycle Development:
It’s a process used by the software industry to design, develop and test high quality software.

The below stages are involved in software development Life Cycle:

1. Requirement gathering
2. Analysis
3. Design
4. Coding
5. Testing
6. MaintenanceRequirement gathering:
In this stage, Business Analyst will gather the Business Requirement Document (BRD) from the Client / Customer and prepare the System Requirement Specification (SRS) document. The SRS contains the Software, Hardware and Functional requirements of the software.

Analysis:
In Analysis Phase, the Development team will sit together and discuss how the development going to be done and which teams are going to taking care of each modules etc. Design Architect, Development Project Manager, QA project Manager and Team leads will involve in this meeting and will finalize software development plan.

Design:
In Design Phase, the Design Architect will create two types of documents. High Level Design Document (HLD) and Low Level Design Document (LLD). The HLD consists of the main modules and it covers the sub modules which is in LLD. LLD consists of the sub modules along with Prototypes, Data flow diagrams etc.

Coding:
In Coding Phase, the developers will write the code based on the SRS and the Prototype.

Testing:
In testing phase, Test Lead will prepare a test plan based on the SRS. Tester will analyze the SRS and will discuss with corresponding resources like BA / Team Lead / Project Lead / Peers If there are any questions. Then tester will prepare the test cases based on the SRS and test plan. They will execute the test cases when the code is released to QA environment. If any test cases fail, the testers will open a Bug ticket and assign it to the corresponding developer, and tester will retest the defect when it’s fixed. Testers will conduct Regression testing and in some cases User Acceptance Testing (UAT). When the UAT is done, the code will be deployed to Production environment.

Maintenance:
Once a system is deployed to Production, it’s in service and during this time the system and its operational environment is changed.

V Model Testing:

Refinement Form of V-Model:

V model is used in small and medium companies and uses a separate testing team for functional and system testing.

Reviews during Analysis:
In Analysis stage, Business Analyst review and prepare BRS & SRS documents. After completion of document preparation, they conduct reviews on the documents for completeness & correctness.

This review focuses on below factors:

1. Are they complete?
2. Do they meet right requirements of customer /client?
3. Are they achievable w.r.t technology?
4. Are they reasonable w.r.t time & cost?
5. Are they testable?Reviews during Design:
In Design phase, the designers will start logical design of application in terms of External & Internal design (HLD’s & LLD’s). In this stage, they review the completeness & correctness of designed documents.

This review focuses on following factors:

1. Are they understandable?

2. Are they met with right requirements of customer / client?

3. Are they complete?4. Does it handle errors?During Unit Testing:
In Unit Testing, the developers will start coding the logical design to construct the software. During this coding stage, programmers will also do Unit Testing through a set of White box testing techniques.White box Testing:
Below are the techniques used in white box testing.
1. Execution Testing
Basic path coverage – Execution of all possible blocks in a program – Termination of loop statements programming technique– less number of memory cycles & CPU cycles.2. Operation Testing – Running the application on customer’s platforms.3. Mutation Testing
It’s a testing to change the program. Developers will do the changes in program to estimate the test coverage on it. It’s a process to decide whether the test coverage is true or false.4. Integration Testing
It’s a testing to combine one or more modules and test those modules together. Below are the approaches are involved in integration testing.

a) Top-Down Approach

In this approach, the sub modules will be tested after the main modules.

b) Bottom-Up Approach

In this approach, sub modules will be tested first without testing the main module first.

c) Sandwich or Hybrid Approach

Here, the testing is conducted using both top-down and bottom-up approaches.

Build: It’s a final integration of the modules which is in an executable form.

FUNCTIONAL & SYSTEM TESTING

After integration of modules, testers should conduct functional & system testing through Black box testing techniques. These techniques are classified into four categories.

1. Usability Testing
2. Functional Testing
3. Performance Testing
4. Security Testing

  • In Usability testing, testing team validates user-friendliness of the application.
  • In Functional testing, testing team validates the functionality of the application.
  • In Performance testing, testing team measures speed of processing
  • In Security testing, testing team validates security of the application to ensure there are no security vulnerabilities.

1) Usability Testing
In general, it’s conducted while doing test execution. While testing, tester validates the user-friendliness of the application. Testing team conducts two types of usability tests:
a) User Interface Test

  • Easy of use (Understandable UI)
  • Look & Feel (Intuitiveness)
  • Speed (Fewer steps to complete the test, easy & short navigation)

b) Manual Support Test

  • Context sensitiveness of user manuals
  • It’s done at the end of all testing & before productive release

2) Functional Testing
It’s a major part of black box testing. Tester concentrates on “meet customer requirements” when testing.

a) Functional / Requirement Testing
While testing, tester validates correctness of every functionality in terms of below coverages.

  • Behavioral coverage (changes in object properties)
  • Input domain coverage (size & type of every input & output object)
  • Service levels coverage (order of functionalities)
  • Calculations coverage (correctness of output)
  • Error handling coverage (ensuring all errors are handled by application)
  • Back-end coverage (impact of front-end operation on back-end tables and contents)

b) Input Domain Testing
Here, test engineers maintain special structures to define size & type of input object.

c) Recovery Testing
It is also called as Reliability testing. While testing, the testing team validates whether the application is changing from abnormal state to normal state or not.

d) Compatibility Testing
It is also known as portability testing. While testing, the testing team validates whether the application build runs on customer expected platforms or not. Also, the testing team tests backward compatibility at minimum.

  • Forward compatibility -> application is ready to run but Operating system is not supporting.
  • Backward compatibility -> Operating system is supporting, but the application has some internal coding problems to run on Operating system

e) Configuration Testing
It is also known as hardware compatibility testing. While testing, the testing team validates whether application build supports different hardware devices or not.

f) Installation Testing
During this test, the testing team validates whether application can be installed successfully in customer’s environment. Testing team observes below factors, when testing.

  • Easy Interface
  • Amount of disk occupied after the installation

g) Sanitation / Garbage Testing
During this test, the testing team tries to find extra features in application build w.r.t customer requirements.

h) Re-testing
Test the application with multiple test data to validate a function.

i) Regression Testing
After fixing the defect, the test engineer will test the entire build to make sure that it will not affect any other modules.

DEFECTS

During testing, the testing team reports defects to developers in terms of below categories:

1. Mismatches between expected & actual results
2. Missing functionality
3. Extra functionality that is not essential w.r.t customer requirement

TESTING DOCUMENTS


Above figure shows the different levels of documents prepared for testing an application.

Test Strategy:
This document is developed by Quality Analyst or Project Manager Category people, and it defines testing approaches.

Components:

  1. Scope & Objective: Introduction and purpose of testing.
  2. Test Deliverables: testing documents to be prepared (Required documents)
  3. Communication & Status reporting: Communication is required between testing team & developing team during test execution
  4. Test Approach: It’s a mapping between development stages and testing Issue.
  5. Automation & Testing Tools: Proper reasoning to use automation tools.
  6. Change & Configuration Management: handle change request while testing
  7. Roles & Responsibilities: Team members’ names and their responsibilities
  8. Risks & Mitigation: Reduce the impact of the risk
  9. Training Plan: Required for testing team before starts testing.

TESTING PROCESS

st7.png

Test Planning:
It’s a road map of entire testing activities like what, who, when & how to test the application. This document prepared by Test Lead and below are the order to prepare the test plan.

Prepare Test Plan:
After finalizing the test team formation and risk analysis, the author should concentrate on preparing the test plan document in IEEE format. Below is the test plan template.

Review Test Plan:
Test plan author conducts the review of completion and correctness of the test plan document. In this review. The below coverage analysis are included by Test plan author.

  1. BRS based coverage (What to test? Review)
  2. Risks based coverage (When & Who to test? Review)
  3. TRM based coverage (How to test? Review)

Test Designing:
After completion of Test Planning, the tester will prepare the test cases based on the test modules.

Test Case Format:
Test engineers write Test Cases in IEEE format.

1. TC_ ID: Unique no or name
2. TC_Open Date: The date of creating test case.
3. Module: The module which is going to be tested
4. Functionality: The functionality in the Module / Function / Feature
5. Test Case Description: Description about the test case
6. Test Case Procedure: Steps to test
7. Input Data: What input data are going to be used?
8. Test Type: Positive / Negative
9. Expected Result: The expected result
10. Actual Result: The result after executing the test cases
11. Status: If the test case is Pass or Fail
12. Comments: Comments for the passed/ failed test cases, If needed
13. TC_Prepared by : Tester’s Name
14. Developer Name: Developer’s Name
15. TC_Close Date: Date of closing the test case.
16. Defect Id: Note the defect id for the failed test cases
17. Defect Status: Status for the corresponding defectTest Reporting:
Test Engineer report the defects to developers through IEEE format. (Defect report template may differ depending upon the company standards).

1. Defect ID: Unique No or Name
2. Date of Initialization : Defect Open Date
3. TC_Id : Add the test case id to match the defect
4. Module: Mention the module which is going to test
5. Bug Status: Status for the defect (New/ Open /Fixed /Reopened /NA / Build Error /Deferred /Closed)
6. Severity: Seriousness of defect w.r.t functionality (Major / minor / Trivial)
7. Priority: Importance of the defect w.r.t customers (high / medium / low)
8. Bug Description: Summary of the defect
9. Reported by: Name of Test Engineer
10. Assign to: Name of the responsible developer
11. Developer Comments : Comments for the defects, if needed
12. Snapshots: Add the snapshots, if needed
13. Closed Date: Closed date.Test Closure:
After completing the testing process, the test lead conducts a review to ensure the completeness & correctness of testing. In this review, test lead focuses on following aspects of testing:
i) Coverage Analysis

a) BR based coverage
b) Use Cases based coverage
c) Data model based coverage
d) User Interface based coverage
e) TRM (Test Responsibility Matrix) based coverageii) Bug density
Find the bug density like percentage (%) of defects in overall modules.

iii) Analysis of deferred bugs
Analyze whether the deferred bugs are deferrable or not. Finally, testing team concentrates on high bug density modules.

User Acceptance Testing (UAT)
It’s a final phase of testing and there are two approaches to conduct UA testing.

1. Alpha (α) test (It’s conducted with in organization, by an independent testing team)
2. Beta (β) test (It’s conducted by customers at their own site)Sign Off:
After the completion of User Acceptance testing & their modifications, test lead creates final test summary report. This final test summary report consists of below documents:

  1. Test Strategy / Methodology (TRM)
  2. System Test Plan
  3. Requirement Traceability Matrix (RTM)
  4. Automated Test Scripts
  5. Bugs Summary Reports

Summary:
Software testing is an important process in IT industry. Software testers should follow above testing processes, so they can deliver the effective and defect free products to the end users.

About MST

At MST Solutions our cornerstone is to adapt, engage and create solutions which guarantee the success of our clients. The talent of our team and experiences in varied business verticals gives us an advantage over other competitors.

Recent Articles

Work with us.

Our people aren’t just employees, they are key to the success of our business. We recognize the strengths of each individual and allow them time and resources to further develop those skills, crafting a culture of leaders who are passionate about where they are going within our organization.