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?ā ?
1 Like
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.
2 Likes
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.
1 Like
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.
2 Likes
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).
2 Likes
Nice!
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!)
2 Likes
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ā.
3 Likes