a) Formal Meeting:
Software test execution process can start with a formal meeting in between corresponding developers and testers along with test lead, team lead, business analyst, system analyst, and technical analyst. In this meeting people are discussing about software build release, defect reporting and build version control.In general, developers can place software build in a folder structure called as "Soft Base". In that folder developers can locate SUT.
In general, testers can use MS outlook or lotus notes to forward a defect report in local mailing system which is as follows:
From the above diagram, test engineer will forward any document to the test lead, then test lead will forward to PM. Then PM will forward those documents to the team lead / project lead from there to programmers. So, here PM will acts as head between the testing team and the development team.
In general developers are placing modified software builds in soft base in server with the version numbers. By using those numbers, testers are distinguish old version and new version of software build.
After fixing the defects by the developers, they will release a new software build with version numbers in order to distinguish the old version and new version for understanding the testers. This type of version numbers are called as "Software build version control".
When company release the software version by version to the customers called as "Software release version control".
Example:
b) Defining Test Execution Levels:
From the above diagram, in first build version, Sanity test will be conducted if it is passed, then real test will be conducted on SUT. After that if defects are found then defects will be reported to the development team for the fixing of defects. After fixing (Modifyng) a new build version will be released. In the second version version of build retesting will be done on defects reported cases or scenarios. Then regression testing will be done to check with the modification of previous build any other modules are effected. And if defects are found then those defects will be reported to development team to fix the defects again same process continues till last version of build.
c) Checking Test Environment:
In general, H/w team can establish test environment for testers with required H/w and s/w. Testing team can approve established environment before going to test execution process.
d) Smoke Testing:
After downloading or launching SUT from server, testing team can operate that SUT build in one system or cabin to find that whether that SUT build is working or not.
This smoke testing is mandatory after receiving every SUT build from developers. But, to do this smoke testing team is using a fixed set of cases related to main modules of SUT.
If smoke testing was failed, testing team will reject the SUT build and wait for stable build or testable build. Due to this reason, smoke testing is also called as "Testability testing" or "Tester acceptance testing" or "Build verification testing".
e) Real Testing:
When software build is testable, testing team members can separate each other and then download / launch that SUT into their cabin systems to conduct real testing.
From above mentioned diagram (Refer smoke testing diagram), every test engineer can open corresponding test cases file and SUT.
Tester can operate SUT and compare test cases expected value and SUT actual value. If both are same then tester can goto next case.If all cases are passed, then test the next scenario cases execution. If all scenarios are passed, next modules scenarios cases will be executed.
If all modules are passed, then goto next testing topic (Functional and Non functional).
If all testing topics are passed then goto software test closure.
Note - 1: While conducting real testing, test engineers can arrange test cases in order. The order of related test cases group is called as "Test Suite"(Module level) or "Test Batch". or "Test Build" or " Test Chain" or "Test Set" .
Note - 2: While conducting real testing, test engineers are preparing a daily report called as "Test Log ". This document will be prepared in IEEE 829 format.
Example:
From above format on test log document:
Passed means the expected value is equal to the actual value.
Failed means that expected value is not equal to the actual value.
Blocked means that case execution was postponed to future build version release.
f) Defect Report:
When, test case expected value is not equal to the software SUT actual value test engineer can stop test execution and start defect report preparation. Defect is also called as issue / incident. To prepare defect report also, test engineer can follow IEEE 829 format is as follows:
1) Defect ID:
Unique name or number for a defect.
2) Defect description:
About defect (What are inputs, what are outputs, what is the expected result, what is the actual result and etc..).
3) Build version ID:
Version number of SUT in which defect was detected.
4) Feature or Module:
Name of module in which defect was detected.
5) Test cases Doc ID:
ID of test cases document on which cases execution defect was detected.
Note: 3,4,5 points will indicates origin of defect.
6) Severity:
The seriousness of defects w.r.t tester.
Example:
High / Critical / Showstopper ----> Not able to continue further testing until this type of defect was fixed.
Medium / Major ----> Able to continue further testing but, mandatory to fix this type of defects.
Low / Minor ----> Able to continue further testing but, not mandatory to fix this type of defects.
7) Priority:
The importance of defect fixing w.r.t customer.(High, Medium, Low).
8) Reproducible:
Failed test case will be executed more than one time for checking of defect reproducibility.
case - 1: If defect is reproducible then attach corresponding failed test documents.
case - 2: If defect is not reproducible then attach corresponding failed test case document along with Screen shot.
9) Test Environment:
Used H/w and S/w while detecting this defect in SUT.
10) Status:
Indicates status of a defect which means whether it is New / Re- open.
New indicates reporting defect for the first time.
Re- open indicates re- reporting the defect.
11) Detected by:
Name of a tester who detected this defect.
12) Assigned to:
To Defect Tracking Team (DTT)(Test lead+PM+Team lead).
13) Suggested fix: Suggestions to developers to fix this defect.
Note: After preparing above like defect report, corresponding tester can send that defect report to DTT via email by using MS outlook / Lotus notes / Company websites.
g) Defect Tracking:
After receiving defect report from tester DTT can review that DR and decide that defect is acceptable or rejectable.
The below diagram explains you the defect tracking:
h) Test case Related Defect Report:
If tester reported defect is confirmed as 'test case' related then, the below process will be followed.
i) Test data Related Defect Report:
If tester reported defect is confirmed as 'test data' related then, the below process will be followed.
J)Test Environment Related Defect Report:
If tester reported defect is confirmed as 'test environment' related then, the below process will be followed.
k) Coding Related Defect Report or Bug Fixing:
If tester reported defect is confirmed as 'Coding' related then, the below process will be followed.
After receiving Build Release Note(BRN) / Software Release Note(SRN) from developers, test lead can forwarded to testers. Related testers w.r.t modifications can start below process. The remaining unrelated testers w.r.t modifications are continuing further testing on old version of build. But, related testers can follow below process.
Step - 1: Conducts smoke testing on modified SUT by executing fixed test cases selected previously.
Step - 2: If smoke testing was passed, then we can say that modified build is working correctly. Then related testers will re-execute previously failed test cases called as Re-testing.
Step - 3: If re-testing was passed, then related testers will re execute previously passed most related test cases called as Sanity testing.
Step - 4: If Sanity testing was passed, then related testers will execute all previously passed related cases called as Regression testing.
Step - 5: If regression testing was passed without any side effects, then all related and non related testers can continue further testing on modified SUT responsible modules and responsible testing topics is coding related bug.
For clear understanding observe the diagram carefully:
BUG Life Cycle:
The initial status of every bug is New and final status is closed or defferd.
Software test execution process can start with a formal meeting in between corresponding developers and testers along with test lead, team lead, business analyst, system analyst, and technical analyst. In this meeting people are discussing about software build release, defect reporting and build version control.In general, developers can place software build in a folder structure called as "Soft Base". In that folder developers can locate SUT.
In general, testers can use MS outlook or lotus notes to forward a defect report in local mailing system which is as follows:
In general developers are placing modified software builds in soft base in server with the version numbers. By using those numbers, testers are distinguish old version and new version of software build.
After fixing the defects by the developers, they will release a new software build with version numbers in order to distinguish the old version and new version for understanding the testers. This type of version numbers are called as "Software build version control".
When company release the software version by version to the customers called as "Software release version control".
Example:
From the above diagram, in first build version, Sanity test will be conducted if it is passed, then real test will be conducted on SUT. After that if defects are found then defects will be reported to the development team for the fixing of defects. After fixing (Modifyng) a new build version will be released. In the second version version of build retesting will be done on defects reported cases or scenarios. Then regression testing will be done to check with the modification of previous build any other modules are effected. And if defects are found then those defects will be reported to development team to fix the defects again same process continues till last version of build.
c) Checking Test Environment:
In general, H/w team can establish test environment for testers with required H/w and s/w. Testing team can approve established environment before going to test execution process.
d) Smoke Testing:
After downloading or launching SUT from server, testing team can operate that SUT build in one system or cabin to find that whether that SUT build is working or not.
This smoke testing is mandatory after receiving every SUT build from developers. But, to do this smoke testing team is using a fixed set of cases related to main modules of SUT.
If smoke testing was failed, testing team will reject the SUT build and wait for stable build or testable build. Due to this reason, smoke testing is also called as "Testability testing" or "Tester acceptance testing" or "Build verification testing".
e) Real Testing:
When software build is testable, testing team members can separate each other and then download / launch that SUT into their cabin systems to conduct real testing.
From above mentioned diagram (Refer smoke testing diagram), every test engineer can open corresponding test cases file and SUT.
Tester can operate SUT and compare test cases expected value and SUT actual value. If both are same then tester can goto next case.If all cases are passed, then test the next scenario cases execution. If all scenarios are passed, next modules scenarios cases will be executed.
If all modules are passed, then goto next testing topic (Functional and Non functional).
If all testing topics are passed then goto software test closure.
Note - 1: While conducting real testing, test engineers can arrange test cases in order. The order of related test cases group is called as "Test Suite"(Module level) or "Test Batch". or "Test Build" or " Test Chain" or "Test Set" .
Note - 2: While conducting real testing, test engineers are preparing a daily report called as "Test Log ". This document will be prepared in IEEE 829 format.
Example:
From above format on test log document:
Passed means the expected value is equal to the actual value.
Failed means that expected value is not equal to the actual value.
Blocked means that case execution was postponed to future build version release.
f) Defect Report:
When, test case expected value is not equal to the software SUT actual value test engineer can stop test execution and start defect report preparation. Defect is also called as issue / incident. To prepare defect report also, test engineer can follow IEEE 829 format is as follows:
1) Defect ID:
Unique name or number for a defect.
2) Defect description:
About defect (What are inputs, what are outputs, what is the expected result, what is the actual result and etc..).
3) Build version ID:
Version number of SUT in which defect was detected.
4) Feature or Module:
Name of module in which defect was detected.
5) Test cases Doc ID:
ID of test cases document on which cases execution defect was detected.
Note: 3,4,5 points will indicates origin of defect.
6) Severity:
The seriousness of defects w.r.t tester.
Example:
High / Critical / Showstopper ----> Not able to continue further testing until this type of defect was fixed.
Medium / Major ----> Able to continue further testing but, mandatory to fix this type of defects.
Low / Minor ----> Able to continue further testing but, not mandatory to fix this type of defects.
7) Priority:
The importance of defect fixing w.r.t customer.(High, Medium, Low).
8) Reproducible:
Failed test case will be executed more than one time for checking of defect reproducibility.
case - 1: If defect is reproducible then attach corresponding failed test documents.
case - 2: If defect is not reproducible then attach corresponding failed test case document along with Screen shot.
9) Test Environment:
Used H/w and S/w while detecting this defect in SUT.
10) Status:
Indicates status of a defect which means whether it is New / Re- open.
New indicates reporting defect for the first time.
Re- open indicates re- reporting the defect.
11) Detected by:
Name of a tester who detected this defect.
12) Assigned to:
To Defect Tracking Team (DTT)(Test lead+PM+Team lead).
13) Suggested fix: Suggestions to developers to fix this defect.
Note: After preparing above like defect report, corresponding tester can send that defect report to DTT via email by using MS outlook / Lotus notes / Company websites.
g) Defect Tracking:
After receiving defect report from tester DTT can review that DR and decide that defect is acceptable or rejectable.
The below diagram explains you the defect tracking:
h) Test case Related Defect Report:
If tester reported defect is confirmed as 'test case' related then, the below process will be followed.
i) Test data Related Defect Report:
If tester reported defect is confirmed as 'test data' related then, the below process will be followed.
J)Test Environment Related Defect Report:
If tester reported defect is confirmed as 'test environment' related then, the below process will be followed.
k) Coding Related Defect Report or Bug Fixing:
If tester reported defect is confirmed as 'Coding' related then, the below process will be followed.
After receiving Build Release Note(BRN) / Software Release Note(SRN) from developers, test lead can forwarded to testers. Related testers w.r.t modifications can start below process. The remaining unrelated testers w.r.t modifications are continuing further testing on old version of build. But, related testers can follow below process.
Step - 1: Conducts smoke testing on modified SUT by executing fixed test cases selected previously.
Step - 2: If smoke testing was passed, then we can say that modified build is working correctly. Then related testers will re-execute previously failed test cases called as Re-testing.
Step - 3: If re-testing was passed, then related testers will re execute previously passed most related test cases called as Sanity testing.
Step - 4: If Sanity testing was passed, then related testers will execute all previously passed related cases called as Regression testing.
Step - 5: If regression testing was passed without any side effects, then all related and non related testers can continue further testing on modified SUT responsible modules and responsible testing topics is coding related bug.
For clear understanding observe the diagram carefully:
BUG Life Cycle:
The initial status of every bug is New and final status is closed or defferd.
