Putting Quality on Cruise Control for Longer Running Projects
Have you ever experienced driving on the highway with cruise control turned on?
It’s a wonderful feature to have in your vehicle for longer journeys, especially on our awesome motorways that cut across Pakistan from Sukkur to up North. In fact, it’s so wonderful that once you get used to it, you won’t be able to drive without it.
It allows you relax, just a tad bit. You start to enjoy the scenery around you, enjoy the music playing in your car a bit more, get involved in discussions happening in the car with family or friends, trusting that cruise control is handling the most basic operation of keeping your vehicle at a constant and manageable speed, while still being cognizant of the fact that you need to, and can, take back control whenever needed.
Running your QA operations in longer running projects is strikingly similar.
Way too much effort and time can be spent in running the basics over and over again. Naturally, this results in monotony at work for QA engineers, which impacts motivation to continue working on the project, and leaves less time to work on other initiatives which may be more rewarding at a personal level.
Another adverse outcome of this mode of work is that QA engineers may request backup QA engineers to be added to the team, so they can offload basic tasks, such as running a predefined smoke test, and focus on other initiatives like automating test cases or increasing their communication with clients.
But what if QA engineers can take the initiative to introduce ‘cruise control’ for repetitive actions that are very important to keep the train running, but feel monotonous and time-consuming due to their repetitive nature?
For the most part, this would result in offloading repetitive tasks so that they can enjoy working on initiatives that they find more rewarding.
This sounds great, but how exactly can QA engineers move towards this ‘cruise control’? Here are some suggestions:
Inculcate a Quality-First Mindset Across the Team
This includes having sessions with the team to drive home the motto, ‘Quality is everyone’s responsibility’.
For example, you expect your government to keep the city clean while you keep on throwing trash out on the streets.
If developers simply keep moving on to their next ticket without doing a decent amount of testing on what they have developed, then QA engineers will keep spending the extra time to ensure a minimum level of quality.
It is much more efficient to have developers run at least a set of happy workflows on their development before passing on the ticket to QA for testing. Achieving this co-ordination requires a change of mindset, and QA engineers can take initiative to drive this change for their own benefit.
This is self-explanatory.
Automating test cases in your smoke or regression checklist that need to be run for each release have a direct impact on reducing the repetitive effort that takes time and energy to run manually.
Automation also reduces the risk of human error while testing, which adds the side benefit of improving the overall quality of your releases.
Document the Basics Well
The value of good documentation, such as updated or new features or maintenance to your product, is evident when onboarding new members to the team or referencing an unfamiliar area in the application that another team member has done in-depth analyses on, and documented the area in the process.
Updated and comprehensive documentation has proven to be a huge time saver for the existing QA members of the QA Team.
Integrate Unit/Integration Tests into your CI
Having a set of core test cases run by your CI tool on build deployment is tremendously helpful in taking the stress and monotony of running these core test cases manually for each deployment or release.
Introduce Regular Knowledge Sessions for your Team
It’s normal for team members in longer running projects to attain subject matter expertise in a particular area of the product, due to the volume of activity they perform in the area.
Also, team members are likely to develop a new feature independently that fellow team members may not be aware of.
Having regular knowledge sessions to introduce an area or new feature of the product helps in keeping the entire team, especially the QA team, on the same page. This, in turn, helps with thorough and seamless testing, with more awareness of impact areas that need to be regression-tested for quality control during releases.
Ultimately, these activities help keep the quality train running efficiently and keep the team satisfied with their progress.
In short, while cruise control is an amazing tool, it is not enabled by default. Introducing it takes time and effort, but it’s worth it in the long run.