I work mostly in start up companies that are scaling up QA. Often teams have worked without QA for a year or two and are loving the freedom, then one day I turn up and start to put some kind of quality processes in place. Most of the time, teams are OK and are very helpful but sometime usually some of the âold headsâ can prove to be quite stiff to change.
Multiple ways I have won the battles have been:
Involving team members in QA Documentation drafts
Getting to know them a bit better before making changes
Little and often changes rather than a Big Bang that makes people put the breaks on
Showing them insightful metrics to show them their actual quality of their work. Yes you got 30 tickets to done in a sprint but if 60% get rejected you have wasted a lot of time
Whats is everyoneâs key tricks when dealing with difficult team members when introducing QA to teams?
People often say that devs donât like QA but itâs actually just âchangeâ
The key role here you need to perform is Change Management, which is probably 75% of any QA his job. Iâm a consultant and mostly the problem isnât âdoing QAâ itâs just change.
I sweeten them a bit up with pastries in the beginning, get them to love me and then add automated tests to the pipeline and bang!
Nah for real, like you mentioned yourself; getting to know them helps. Starting small, not only introducing a ânew thingâ but also explaining why itâs better the proâs and cons.
You can always try to say â we can try it, if it doesnât work, weâll throw it awayâ
Youâre absolutely correct, Ive seen some really good Senior Testers that know a lot about testing struggle with the change management and the QA side of the thing starts to stall. It is defiantly a skill to manage the change as well as selling the QA processes to the team
Prior to reading it, I would always race ahead to the âLetâs get to here cos itâs betterâ bit. And it definitely helped when I started to use what Esther describes in a chapter: âHonour the Past, Present and Peopleâ. Respecting the current paradigm and context made a positive difference.
Definitely a journey we will all take even if we never work in a startup, whenever a brand new product/SKU comes out, the test team get involved a bit late. The trick is to not gatekeep, but to rather seek those friction-reducing changes that get you all to your first public release sooner. Observe and help out in the release and deploy and then iterate over patch releases with small improvements in any release/deploy trouble spots. Also by attending every splint planning and attending the sprint retrospective and having good concrete suggestions to add in the retro.
Practically, that means retesting bug-fixes as soon as possible and closing them, or asking for help to close them, that earns you brownie points for sure.
Adding to this, I think itâs important to spend a lot of time assessing whatâs currently being done, and then figure out all the little things that will help foster a culture of quality.
The job isnât to make sure all the code works; itâs to help the team be confident that their code works and keeps working. Fostering that culture of quality usually means lots of small tweaks, where the team eventually owns quality, as opposed to relying upon a third-party to verify their product.
Ha, as usual @ernie has said it more clearly. Give devs confidence that bugs wonât escape. It lets the whole team mover faster when unknowns slowly get nailed down and removed.
A good way to introduce yourself and QA measures would be to find a few bugs to prove your worth. Look at previous bugs, are there patterns? Then look for these patterns. Try to fit yourself into the existing processes (one can always widen the processes afterwards if they are lacking), try to be stealthy when fitting you and your QA measures in. At the same time, try to take part in as many team meetings as possible, retros, dailys etc. And most of all: be a positive, helpful colleague, testers are usually considered a bit of a nuisance, the guys with the checklists. So prove them wrong.
Why are things being set to Done before QA has taken place? A better approach would surely be include any QA in the ticket itself, therefore nothing is being ârejectedâ just âreworkedâ as part of the sprint.
What is the organisation like in terms of âblameâ? Does someone get it in the neck every time something is ârejectedâ or do people act like adults? (Sorry, previous experience of working in an organisation where every time we found a defect the senior manager would start yelling at people!
Is the main reason that the QA person needs to be sure to get invited to the sprint planning meeting, the grooming session, and the retro. If the devs are not doing those 3 things by one name or another, they are not agile yet, and you are better off talking to the release manager and the PO than talking to the devs about process attitude. We all know that in agile a ticket is not âdoneâ until it is with the âcustomerâ, the customer could be the ops-team, but if the customer is the tester, then itâs not agile. Bring out this chestnut Definition of Done | Agile Alliance . Itâs almost worth an entire retro half hour, to get this defined and agreed in your team.
Once you get invited to a retroâŚand donât get me started, retros are the first meeting that gets cancelled during release closedown, and itâs the most toxic thing a team lead can allow to happen, but anyway⌠the day before the retro write down the TOP 3 things that you did not like and one thing you did like. On a notepad somewhere. Then take one of the things that went badly and write down a suggestion to change and resolve it. Be sure to make your wording as positive, as possible while not pulling your punches. Take that notepad to the retro.
I think it is really time to leave the old era behind. With the speed of how software changes, it is ridiculous to have a development team that is stiff to accept quality assurance, especially as quality is not a one-man-band responsibility but a teamâs responsibility, not to say cross-domain responsibility.
I know it might happen even more often to come up to such a fellow developer though.
I donât have specific tips and tricks for dealing with such, except just doing my job, being my best and showing them results. No better motivation than just showing something gets better in time, despite the pain of discussion and all work around found bugs.
Be persistent! Be communicative and collaborative. Donât take it personal. Simple as that.
Keep in mind also that in order to achieve anything as a QA person in charge, you should also have the management support and clear view what kind of and how much resource the company is ready to invest in the quality.
Well said @sassypilot . Last year I also became aware that my belief that teams need a dedicated tester person was a weak assumption, especially when you think about how quality, like security, is every single engineers responsibility, not just one person.
Interesting how this shift has occurred, for me I think when I realized a few years ago, that a huge proportion of software bugs have very little to do with coding. A good spread of bugs cannot be detected using test contracts or scripts, bugs that stem from people communication and misunderstandings. And my job-description has gradually shifted from being
1 (junior) a person who runs tests
2 (practitioner) person who creates tests
3 (senior) person who architects for testability
I still do all 3, but I spend more time talking to devs as a matter of course. Because we are a team, and my job is to help the devs, to petition on behalf of the Users, but never work against the developer.
