Bla Bla Bla, Lots of QA Talk and Vague Implementations: How to Foster a Culture of Quality in Real…

Bla Bla Bla, Lots of QA Talk and Vague Implementations: How to Foster a Culture of Quality in Real Practice?

For many years, I have seen a lot of posts by QA Engineers or SDETs about how quality should be owned by everyone in the development process, but I see few solutions for this. I have read about teams removing the Testing column, having meetings to talk about quality, and implementing unit testing, but it is never clear how those implementations actually look.

The intention of this article is to showcase how to foster a culture of quality in your team to speed up releases, reduce failures, and guarantee quality in software. Let’s dive in…

• Start with yourself. When people see you as the QA Engineer or the SDET, they should see a quality ambassador, someone who cares about the product and its customers, someone who promotes good practices, and simple but impactful solutions towards the improvement of QA processes and software quality. By starting with yourself, I mean knowing and understanding the software architecture, familiarizing yourself with the concepts developers and PMs are talking about, knowing about the product and the customers, becoming a product expert, and producing clear, concise, and high-quality test reports. Please do not over-engineer; I have seen many QA Engineers making things very difficult and hindering the process when over-engineering. When it comes to quality, you want to implement simple, concise, impactful, and slow changes so you can have control over the outcomes. You also want developers and everyone to understand that you have high standards for yourself, which can imply that you expect high standards from your team members.

A QA Engineer is also a researcher. You need to fully understand your current team culture, development stages, risks, and much more. The point of saying a QA Engineer is a researcher is to emphasize that you first investigate and, based on the data, make decisions. This leads to the next point.

Gather the right information. The fact that a bug leaked into production doesn’t mean the QA processes are falling apart. I am so tired of seeing radical changes in workspaces just because of a single bug in production. It is exhausting. Why do teams do that? You don’t need to change everything or start with crazy implementations because something failed. Most of the time, you just need to adjust. My advice is to narrow down or identify the stages where the bug could have been detected. Ask yourself/team these questions: Do we have unit testing for this? Do we have API testing for this? Do we have E2E testing for this? Is this an edge case or simply something that wasn’t caught? Was this part of the test plan? Was the bug ignored in the automation testing run because our automation is too flaky, so we are just ignoring it all the time? Is this a requirement bug or due to incompatibility? What was the source of the problem? Were there changes in a microservice that we had no idea about, which is incompatible with the new requirements?

Once you have answered all the questions you need, start taking action. Ask developers for unit testing around this functionality and then review yourself the PR, check what type of testing there is, are there more scenarios needed? Work with developers to review the API testing or develop those yourself, and finally, evaluate if E2E testing is needed for this. Also, identify if this is a core functionality. If it is, you might want to add conditions in the GitHub Actions or AWS YAML file so that if changes are made to specific modules/files in X repo, other specific tests in Y, Z… repo(s) should run.

My point is, BECOME A DATA DRIVEN QA ENGINEER.

• Involve the developers. Developers LOVE automation testing. They don’t necessarily love doing it themselves, but they appreciate being involved in the process when you are the one developing it. So approach them. Do NOT stop scripting an automation test because of your technical skill limitations. Go and talk with a developer; I am a million percent sure one of them will be happy to help. The same applies to DevOps. Involve the team, take ownership of your job, but reach out and allow them to participate and understand the reasons behind what you are doing. Also, send reports about which features are automated, ask them about the unit tests that are in place so you are not over scripting, and let them see what you are seeing. Once those things are in place, prototype standards for unit testing yourself, make a PR, and write some tests yourself. Play around with it until you feel you have reached solid unit testing standards that developers can follow. Once that is done, set KPIs. Maybe I should use another word since KPIs sound a bit frightening, but the idea is not to monitor their job but to monitor the current status of quality. This is a team; never forget that.

So what KPIs can I implement? How can I implement those? And how can I make sure everyone follows them?

What KPIs can I implement? One example is Unit Testing Test Coverage. Usually, QAs are disassociated from unit testing coverage; however, there are many ways in which you can implement this. I will use Python as an example:

You could use the “coverage.py” package to run your tests with coverage. For example, you could run the tests with the command: coverage run -m unittest discover. Depending on whether you are using Pytest or not, you can generate an HTML report with a command like coverage html or coverage xml. Note that the report will print the module and its percentage of test coverage, which will help you understand which areas of the app are missing testing. Of course, you will want to monitor this automatically, so it is important to create a YAML file in AWS or your provider that runs this for you against your repo and sends notifications to you or the team to monitor the test coverage on unit testing and work accordingly.

Now, how the hell can we all commit to it? You will definitely be the lead on this, which means you need to make sure you’re raising the alert and creating tickets in the areas where unit testing needs to be added. In Jira or whatever ticket management system you use in your company, create a ticket with the module and repo’s name, add all the necessary details and percentage expectations, and add a note for you to be the reviewer of the PR.

Maybe what I would do is create a Slack channel named #software-healthcare-kpis where we push notifications about this.

There are many KPIs you can implement. I can create another article exclusively about this if you would like, as it is a topic I am very passionate about. Anyway, with whatever KPIs you implement, please don’t be greedy. Don’t add things that won’t add value, and do it slowly. This is a long-term project; don’t harass people with it. I’ll keep an eye on you! 🧐

• Set expectations to the PMs. It is hard to set KPIs here, I know. However, you need to remember that you are a researcher and a QA-driven engineer. If you notice that bugs are produced due to certain patterns in the requirements or a lack of information, talk to your PM(s). Propose to add more details or to remove unnecessary and confusing ones. There is always something that can be improved here. Be vigilant about it, and try to measure how many bugs occur in the testing stage due to a lack of requirements or confusion due to ambiguity. Even more, measure how many bugs happen after changes in the requirements. Always remember that the idea is not to point fingers but to standardize the software life cycle as much as you can while having fun in the process.
• Celebrate people’s contributions to quality. Say thank you and celebrate their contributions. Give a shout-out in any public channel, letting them know why their contribution to quality is important. Negotiate with Engineering Managers to see if there can be any special recognition for the person who has contributed the most to quality in a given trimester or month. Maybe an extra vacation day, a gift card… who knows? Figure it out. Come on, I can’t give you all the answers!

Anyway, Software Quality Assurance is an ecocystem that relays on a variety of people, as QA Engineer your job should be testing, researching, implementing and monitoring that ecocystem, and dig deeper to the core of issues, gaps, improvements and then have an elegant and realistic implementation based on data gatherine. Also, be excited about your role, it can be contagious, and that can facilitate your job to be better, funnier and easier. Please be mindful, these advices are for QA Engineers more advanced in their career if you are a beginner don’t feel intimidated, but get the general idea about it and take some notes on how you can excel in your career.