Abstracts

There is a lot to be addressed during first days of being a QA in a new project all at once - testing itself, process maintenance, and knowledge gathering. Yet, numerous issues stand in the way - documentation doesn’t exist, is outdated or over-detailed; tasks are poorly described or not described at all; requirements are changing - but it’s highlighted nowhere, being discussed only in DMs between few people, etc. Most likely all of us faced such a situation at least once in our careers. In addition, there are usually dozens or even hundreds of test cases to be maintained - or there are none, and would be good to start writing them. 

On the other hand - let's imagine we have a person who is already familiar with the project and its domain. But the pace of delivery is huge, and lots of different contexts can potentially lead to loosing sight on what's important to check or cover. A solution for maintaining the clear perspective in such cases becomes crucial.

I had a chance to work with teams of various specifics. The problem with documentation appeared basically in any of them - only the scale was different :) Introducing the checklists helped me in such situations significantly. For projects where all people were new and we had to build our knowledge - it turned out to be a guideline; for projects with knowledge silos impersonated by few people - helped to track and indicate points where we shouldn’t rely only on obviousness. And numerous times when using them as test reports simply saved my as*, when the world around was burning. The solution is not ideal, and sometimes may be tricky - especially when we want to have “too much & too well documented”, but at the same time - I can’t imagine working without it. It’s only a matter of adjustments to the project’s needs.

I’d like to show a solution, that turned out to be flexible enough and has been used when I had been working with several different teams - with all the pros, cons, and lessons learned.