Can you think of a software delivery without or with very less Quality testing? If yes, then be prepared for a heated session with the client who himself is bound by the tight delivery timeline and the poorly tested module is only going to make it worse. I have been a part of such a delivery where the client was persistent to launch the module before time due to some prior commitment made to the stakeholders holding key position in Management. It was a really harsh demo with all the questions directed to the Product Owner by the client.
This event made me think on how to prevent such encounters and ensure testing is done effectively. The other challenge with this situation was to balance the quality of software along with the timely testing. I started interacting with Quality Assurance team to understand their challenges.
Interaction with Quality Assurance team:
- The primary reason for poor testing was delayed creation and sharing of Concept designs with the developers and which ultimately took away time from Quality team to work on use cases to effectively test the module. The module documentation and a quick follow up meeting to understand the objective of module could have resulted in better testing.
- Setting up of testing environments demands attention to detail and upload of relevant data files by the Quality Assurance team for effective testing. This activity can be overlooked in case the team is spending more time focusing on documentation.
- Outdated technology tools and systems – Have you noticed your testers struggling with their laptops or mobiles to get the installation of APKs in one go. It could also be a result of poor internet connection resulting into a demotivated team preferring to spend more time sipping coffee. All these factors need timely escalation before they prove fatal.
- Incomplete or poor bug description – The team showed me the bugs created by the business team members where there was no clear description about the module on where it was encountered and it lacked the expected call to action for the testers to understand the flaw in one go. It ended up adding a task to testers for getting in touch with business team to understand the issue.
The challenges stated above can be rectified by open discussion with Product Owner and business team members. After having a chance to sip coffees with both the team members. We came to a consensus that there is a need to improve the current business processes.
- Product Owner took the responsibility for drafting the concept note with possible use cases and sharing it with both business and developer teams once the requirement gathering was complete. It also helped the developers to think through the module and plan the delivery accordingly. The testers, on the other hand, were aware of the details like the platforms like Web, iOS, Android and expected user behaviors.
- Testing types – Smoke testing should be planned as per the concept note shared by the product owner beforehand. This will ensure the critical functionalities or expected behaviors are in check as expected by the client. Regression testing can be carried out parallelly covering all the workflows.
- A delay in commits can also result in a bottleneck with the testers team. It becomes crucial for the product owner to schedule the commits and stick to the release plan for effective testing.
- Dataset creation for testing is also known for consuming time which could be used by testers for testing the software. There are automation tools available nowadays which make use of browser data. It not only saves time but stores the data in the database thereby reducing cost and time efforts.
- Testing Workshops – One of the companies, I worked with had a weekly scheduled demonstration day where the developers gave a walk-through of the modules developed in that sprint. It included the entire team expressing their concerns related to the design and workflow. A similar workshop can be organised to carry out the testing of modules thereby allowing more suggestions for improvement and hence improved user experience.
