Looking for advice on helping overhaul strategy

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

:raised_hands: 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