Standard end to end Quality Assurance Process

  • Abhik
  • 0
  • 2017-11-08

Strategy (Test types)

Following test strategies are going to be followed:

  1. System testing: New functionality shall be tested using manual approach. This shall include backend system, frontend system and integration points like Rest API using Swagger UI. This testing includes following type of testing: sanity testing, smoke testing, regression testing, functional testing etc.

  2. Automation testing of UI & Functionality: With the help of Selenium WebDriver, regression testing shall be automated. This is to test the UI and functionality of backend and frontend system.

  3. API testing: Rest API testing shall be introduced later part of the test cycle. This can be done using SOAPUI-community version software.

  4. Performance testing: Performance testing needs shall be performed once we reach a deliverable point. This shall be performed using JMeter.

  5. Usability testing: Usability testing shall be performed using manual process (on actual device and emulator testing) to check the easy access of the application.

Build cycle & environment available

It is never recommended to push the code directly to production. A stage and QA environment is preferred / recommended. Stage can be made optional if QA can be acted both as stage and QA.

Recommended process

  1. QA should be notified for a new availability of the build. A brief about current changes (a change note kind of).

  2. Once notified, QA shall take the latest version of the master and deploy it to the QA server.

  3. Once QA finish the testing on QA environment, it shall notify back with the test result.

  4. Based on test result, decision has to be taken for stage deployment. Once tested, the build manager shall push the code to production server.

  5. Smoke test on the production and sign-off.

Test management

Test deliverables are being managed through different tools. Following are the process being recommended by QA:

 Requirement document management

  • Requirement can be drafted during bug scrub meeting/scrum kick-off meeting.

  • The same can be drafted/shared using different tools like words, wireframe designs, pictures of UI design etc.

  • This can be managed in a repository [Like Google Drive or DROPBOX etc.]

 Test Case/Test Scenario management

  • QA shall write test scenarios on excel sheet and shall store in a common place so that it can be referred on later stage. [Currently we can manage with Google drive/DROPBOX]

  • QA should be involved in initial stage of requirement discussion so that test case development can be a parallel and effective process.

Automated test script management

  • Selenium code shall be written in Java using eclipse.

  • Code shall be managed in project BITBUCKET/Github/GitLab. [This is to be discussed with stakeholders].

 Test Results

  • Manual test cases shall be executed in excel sheet itself and result shall be shared in central repository.

  • Automated script shall be executed through manual intervention. In future, we shall try to integrate it in the delivery line as continuous integration and continuous delivery process.

Bug Management

  • Bug shall be logged in an identified tool (like bugzilla, mantis, trello, Jira, Asana etc.)

  • I recommend Jira as bug reporting tool.

  • Bug must be followed by a standard bug cycle.

  • Bug has to be given right priority and severity marks.

  • It should be assigned to the right person so that action should be taken promptly.

  • It should be followed to the closure and should be tracked by the QA engineer.

continuous integration

Automated code can be executed on code push or based on scheduler through any CI tool (Like Jenkins).

Bug cycle proposed

A typical bug flow is like below:


  1. A new bug once identified shall be assigned to a designated engineer and shall be marked opened.

  2. If the bug is valid, it shall be fixed by the engineer else it should be either rejected/deferred.

  3. Once fixed, it should be assigned to a tester. Tested test and based on the result it marks it to reopen/verified.

  4. After the bug being tested in all required environments, it can be marked as closed.

 Bug Label introduced to support this:

  1. Open – New and Assigned (Any team member)

  2. Resolved – Bug resolved in Dev Environment (Developer)

  3. Ready for QA – Any feature or bug is ready for testing

  4. Tested in QA – Bug tested in QA. (QA engineer)

  5. Deployed in Prod – Optional step – if the bug is environment dependent. (Developer)

  6. Tested in Prod – Optional step - for special bugs. (QA engineer)

  7. Reopened – Bug has been marked as opened/reopened. (QA engineer)

  8. Rejected – Invalid Bug (Developer)

  9. Deferred – Can’t be developed in current cycle or current scope of the product. (Developer)

  10. Closed – Bug has been verified and tested in required environment. (QA engineer)

  11. Note: Recommended bug life cycle for Jira is updated in Jira Process document.

Tools recommendation

Bug tracking tool:

  • Jira

CI tool

  • Jenkins

Other tools

  • Web UI automation tool - Selenium WebDriver

  • Rest API test – postman, runscope

  • Performance Testing - JMeter

  • Build Management - Maven and TestNG etc.

Questions & Risk

-----To be entered------

-----------------------End of document-------------------


Follow Teknotrait Solutions on

Comments (0)

Recommended Read