Have you ever had that moment where you’ve dived deep into testing a product and then thought, “Okay, now how do I tell everyone about this?” It’s not just about what we find but how we share it. Let’s chat about the fun, the quirky, and the absolute best ways to share all those details from our testing explorations!
5 Likes
Have you tried a debrief?
It’s a discussion following a testing session to go through the good, the bad and the questions you have with a developer. the intent is to share information and decide if something is good enough.
One of the biggest issues I’m seeing with testing at the moment is not making information transparent. Testers who aren’t vocal and don’t share information with teams aren’t helping the team to understand quality. We need to be champions; get out there and share information related to quality in reports / on slack / in meetings!
- Do you give an update on why something is “done” in standups?
- Do you share updates on the state of things in slack channels?
- Do you push reports and test reports and quality narratives into the team?
- Do you speak up and ask questions?
These are the type of things people are coming to expect from their testers in modern development teams. We have to be way more vocal.
2 Likes
We do this through several moments:
- Bi-weekly 'stand-ups with a core tester team, which takes about 15-30 minutes and here we share experiences or interesting things we’ve seen.
- We host evening sessions, where a person comes to explain their project and presents what they’ve done, or even tells us about his struggles and asks for advise.
- We also have training days, where people can present their work during the work hours. (Like a mini-conference)
2 Likes
I talk to them. Depending on the situation it can be immediate or wait for a break.
1 Like
Once I obbserved a user testing an online payment. The amount was shown in cents. One of the developers looked at me with an amazed face. So, I quoted the user: “Now I have to calculated it.”.
During the tests I noticed another advantage of an online payment. Until then credit cards were a lot used in the call center. If a number or name was wrong, then an email had to be sent to get the proper information. This costed time and a delay in payment, The online payment did not have these disadvantages, This observation was unexpected for some members of my project team.
1 Like
I do write a users manual for technicians when having learned a product. The only document testers and programmers later use, since it was written by one who really know the product. They are quite popular among other users too. A true tester sees the product as a whole and do not only dive into bits and pieces.
Thats whats worrying me a bit with this newer trends to automate just everything test, including unstable Front Ends. What are the main driving force for the testers? To make good automation code?
1 Like
I usually keep notes in the jira ticket so I can refer back to that later, and if I have time, I will create an internal wiki page as well.
Realistically, internal wiki is the best way since you will always have new people joining.
1 Like
I find it useful to share what you learned as the discussion leads to questions and scenarios and enhances everyone’s knowledge. Creating wiki pages, giving demos about the features are good ways to pass on the knowledge.
1 Like
+1 on the internal wiki. We have a space in our JIRA confluence called “Knowledge Base” (KB) which is a collection of how-to articles. It usually only takes a few minutes to add a new post and I try to include screenshots and/or links whenever possible.
Can’t remember something I did over a year ago ? There it is on KB
A colleague wants to know how to do something ? Here is a link on KB
1 Like
I add pages to the team wiki. And documents to the How To repository. And anything else that fits the needs of the environment.
My basic rule of thumb is if I have to chase down information three times, I need to turn it into a document of some sort because if it’s sufficiently uncommon that it’s not in my immediate memory but common enough that I keep having to look it up, it needs a reference document.
1 Like
At the end of the day when I see something unexpected that isn’t documented, I’ll reach out to a product partner to discuss and update AC and documentation accordingly. I’ve been on teams that are great about documenting their features, teams that use the test suite as their source of truth on requirements, and teams that don’t track anything outside of their Jira board.
When working on anything with a PRD, I strive to get those unexpected flows and finds worked into the project definition so that they don’t come up as surprises later on.
Realistically, the most common conversation I have is:
me: Hey [dev] you know [x]?
dev: Yeah?
me: Is it supposed to be doing [y]? [attach a licecap recording]
dev: uhh
me: Lets ask [product] and get things updated
1 Like
We share information in stand-ups, through test notes and internal wiki pages. It depends on the situation.
Just wanted to say a huge thank you for all the feedback on this question. It’s helped me to put together an initial task analysis document for the upcoming session: