How to introduce QA Process to established teams

In this article, I am going to present some insights into my journey starting out at Martian & Machine (M&M): Gaining knowledge, understanding new people, and deciding upon how and where to introduce QA testing aspects to a diverse and established team.  

After several years of testing the ins and outs of enterprise applications and dealing with SaaS models, I have opted to switch gears and applied for a QA Specialist role at M&M. The Martian switch would prove to be interesting and challenging, as it has introduced me to a variety of products and features, new ventures, and a ton of opportunities to better myself professionally and help the team. It also shed a light on my testing approach and thinking philosophy when it comes to deciding where to exactly implement and invest in quality assurance efforts.

Spoiler alert: Here at M&M, we are focused on having those set as early as possible, especially for new projects.

Starting out with QA testing process

More often than not, as a software tester, you aim to support the team in a way that you come up with and maintain processes, investigate and think of the best ways to approach QA testing when you’re dealing with several projects and clients, or explore new, and also improve existing tools that will make your testing work easier, more efficient, and better aligned with the product specifics you’re in charge of testing. 

As time passes, you gain new discoveries while QA testing. You also begin to acquire broader product (or service) knowledge. At this point, you get to apply all the QA testing processes, alongside with your critical thinking, in order for you to tackle all the potential obstacles that you might face. Needless to say, (however, I will dare to say it) - no approach should be the same.  

With that said, as your career progresses, one of the sweet-sour challenges of transferring all of the accumulated thinking and processes is manifested when coming to or joining a new and established team. What makes it even more cumbersome is the fact that sometimes the new team has never had a full-time dedicated software tester, to begin with. Here’s where our story starts.

Challenging your ideas

One thing to clarify right away is that everything you come up with is potentially going to be challenged and questioned. This will most probably occur in teams where team members have previously worked and collaborated with QA. Since those experiences tend to tip on both sides of the scale, brace yourself to prepare and stand up for your ideas, if necessary. Not saying that asking questions is in any way, shape, or form a bad thing but bear this in mind - things are going to be challenged, and that is something good because it is one of the most efficient ways of enhancing and iterating. An additional bonus: It usually goes both ways.

Challenging each other’s ideas and solutions can even become your cornerstone if you do not perceive comments or suggestions as direct and personal strikes to you or your standpoints. However, we all do it from time to time. The reason behind it is that people tend to get used to working in and with their own agreed-upon workflows and processes that they sometimes have a hard time letting go of. This is especially important when coming to a new team. As each approach is certainly different, the further text will give you an overview of how this transition was done within M&M.

A somewhat simplified list would consist of several steps:

• Adjusting your approach to the new team

• Focus on being involved early on

• Improving reporting with minor adjustments

• Encourage and enhance observation 

Adjusting your QA process to the new team

A good starting point would be to investigate and get familiarized with all the existing processes as they are currently implemented. At this point, you should be comfortable with not immediately addressing issues and potential loopholes just yet, but make sure to have them either documented or prepared for later.

 It should be even more important to get to know the people that are involved during the QA process. Those are the people whom you will have the most of your interactions with and they know how existing processes and workflows are set up. Only then you can efficiently start working and building on top of that. Approaching the idea of getting to know the processes (and people) in that way will help you gauge and decide what should be a good entry point for new ideas, and constructive suggestions, and, in the end, help you steer people to new ideas more easily.

As previously mentioned, no matter how much or little your experience varied throughout the years, your approach should never be the same, at least not right off the bat. It is only logical that we tend to recognize patterns or parts of a certain process and attempt to glue them together with any of your previous experiences and, what were then best practices. However, this will certainly change because you are working with a new set of people and in an entirely new and different work environment.     

Focus on being involved early on

There is a common approach philosophy discussion in a lot of places, projects, teams between the old waterfall vs. agile. A quick note - this is not an article about that. What can be definitely said about both of those is that quality aspects should begin as early as possible, no matter what approach is used. Doing that will help to potentially identify a wide range of issues, problems that can be discussed and resolved before any form of specification reaches the development team, and cascade even more problems down the line.   

To complicate things a bit more, quality assurance has its fair share of being confused, mixed up, and equated with testing. QA related roles can significantly vary in their job description, responsibilities, and the actual scope of work so, in order to combat that, it can help to create that distinction for yourself and see if it will correctly apply to your future or current work environment. The idea behind the distinction is that it will help you, first of all, look out for jobs that would better fit your desires, and in turn provide a better platform for your future work. Alternatively, you will get the grasp of where you should primarily focus your efforts.

Improve reporting with minor adjustments

There is a constant need for little things to either improve the workflow or, at least, change someone’s perspective about things that are already implemented. Adding new things, introducing new tools to any team seems to promote more collaboration, discussion, and should deliver even more productivity. As soon as either your team or you notice this brings additional value, it should be communicated outside of the team and made accessible company-wide. In the case you’re working in an agency, this can easily be put through on all of your active and future projects.

Apart from test case management, writing, and thinking about an end to end scenarios and exploratory observation notes, the most notable form of documented work for a dedicated software tester is some kind of a bug report. In its simplified form, a bug report is used as a detailed guide for reproducing any kind of mailforming software issues, functional or visual bugs, and various improvements yet to be made. 

In order to achieve that, the report has to contain numerous information ranging from the concise title, type of reported issue, clear and easy to follow steps to successfully reproduce, etc. Any additional information could be useful and beneficial in reproducing the issue and determining a proper way to fix it. Those could range from a set of request/response examples, specific test data that was used, or simply a detailed screenshot or even a video recording. The difference between a good and an excellent bug report is often just several newly added fields that easily help to distinguish the priority evaluation, information regarding test environment, or test device. In that scenario, small improvements make for a big impact. 

Encourage and enhance observation

After we’ve made some room for QA related statuses and workflows, what we’ve started to realize is that there was a new trend that is slowly starting to pick up. It was to observe, and not just react. Oftentimes, teams decide on a certain feature, iterate it enough for it to end up in the pipeline, develop it, test it, deploy it, and don’t really invest time or effort to polish all the imperfections and improve on stability and overall look and feel.

During bug report implementation into our workflows, as my minor personal touch, I included an extra step which was: Observe the screen. This might have started as an inside joke (or at least produces some chuckles along the way) but somehow provoked other team members to actually better start (or begin) to observe the screen states after a particular action is performed. With that, we’ve accomplished greater test coverage from people that perhaps weren't big fans of end-to-end testing, for example.     

Conclusion

Although this is not a detailed follow-to guide on how to apply your QA process in a new team, it should at least help to think about some starting points and key places where you can certainly make an impact and start adding value. Some of those key points that should always make your list would be to enhance the bond with the people who you’re working with and better understand other coworkers’ processes. In the end, do not be afraid to get your voice heard across the team.

Keep testing!