Test Execution

After completion of test design (preparation of scenario, cases and data), corresponding testers can concentrate on test execution. Here test execution is possible in two ways such as manual testing and test automation.

 Why following manual or Automation or both, test execution process is able to classify in below steps.
a) Formal meeting
In general test execution process can start with a formal meeting in between developers and testers. In this meeting, developers and testers can discus three factors.
 Sprint or software
 Defect Report
 Modified Sprint or software release
(Build Version control process)
In general developers can approach sprint or software to server computer in company network. Testers can download or launch that sprint or software from server to tester computer.

 If sprint or software is 1-tier or 2-tier windows based software, tester can download and install that software or sprint in tester computer.
 If sprint or software is 3-tier or n-tier, tester can launch that sprint or software using URL/URI. In general tester can report to defect to developer through an email using ms-outlook, lotus notes like mailing software’s or report defect using defect reporting tools like JIRA, Bugzila, Bugtracker, mantis….etc. In general, developers can release modify sprint or software by assigning new version number.

b) Levels of Test Execution
After completion of formal meeting with developers corresponding tester can concentrate on design levels of test execution.

c) Establish Test Environment
After completion of formal meeting with developers and clarification of level of test execution, corresponding testers can sit with hardware team or infrastructure team to establish test environment with required hardware and software.
Test bed or Test harness

d) Smoke Testing or Testability Testing or Verification Testing
This testing stage is also called build verification testing or testability testing or tester acceptance testing.
In general tester can conduct smoke testing to ensure the corresponding sprint build came from developers is working or not. Here tester and scrum master can download launch corresponding sprint or software from server computer into one cabin system into test environment and then, scrum master and testers can execute a fixed step of positive functional cases on the sprint or software build to ensure that build is working or not. If corresponding sprint or software build is not working in test environment,
testers can reject that sprint for working sprint or software.

e) Real Testing
This stage of testing is also called as comprehensive testing. During this test, tester can execute all test cases one after other on corresponding sprint or software builds by comparing expected values in test cases and actual values of sprint or software build. If all test cases expected values are equal to corresponding actual value then tester can stop test execution and concentrate on defect reporting.
f) Error, Defect, Bug, Failure
Error: A mistake in coding found by developer is called as error or flaw. Defect: A mismatch in sprint or software found by tester is called as defect/issue/Incident/Ticket. Bug: A defect in software was accepted by developers is called bug. Failure: A software problem raised in customer site called as failure or latent
bug.
g) Defect Report
During smoke testing, tester can reject sprint when sprint is not working. But in real testing, tester can report defect to developer when that sprint or software is not correctly working. Due to this reason defect means a mismatch in between tester expectations and sprint or software actual to report to defect to developer, tester can follow below IEEE829 format.

1. Defect ID: Unique number or name as title
2. Description: About detected defect
3. Build Version: Version number of build, in which this defect was detected
4. Feature or Module: Name of module in which this defect was detected
5. Failed Test case ID: ID of test case, in which execution this defect was detected
6. Reproduceable: yes/No,

7. If yes, attach test cases doc:
8. If No, attach test cases doc and screen shot
9. Severity: The seriousness of defect with respective to tester show Stopper/high/critical Not able to continue further testing until fix this defect.
   Ex: functional defects
   Medium/Major able to continue testing, but mandatory to fix this defect Ex: Non-functional defects
   Low/Minor  able to continue further testing, but May or may not to solve defect. Ex: Usability defects
10. Priority: The importance of defect fixing with respective to customer
    High
    Medium
    Low
    11.Status: New/Reopen

12.Test Environment: List of used hardware and software while detecting this defect.
13.Detected by: Name of tester
14.Detected on: Date and Time
15.Assigned to: Developer name
16.Suggested fix: (optional)
Suggestion to fix defect if you know
Note1: Tester can use MS-EXCEL, Open office Excel to prepare above like defect report.
Note2: Tester can use MS-Outlook or lotus notes to forward defect report to developer as an email.
Note3: Some company tester are using defect reporting like Bugzila, JIRA, Defect tracer, Mantis, Bugtracer…..etc.

h) Defect tracking process

i) Bug Life Cycles