In your team or organisation, who is responsible for testing while you're offline?

🧑‍🏫 Content Discussions
,
1

Please check out my first Ministry of Testing article about handover documents. In the article, I make the case that testing professionals shouldn’t be writing handovers but instead putting in place ways of working to increase quality and share the responsibilities, such that a handover isn’t needed.

So, do you write a handover document? And who is responsible for testing while you’re offline?

7 Likes
2

We make sure that acceptance criteria is clear and filled in and we have test cases for our regression set that are readable for anyone. So the PO can take over and mark the things as “ok”.

Same for the acceptance criteria, and I’m not just talking about 2-3 lines of acceptance criteria. But more like 10+ Happy & Negative Flows for upcoming user stories…

3 Likes
3

I love the idea of having a wiki available and accessible to everyone. Documentation is our testing friend!

1 Like
4

I like your article and work in a similar way. I’m the only tester in a team with 5 devs (previously up to 9).
Especial work I by Responsible Tester from James Bach. In the last instance I’m responsible for testing, but I try to enable my devs as testers as good as I can. By that I let them do some testing and supervise them.
As I have no full replacement during my absences, things sometimes don’t go that well during that time. But it was way worse in the past. Now my devs can handle much more testing by themselves.
I can’t solve having no similar skilled tester in my team by myself. Management has to grant a job offer and the education of people.

Yes, I seldom do handovers. Just of topics I could not finish. Sometimes I work a bit ahead of my absence, especial discussing test plans for tickets in our sprint. At least the high level focus of the testing should be clear.
Partly I do that by this bringing up in you Scrum refinements and plannings. As much as we refine requirements and acceptance criteria, we refine also potential ways of testing the feature (especial driven by risks). But this independent from myself being absent, I want that also for my own work.

1 Like
5

I am the only tester in my team, working with 3 devs. If I am not available, the task still moves to PROD and have to pick it up the next day for testing. We dont have a formal handover process-I just check the tasks the next day and test them as needed. While this isn’t ideal, it’s how our workflow is currently set up!

1 Like
6

Everyone.
I developed an idea in my company. It’s called “dev testing”. We encourage dev teams to work in pairs or in mob programming fashion. When they’re done working on a feature, they test it amongst themselves against the use case documentation 1 more time to verify if they covered all of them.
Following this they ship it for testing which is done by me or the product owner in my absence.

When I’m on a longer leave, I usually write down testing notes and a plan which anyone in the team can follow to do some final checks.

1 Like
7

So in my organization testers are assigned primary projects, however apart from the primary project they are also given KT of all other projects. Also even though every project serves different clients or customers with different requirements, they are being developed on the same boilerplate and hence they have almost the same architecture which makes it easy for testers to work as a substitute in case someone is not present in the office.

Some confluence documents are also created for some operations that might be required to be performed during or after the deployments.

Apart from that screen recording of all the operations of all the projects is created and shared on the organization drive with the QA team so that they can refer as well as new members can also refer for the understanding of the project functionality.

1 Like
8

I’m lucky in the sense that I have a team of 6 testers (including me). But I still totally agree with less handovers more cross skilling, even if its just testers.
So day to day, we try to adopt a “no silo” principle. To make that happen we:

  • keep track on a knowledge matrix. I stress, not an old school skills matrix, but ones the testers themselves maintain to keep track of how confident they are testing different projects, understanding different frameworks etc.
  • Our QA team meetings are all about sharing knowledge and learning from eachother
  • In our sprint show and tell sessions, I encourage the team to use these to demo to the team our testing lessons, challenges etc. still some work to do there
  • We have confluence product/team spaces that useful tips and how to set-up things are documented day to day as part of the tickets

On top of that I’d go further and say from experience, that specific handover documents for when people leave aren’t that effective either. Asking leavers to do that is almost a lazy way to get the leaver out the way writing documents - I’ve done it myself in the past. They don’t really get reviewed either as someone has probably had to pick up the work anyway while you recruit someone else. By the time you recruit someone else, they’re being onboarded by the person that has picked it up or you actually decided to recruit someone different as the person that picked it up wants to carry on with it.

I think the general principle I’ve learnt with documentation is if you are thinking of writing a document that will only be used/read once, don’t write it.

3 Likes