Step By Step Software Testing Process To Achieve Top Product Quality

At Mindbowser, we are always looking to create predictable Zero Hiccup processes. A process-driven QA manual is a cornerstone of such a strategy. In this blog, I share our software testing process that has worked well for us. The process keeps evolving but this blog gives you a good idea about the core process.

The Mindbowser Software Testing Process

The software testing process starts with creating a test plan. A test plan is a systematic document for planning and documenting a test effort for a software product. It describes how we will execute the testing activities to determine whether the product is ready to be released.

The plan describes the test strategy, objectives, schedule, estimation, deliverables, and resources required to perform software testing for a product. It acts as a blueprint for all testing activities.

For Agile development, we do not need to create documents upfront. We decide the sprint objective, estimations, deliverables and what type of testing we are going to perform and activities during sprint planning. We set up a Qase.io account for each project to manage the testing for the project.

What is Test Suite?

The test plan has a test suite created for the different tests we do. Test suites help organize all the test cases into logical groups. Сomprehensive features of test cases help define the module/feature severity, priority, type of test cases [functional, smoke or regression], test cases behavior [positive or negative], pre-post conditions and steps to reproduce.

We primarily set up 3 test suites:

1. Smoke Test Suite
2. Regression Test Suite
3. Functional Test Suite

Fig: Snapshot of Qase tool where we define a different Test suite

Smoke Suite:

• Consist of all the smoke test cases or critical test cases of the feature. In smoke test cases we include high-level positive scenarios test cases only.
• Smoke test results and reports decide whether we need to accept or reject the build.

Regression Suite:

• Regression test cases include all the previous sprint’s high level- positive and negative test cases.
• QA needs to execute the regression test cases suite to check whether the previously developed functionality is working properly or not based on the passed/failed result. This type of testing helps to keep the application up and running without any issues.
• Regression testing is always part of every sprint cycle.

Functional Suite:

• This consists of all the functional test cases for the project. Functional suite test cases include all positive and negative detail test cases for the module/feature execution which we are considering for the ongoing sprint.

The above test suites are completely mandatory for the team and failing to create the test suites results in rejection of test cases for the team.

QA Process in Software Testing:

a. Writing test cases in CSV file format
b. Uploading final updated test cases in QASE tool
c. Dev environment: Dev and QA run smoke test cases
d. Staging environment: QA runs Smoke/Functional and Regression testing
e. Logging defect in JIRA and retesting
f. If all test cases are passed in staging then the team will go for the Client demo

Fig: Test cases writing – CSV format  screen dump for reference

Fig: Snapshot defining test cases in Qase

Fig: Snapshot defining test cases in Qase

Fig: Defect logging through Qase tool and integration with JIRA screen dumps for reference

Fig: Defect logging through Qase tool and integration with JIRA 

Fig: Defect logging through Qase tool and integration with JIRA 

Fig: Defect logging through Qase tool and integration with JIRA 

Fig: Defect logging through Qase tool and integration with JIRA 

Internal Demo:

• Once all the planned user stories are developed, tested and verified by the QA team, on the staging environment we do an internal demo with all team members and take the feedback. The demo dates are decided during the sprint planning meeting considering the development and staging environments.
• If any new suggestion or improvement from the internal team comes up, we keep it as part of the next sprint.
• Once everyone agrees with implemented changes then the team plans a demo for the customer.
• Feedback includes bugs and suggestions for improvement. Based on our feedback changes, we decide whether to make changes only or keep it as part of the new sprint.
• Finally, the build is ready to be shared with clients.

Client Demo:

Often founders complain that they do not really know where their project progress lies until one day they see the project state that has gaps and is too late to fix.

Keep a dedicated time for the demos and product walkthrough at every milestone or major feature update of the project. If your project is an ongoing engagement, then you can have a demo every 2-3 weeks. The demo should be happening over live video sharing followed with sharing of build that you can play around in your own comfortable setting as well.

We recommend to our customers that during the demo they understand thoroughly and provide feedback to the team. To avoid too much discussion, clients can keep notes and discuss at the end of the demo. 

After the client demo, we share a detailed report of the sprint completed. It includes:

1. List of features completed
2. Links/Builds
3. Test credentials to check
4. Test cases reports
5. Codegrip reports
6. Known issues

This report is shared by the QA team with the Project Manager to be further shared with the customer.

Best Practices For Software Testing:

Keep proper naming convention for each test like: Build Version_Build type_DD/MM/YYYY_Smoke/Regression/Functional_1st pass

Keep past test cases handy for future us:

• Use WPS or similar software for smooth writing and editing of test cases.
• Integrate Jira with Qase so that you get all data in sync. In the sprint planning itself, we decide dates for final development build and then staging build. The developer’s aim is to complete the tasks by estimated dates. During daily standup, we check for every developer’s JIRA ticket status.
• At the start of every sprint, a detailed sprint planning meeting is held with end to end screen walkthrough addressing the team’s understanding about it to avoid further gaps and delays. During sprint planning, we also decide weekdays to share a regular build for testing. For e.g. we can decide developers must share builds every Tuesday & Thursday for testing. This process is integrated with code review as well so that whenever code review is done and merged, it is approved and then only the build is gets generated via CI/CD. 
• While sending regular builds developers send email as well with all the features developed & known issues. 
• Developers also make sure that they are changing their JIRA ticket status to ReadyForQA. This way the team remains in sync.