Previous part of series:
Part 1
Part 2. Daily routine
2.1. Documenting QA processes
When the QA team began to expand, it became apparent that detailed documentation was essential. We want our employees to be self-sufficient, and they require the ability to locate the necessary information.
Our documentation enables new joiners and other teams to access information about any feature or process at any time without relying on others.
At the moment of writing this article, we have 82 Notion pages and 10 tables of content sections within only the Docs section in the QA hub. That's the depth of knowledge we've curated to ensure that our team has everything they need.
If someone from outside the QA team wants to know how to set up something for testing, which devices the QA team uses, how to run autotests locally - they can just refer to our documentation.
Of course, it requires a lot of time as you want to write it properly, but in the long term it makes a huge positive impact for everyone.
2.2. RC-ninjing
Within a QA job there is always a routine named release testing. The same tests, the same things done many times. It could really be boring and steal any desire to work.
So why don’t we split it to everyone in the team and create a cool name for this?
We called it RC-ninja.
RC-ninja - the person whose responsibility is testing the particular release. It’s a weekly routine and every person in each stream does it by rotation according to schedule.
RC-Ninjas are tasked with a dynamic set of responsibilities, including:
- Testing Releases
- Identifying and assessing issues, determining whether immediate fixes are needed or if they can be scheduled post-release
- Taking ownership of reported bugs from users and colleagues throughout the week
- Keeping an eye on key release statistics after the rollout
- Ensuring a smooth release process by managing and mitigating any delays that may arise.
We constantly search for ways to improve every process. That's why after a release, RC-Ninjas actively contribute by suggesting enhancements, from updating checklists to fine-tuning automated tests, and even refining release schedules.
2.3. Feature Sharing Call
As far as everyone in the team does “ninjing”, they should be aware of every new feature, update and change. In order to keep everyone on the same page, we have a weekly Feature Sharing Call, where anyone who has any updates from their team goes through the design of the feature and describes how it should work. This could be a small new feature, face lift of the big ones or any change within both apps. We are a product company and we build our products for users, so we need to be sure that we deliver a good user experience and do not have any discrepancies and inconsistencies in the design of the whole application.
Also Feature Sharing Call it's a cornerstone in building trust and forging positive relationships within the QA team. When everyone has confidence in each other's perspectives and trust in one another, it's a catalyst for teamwork and unity. They are more likely to work together towards a shared goal.
Top comments (0)