A bit of background first. My work has 3 companies across 4 or 5 countries, merging into one big team. This means there’s a bunch of different cultures and processes. Testing and quality approaches had differed from agile, testing throughout SLDC to a bit more waterfall and “test team will pick that up in a few months”. To resolve quality issues two working groups were set up and they put forward strategies, spreadsheets and checklists etc to get the dev teams up to speed with basics of doing QA. Basically write detailed test plans & test cases then have someone ensuring that it is getting done. I hate this approach TBH. IMO writing automated tests, checking ACs pass etc should be part of DoD.
So my point.
Following a re-org I have been taken off my project (testing our older products) and will be our office’s representative for these groups, writing the test plans and nagging everyone “have you put together your automated tests”. Co-incidentally, the people leading the two groups are leaving. To me this sets up an opportunity for me to try and go “whoa there guys - this ain’t how you’re meant to be working with LeSS”.
Does anyone have any advice on how exactly I go about things? Has anyone found themselves trying to make changes when they aren’t the most senior person on board and new to the project?
I’ve booked a 1-to-1 with the new leader of the “QA Champion” group (not someone with testing background) but don’t quite know how best to nudge people in (what I think is) the right direction. Providing my concerns? Talking about how we work in my existing team and its benefits? Offer to run a short talk for the working group?
Or should I just go “OK, I don’t believe that works for the folk in my office so can we just do our own thing?” ?
I’m doing this in the last months.
It’s that easy without much authority.
Maybe that is one point: get yourself support by a authority. Devs should at least know that someone approved your approach and that it should be done this way.
More or less I have this and technically I could go to my boss and tell him who is not collaborating. Which I try to not do, because it would be a worse case.
I’m a single tester to 8-9 devs and can not test everything. Therefore we worked out an approach how we share the work over the whole team.
Often I’m more a test coach or test facilitator, helping with design and doing debriefing, while the developers carry out most of the (exploratory) testing.
It could be better, some buy in more, some lesser.
The thing is that it is responsiblity of whole team. You may guide it as expert, but everyone can help.
I also dropped the whole “write detailed tests cases with explicit lists of steps”.
We note in bullet points (can also be a table or mindmap, it depends) what we think is to test and also note what we found out. During the test execution it happens regularly that we find news points to test.
Often the first testing is more doing a survey, getting used to the feature, before you really dive deep.
Because of this I could get rid of the classic test case management.
We note our testing either in the issues directly (Jira) or in linked Confluence pages (Jira is bad in parallel editing of descriptions, who saves last overwrites all other changes). For some repeating stuff we have test manuals in Confluence which we use as templates to copy, this is what comes next to classic test cases, but it’s just a fraction.
In addition to normal feature"dev+test" issues I sometimes create dedicated test issues for more general testing which is not linked to a specific feature in development.
We do not test to conform something. “All checks green” is not the target.
We test to find problems. Urgent problems will be resolved fast, less important later or maybe never.
How are you about that?
I’m writing and article about how I do any notes in Jira an Confluence without any plugin.
What’s strange about my situation is that I am confident that the devs that I’ll be working with can work and test effectively. They’ll do a lot of the stuff that you talk about. Selling them on testing early, doing exploratory testing and ensuring automated tests are written before a story moves to done doesn’t concern me. Most the team have worked like that for ages.
My challenge is that other offices previously did very little testing so the authority has said “okay, starting now we need to be writing all these documents and have checks all go green”. I get why, but it isn’t an approach that I want to push on my team. I’d rather get other teams following our approach!
Perhaps I should find an ally developer from the office (my manager would be one) to help me go to the leaders deciding this stuff.
This is a tough point as its very personal. A lack of trust the previous offices created.
I see the current solution in place “documents with green checks” as makeshift by the authority.
They should not have to care for this depth of details.
I second you in your approach to get rid of it.
Therefore I recommend you to be well prepared for this. Maybe do not demand an immediat decision, but prepare people upfront. Make the used to your ideas, getting slowly more and more agreement, so that at the final decision round its just a matter of making official what everyone has agreed on unofficially. Create slowly a consent.
One “trick” would be to phrase it more as a experiment they could theoretically finish any time.
“We want to try this and we could switch back at any time”.
If the pressure is to high to keep the current approach, also maybe can sneak it in.
Make the minimum to satisfy the official approach and do internally your own. Or at least ad yours slowly.
In addition you change slightly the reports you deliver, by improving them with more information from your approach. Showing with concrete examples that yours is better.
Another thing is not to concentrate to much on the concrete reports (maybe still doing the official one + extras), but bringing up important topics to be discussed.
By my experience once the management has concrete topics to discuss they don’t care much for the concrete report.
Distrust is a challenge, but a manageable one.
I hope this helps you.
This all relies on the concrete persons and the relations. Therefor I do not see how to give you a more detailed advice.
I really like the experiment idea. I’m pretty sure that this was part of the LeSS (large scaling scrum) training that we had.
You make a great point about going in too strong or trying for something immediate. Perhaps guiding towards a more “longer term strategy” once the next big release is out (due in Dec 2020, Q4 2021, def Q2 2022, certainly Q4 2022, no later than Q1 2023, well maybe Q2 2023).
Two last generals advices I follow:
- Work underground as long as you can (so you are well prepared when you need to stand you ground officially)
- Ask for forgiveness, not for permission.
(Doing both responsible!)
I wish I could reply in more detail - hopefully I can in a few days (I have RSI in my hand. limiting typing).
Some really key questions which will help us and hopefully you.
- Who are you engaging with? Should you engage with more?
- How are you engaging? One-on-ones? Big group sessions?
- What ‘low hanging fruit’ can you win some gain on long term?
- Have you identified big wins you can make? What’s stopping you implementing them? Will they take time? How can you break them up to implement?
I’m a product owner for testing, and I have a whole series of conversations constantly with my team, with developers, senior management and even parts of the business. It’s a constant engagement & listening. But I’ve also been places where people have felt this is NOT my job, even though they see the benefits (which always make it a hard sell).
I’ve also learned through a process of self-discovery an awful truth. There are places which will moan about the process of testing, but they ABSOLUTELY do not want you to change anything. Usually it’s a vendor environment and ‘it’s all broken, but we get paid by the hour to provide broken’.