Software Development Life Cycle / Life Cycle Development
Stages involved in software project development
1) Information gathering; Customer requirement
2) Analysis; Customer requirement v/s Solutions
3) Design; Dividing the project into modules & coupling them
4) Coding; Physical construction of project
5) Testing
6) Maintenance
Information gathering stage:
In this stage, Business Analyst studies the requirement of the client /customer and they prepare Business Requirement Specification (BRS) documents.
Analysis:
In this stage, Sr. Analyst prepares Software Requirement Specification (S/w RS) document with respect to corresponding BRS document. This document consists of two sub-documents System Requirement Specification (SRS) & Functional Requirement Specification (FRS). SRS contain details about software & hardware requirement. FRS contains details about the functionality to be used in project.
Designing:
In designing phase, Designers creates two documents High Level Document (HLD) & Low Level Document (LLD). HLD consists of main modules of the project from root to leaf and multiple LLD’s. LLD consists of sub-modules of main module along with Data flow diagrams, ER-Diagrams, etc., are prepared by technical support people or designers called Internal designers.
Black box tester should have knowledge of customer requirement
Black box testing tests BRS & SRS
Testing external interfacing is Black box testing
Testing internal interfacing is White box testing
White box testing is done w.r.t design documents
1) Reviews during Analysis
In general, Software development process starts with Information Gathering & Analysis. In this stage Business Analyst category people are preparing BRS & S/w RS documents and after completion documents preparation, they conduct reviews on the documents for completeness & correctness. This review focuses on below factors:
1) Are they complete
2) Are they met with right requirements of client / customer
3) Are they achievable w.r.t technology
4) Are they reasonable w.r.t time & cost
5) Are they testable
2) Reviews during Design
After completion of Analysis phase & their reviews, our Project-level designers will start logical design of application in terms of External & Internal design (HLD’s & LLD’s). In this stage, they conduct reviews for completeness & correctness of designed documents. This review focuses on below factors:
1) Are they understandable
2) Are they met with right requirements of client / customer
3) Are they complete
4) Are they follow able
5) Does they handle errors
3) During Unit Testing
After completeness of Design & their reviews, software programmers will starts coding the logical design to physical construction of software. During these coding stage programmers is conducting Unit Testing through a set of White box testing techniques, Unit Testing also known as Module / Component / Program / Micro testing
White box Testing:
There are three possible White box testing techniques
1) Execution Testing
Basic path coverage – Execution of all possible blocks in a program
Loops coverage – Termination of loop statements
1) Are they understandable
2) Are they met with right requirements of client / customer
3) Are they complete
4) Are they follow able
5) Does they handle errors
3) During Unit Testing
After completeness of Design & their reviews, software programmers will starts coding the logical design to physical construction of software. During these coding stage programmers is conducting Unit Testing through a set of White box testing techniques, Unit Testing also known as Module / Component / Program / Micro testing
White box Testing:
There are three possible White box testing techniques
1) Execution Testing
Basic path coverage – Execution of all possible blocks in a program
Loops coverage – Termination of loop statements
Programmer technique coverage – less no of memory cycles & CPU cycles
2) Operation Testing – Running the application on Customer expected platforms
3) Mutation Testing
Mutation means that a change program. White box testers are performing the change in the program to estimate test coverage on that program. Mutation testing can decide whether the test coverage is correct or wrong
4) Integration Testing
After completion of dependent modules of development & testing, Programmers combine them to form a System. In this Integration, they are conducting Integration testing on the compiled modules w.r.t HLD.
There are three approaches to conduct Integration testing
a) Top-Down Approach
Top-Down Approach
In this approach, testing is conducted on Main module without conducting testing to some of sub-modules. From the above diagram, a Stub is a temporary program instead of under constructive sub-module, it is known as called program.
b) Bottom-Up Approach
2) Operation Testing – Running the application on Customer expected platforms
3) Mutation Testing
Mutation means that a change program. White box testers are performing the change in the program to estimate test coverage on that program. Mutation testing can decide whether the test coverage is correct or wrong
4) Integration Testing
After completion of dependent modules of development & testing, Programmers combine them to form a System. In this Integration, they are conducting Integration testing on the compiled modules w.r.t HLD.
There are three approaches to conduct Integration testing
a) Top-Down Approach
Top-Down Approach
In this approach, testing is conducted on Main module without conducting testing to some of sub-modules. From the above diagram, a Stub is a temporary program instead of under constructive sub-module, it is known as called program.
b) Bottom-Up Approach
Bottom-Up Approach
In this approach, testing is conducted on sub-modules without conducting testing on main modules. From the above diagram, a Driver is a temporary program instead of main module, it is known as calling program.
c) Sandwich or Hybrid Approach
Sandwich / Hybrid Approach
In this approach, testing is conducted taking both Top-Down & Bottom Approaches.
* Build: A finally integrated all modules set *.exe form file is called build.
4) Functional & System testing (* imp)
After completion of final integration of modules as a system, Testing Engineers are planning to conduct Functional & System testing through Black box testing techniques, these techniques classified into four categories.
1) Usability Testing
2) Functional Testing
3) Performance Testing
4) Security Testing
From Above 1 and 2 are Core level and 3 and 4 are Advance level
. During Usability testing, Testing team validates User-Friendliness of screens.
. During Functional testing, TT validates the correctness of customer requirements
. During Performance testing, TT estimates speed of processing
. During Security testing, Testing team validates privacy to User operations
1) Usability Testing
In general, TT starts with test execution with Usability testing. During test, Testing team validates User-Friendliness of screens of build. During Usability testing, TT applies two types of sub-test:
a) User Interface Test
In this approach, testing is conducted on sub-modules without conducting testing on main modules. From the above diagram, a Driver is a temporary program instead of main module, it is known as calling program.
c) Sandwich or Hybrid Approach
Sandwich / Hybrid Approach
In this approach, testing is conducted taking both Top-Down & Bottom Approaches.
* Build: A finally integrated all modules set *.exe form file is called build.
4) Functional & System testing (* imp)
After completion of final integration of modules as a system, Testing Engineers are planning to conduct Functional & System testing through Black box testing techniques, these techniques classified into four categories.
1) Usability Testing
2) Functional Testing
3) Performance Testing
4) Security Testing
From Above 1 and 2 are Core level and 3 and 4 are Advance level
. During Usability testing, Testing team validates User-Friendliness of screens.
. During Functional testing, TT validates the correctness of customer requirements
. During Performance testing, TT estimates speed of processing
. During Security testing, Testing team validates privacy to User operations
1) Usability Testing
In general, TT starts with test execution with Usability testing. During test, Testing team validates User-Friendliness of screens of build. During Usability testing, TT applies two types of sub-test:
a) User Interface Test
. Easy of use (Understandable screens)
. Look & Feel (Attractiveness & Pleasantness)
. Speed in Interface (Less no of event to complete a test, easy short navigation)
b) Manual Support Test
. Context sensitiveness of user manuals
. Manual support test are conducted at the end of all testing & before release
2) Functional Testing
The major part of Black box testing is Functional testing, during this test, Testing team1 concentrates on “meet customer requirements”. This Functional Testing is classified into below sub-test.
a) Functional / Requirement Testing
During this test, Test Engineers validates correctness of every functionality in terms of below coverage’s.
. Behavioral coverage (changes in object properties)
. Input domain coverage (size & type of every input & output object)
. Error handling coverage (preventing negative navigations)
. Calculations coverage (correctness of output)
.Back-end coverage (impact of Front-end operation on back-end tables contents)
.Service levels coverage (order of functionalities)
b) Input Domain Testing
It is a part of Functionality testing; Test Engineers are maintaining special structures to define size & type of input object
c) Recovery Testing
It is also known as Reliability testing. During this test, 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. During this test, Testing team validates whether application build run on customer expected platforms or not. During this test, Testing Engineers are finding Backward compatibility at maximum.
. 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. During this test, Testing team validates whether application build supports different technology Hardware devices or not.
f) Inter-Systems Testing
During this test, Testing team validates whether application build co-existence with other existing software’s or not and also test whether any Dead lock situation occurs or not.
g) Installation Testing
During this test, Testing team validates whether application build along with supported software’s into customers site like configured systems. During this test, Testing team observes below factors.
.Setup program execution to start installation
. Easy Interface
.Amount of disk occupied after installation
h) Parallel / Comparative Testing
During this test, Testing team compares application build with competitive products in market.
i) Sanitation / Garbage Testing
During this test, Testing team tries to find extra features in application build w.r.t customer requirements.
* Defects
During this test, Testing team reports defects to developers in terms of below categories
1. Mismatches between expected & actual
2. Missing functionality
3. Extra functionality w.r.t customer requirement
. Look & Feel (Attractiveness & Pleasantness)
. Speed in Interface (Less no of event to complete a test, easy short navigation)
b) Manual Support Test
. Context sensitiveness of user manuals
. Manual support test are conducted at the end of all testing & before release
2) Functional Testing
The major part of Black box testing is Functional testing, during this test, Testing team1 concentrates on “meet customer requirements”. This Functional Testing is classified into below sub-test.
a) Functional / Requirement Testing
During this test, Test Engineers validates correctness of every functionality in terms of below coverage’s.
. Behavioral coverage (changes in object properties)
. Input domain coverage (size & type of every input & output object)
. Error handling coverage (preventing negative navigations)
. Calculations coverage (correctness of output)
.Back-end coverage (impact of Front-end operation on back-end tables contents)
.Service levels coverage (order of functionalities)
b) Input Domain Testing
It is a part of Functionality testing; Test Engineers are maintaining special structures to define size & type of input object
c) Recovery Testing
It is also known as Reliability testing. During this test, 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. During this test, Testing team validates whether application build run on customer expected platforms or not. During this test, Testing Engineers are finding Backward compatibility at maximum.
. 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. During this test, Testing team validates whether application build supports different technology Hardware devices or not.
f) Inter-Systems Testing
During this test, Testing team validates whether application build co-existence with other existing software’s or not and also test whether any Dead lock situation occurs or not.
g) Installation Testing
During this test, Testing team validates whether application build along with supported software’s into customers site like configured systems. During this test, Testing team observes below factors.
.Setup program execution to start installation
. Easy Interface
.Amount of disk occupied after installation
h) Parallel / Comparative Testing
During this test, Testing team compares application build with competitive products in market.
i) Sanitation / Garbage Testing
During this test, Testing team tries to find extra features in application build w.r.t customer requirements.
* Defects
During this test, Testing team reports defects to developers in terms of below categories
1. Mismatches between expected & actual
2. Missing functionality
3. Extra functionality w.r.t customer requirement
* Manual v/s Automation
A Tester conducts any test on application build without using any testing tool is called Manual testing, if any testing tool is used then it is called Automation testing
In common testing process, Testing Engineers are using test Automation w.r.t test impact & criticality. Impact -> test repetition & Criticality -> complex to apply test manually. Due to these two reasons testing people are using test Automation.
j) Re-testing
The re-execution of a test with multiple test data to validate a function, e.g. To validate multiplication, Test Engineers use different combinations of input in terms of min, max, -ve, +ve, zero, int, float, etc.
k) Regression Testing
The re-execution of test on modified build to ensure bug fixing work & occurrence of any side effects, Test Engineers conducts this test using Automation
l) Error, Defect & Bug
A mistake in code is Error, due to errors in coding, Test Engineers are getting mismatches in application build are defects, if the defects are accepted by developers to be solves then it is Bug.
In common testing process, Testing Engineers are using test Automation w.r.t test impact & criticality. Impact -> test repetition & Criticality -> complex to apply test manually. Due to these two reasons testing people are using test Automation.
j) Re-testing
The re-execution of a test with multiple test data to validate a function, e.g. To validate multiplication, Test Engineers use different combinations of input in terms of min, max, -ve, +ve, zero, int, float, etc.
k) Regression Testing
The re-execution of test on modified build to ensure bug fixing work & occurrence of any side effects, Test Engineers conducts this test using Automation
l) Error, Defect & Bug
A mistake in code is Error, due to errors in coding, Test Engineers are getting mismatches in application build are defects, if the defects are accepted by developers to be solves then it is Bug.
***
No comments:
Post a Comment