Sara [10:22 AM]
It’s quite faschinating how much the role and identity of being a Tester has changed. I’ve had to change a lot in my “tester identity” these last 10 years.
Sara [10:22]
Maybe I’ll write a book about it some day 🙂
Christoffer [10:23 AM]
Yes, do it! 🙂 What would you say is the biggest change?
Sara [Today at 10:56 AM]
Answering your question @christoffer (and trying to keep it as concise as possible, obviously failing).
My personal path was somewhat like: I started as a developer’s right hand, testing ready code, then moved towards being a tester in agile team, then test lead, then worked on a high level defining quality strategy on organization level, and then returned to the hands-on.
And as for the tester identity change per se (the way I’ve seen it which is 100% subjective), I think there was a very interesting metamorphosis the last 10 years. Testers did not want to be the “passive receivers” of developer’s work anymore, so there was a lot of talk about being an inspiration/guide/ambassador of quality. And that time created plenty of “empty” testers, the ones without strong knowledge and expertise, but with an ambition of some special knowledge and (at last!!!) power. This attitude couldn’t possibly sustain itself long. So naturally the emptiness started filling up with real expertise. But this time it was important to become an equal player of the development process. Which means testers having their own domain of expertise and at the same time share it with everyone else in the team. Not an easy task. But we seem to be managing.
Christoffer [2 hours ago]
I notice it’s very common that people struggle in teams between having special knowledge which entails being responsible for all work requiring that knowledge and the teameffort requiring everyone to share/contribute their knowledge and expertise but not necessarily doing the work themselves.
Christoffer [2 hours ago]
I guess it boils down to making sure people with special competence feel like they contribute even if it’s not their hands on the keyboard all the time?
Sara [2 hours ago]
I guess it’s one aspect of it, yes.Another one I see is somewhat different value attached to different skills. For instance for developers the value is very clear. Code = product. Easy to see and measure, easy to be proud of. For the tester it’s a bit more tricky, because good product quality is not equally straightforward and rather undefined.
Sara [2 hours ago]
And in itself testers best effort manifests in helping an organization and a team produce better quality. But just “helping” is not enough, it’s not fully satisfactory, it’s a group result. One also needs some individual result, and this is what testers are searching for — how to have impact on both group- and personal level.
Sara [2 hours ago]
IMHO 🙂
Christoffer [2 hours ago]
As a developer I used to think that too. Code = product. But as time has passed I’ve realized that Code is at best product. In a lot of cases it’s not. And that’s where developers today should feel like the testers you describe above as well. Is the work I’m doing adding value? Is it solving someones problem or am I creating more problems?
For good developers product is not necessarily code. Good developers solve a problem for someone. And testers can help them understand that problem by framing the problem in a way that’s understandable for both developers and the problem-owner. Using scenarios, scoping and challenges of ideas.
Christoffer [2 hours ago]
However, developers have one tool that give them instant continuous affirmation. The red/green bar of a unit/integration test. For testers the affirmation is harder to find, like you say.
Sara [2 hours ago]
Interesting about the developers point of view! We continue after lunch 🙂
Sara [1 hour ago]
“Good developers *solve* a problem for someone. And testers can *help* them understand that problem..” — exactly my point you replicated here. There is a big gap in terms of satisfaction between “solve” and “help to solve”.
Sara [1 hour ago]
So I think both linguistically and empirically we’re aiming to “developers and testers *together* solve the problem”.
Christoffer [1 hour ago]
Sorry about that sloppy writing. My thought is good developers help someone with a problem or help them realize an opportunity. Sometimes they solve it for them with software but very often they help the person or organization realize it’s not a problem to be solved with software but rather it’s a tweak in process or just understanding the domain.
Christoffer [1 hour ago]
I agree with your second note!
Christoffer [1 hour ago]
totally
Sara [1 hour ago]
Mhm, I see what you mean with problem solving/sorting as part of developer’s job.
Christoffer [1 hour ago]
Much like the testers job of identifying if the software actually solves the problem or if it makes it worse.
Christoffer [1 hour ago]
Our different competences aside we are very alike in our aims and struggles.
Sara [1 hour ago]
Yes 🙂
