A child had to submit an assignment in school. The child’s parents helped him work on this assignment and get it ready for scrutiny at the school. Now, on the day of submission, there was an argument. While the child who was running late for school and wanted to hop on to the bicycle, his parents were apprehensive. They wanted their child to reach safety and hence, insisted that they will drop him to school in a car. This argument continued and no one listened to the other. Result? The child could not go to the school that day and hence, missed the submission deadline. Here, the child is the customer, parents are the delivery team, and the assignment is the product.
A tester often drifts into the technical aspect of a software or a solution so much, that he loses the end user’s perspective. A software testing specialist’s role is not limited to check if the software matches the client’s requirements, but to also view it from a user’s perspective and point out the glitches that make it less user-friendly and more difficult to understand/operate. Sometimes, this approach might be misunderstood and labeled as sly, however, that should not deter the testing specialist. Let’s cite an example: Say, a project is ready, and there is a general perception, that it will pass through the testing stage ‘glitch-free’ and then directly go on to deployment. However, the testing team finds the developed product less user-friendly and suggests a creative solution to make it more appealing to the users. This is hailed by the client/customer, however, the work of a developer increases. Such situations commonly lead the QA and testing team at loggerheads with the development team, ultimately affecting the deliverables and deadlines. Is it not possible to reach to an admissible solution here?
I recently read a blog, regarding re-positioning the role of a tester in the SDLC cycle. Interestingly, if the testers get involved in the early stages of this cycle, these implausible arguments could be handled well. The developers also stay aware of the view in which the testing is going to take place. Prioritizing and division of the stories can thus be planned in an amenable way as in the agile methodology. Furthermore, along with the customers and end-users, testers can also take part in the Prototype evaluation stage. If not for the Vertical prototype, the testers can share their feedback for the potential additions in the Horizontal prototype of the application. This could further help in collecting broader insights on the requirement and can be discussed with the team so that the work is divided accordingly. For instance, any mutations in the CSS styling can be conveyed to the respected individuals. This not only helps in meeting the client requirement, but also in moving a step further to inscribe a great impression on the customer.
I believe, if the testers also get the chance to understand the code base of the project, this could help them to discern the feasibility of the approach. He/she might stay aware of the amount of work concerned with the specific requirement and its effects on the subsequent phases of the cycle.
Additionally, if a tester discusses the observations and suggestions met during the test case preparation; many needs are identified, thus reaching the end of the cycle. The team should convene a daily stand up session and note down the observations from an end user perspective. This helps convert the divergent decisions to convergent decisions in a team. A holistic approach is thus achieved by taking such little accounts into consideration.
These approaches are helpful in avoiding pesky situations a team encounters and an adaptive environment is then achieved. It solves the Red pill & Blue pill dilemma of the tester and brings parties to an agreeable solution.
