There are frequently questions across the various slack channels along the lines of:
“I have a meeting with my boss tomorrow to discuss the goals of the QA/Test department. I don’t know how to approach this meeting or what to say, can anyone help?”
The most recent of these, the person asking was the sole tester for the company. They felt as if they had been winging it so far and doing both manual and automation work. They were confused about how to prepare for the meeting and what goals to set.
Let’s start with that situation, what suggestions would you give this person?
If the person asking was from a company with a larger testing team, would you modify the advice given?
Yes, I think the size of the team impacts the goals you’d want to achieve. The overall aim might be the same but the level of what can be achieved will depend on the number of people within the team.
We talk about goals for our team and often it aligns with what the goals are for the company and department.
So,
What goals do the team have which are internal to them?
What goals do the team have which contribute to the wider departments vision & goals?
What goals do the team have which contribute to the wider business vision & goals?
Whether you’re a team or an individual you’ll know where the areas of improvement are for your team/role and also where other stakeholders would like to see improvement from you.
We use the OKR model which means we have high-level goals and then from those come actionable and measurable actions/targets.
I think it’s good to have goals broken down into short, medium & longer term. Say 3 month, 6-12 month and 12 month onwards.
The other topics to consider are the types of goals. For example, people development, testing methodology, product knowledge etc.
Hi Heather.
You can approach it differently and mostly it differs on the environment. So it differs for start-ups flying high speed and for older bigger companies.
What I did some time ago in the start-up I’m working for was the exercise where we defined how would ideal world looked like for testers. We were 5 testers at that time. So I know where we see us in future and our goals are set appropriately to achieve it. Of course, those goals need to align with organizational goals. But for us, it is quite aligned.
For a bigger company, you will be in need to buy-in more people and it is time-consuming and sometimes impossible if you want to head to something very different what you have now. So, in that case, I would define “my ideal world”, and it usually is very similar for all the testers. So the whole testing team should speak about it. Out of that, you can identify what can be improved by testers itself and you should start with this immediately. And what needs buy-in from the broader audience and this is the job for test lead to chase for. Usually, you will need to find arguments why is it needed but for us, it was dealing with quality issues on production and we ended up by CEO steering the wheel chasing for the overall product quality instead of feature delivery.
My view is goals are needed for the test team/department to help their overall competence development.
Typically project-work enables the testers to delve into their past experience and employ their learning skills to test the applications in various ways with help of techniques, tools etc. Goals can be set to meet typical project demands like testing for accessibility or employing an automation framework. It may even be to meet customer expectations set for a ‘quality’ application.
I have generally always believed in setting goals to help take the team in new directions to help explore new/unknown, complex areas of testing or aspects that indirectly relate to it. This has been done year-on-year by creating multiple workstreams with each team responsible for achieving objectives like study of automated database tools, getting deeper into ASVS, building apps (to help their development skills) and so forth. We do regular workstream demos and give away awards to motivate the team members.
My finding is that the team has been successful in achieving results and has helped their self-confidence a lot. The team’s overall competence has seen an increase which helps the team cause.
For a lone tester I think the goals for me would be outward facing. Obviously I’ve no idea of context but I’ll try to be as general as possible while remaining useful as ideas.
Be an advocate of testing through pairing, talks, workshops and example
Be an advocate for the principle that quality is everyone’s responsibility through talks workshops and examples
Be visible in the scope and progress of testing through visual aids (charts, Kanban board or similar)
Be explicit in providing attainable estimates to set expectations through analysis and risk based testing techniques
I think for a larger team these can certainly apply but for a lone tester I feel they would need to educate as much as execute. They would also need to be clear on what is achievable on their own, hence the risk analysis to focus on the most important first.
In my last company I was a lone tester for over a year and I definitely struggled with it. Once I got another tester on board I found it easier because I had some breathings space to get my thoughts together and work on my communication methods.
I’m once again the lone tester in my new company and I’ve learned from previous experience that this is key to succeeding as the only tester. It also helps to have a team of great Devs
I’m an automation tester. If, like me, you are in a large “Agile” workforce, your testing role is primarily to support the scrum team, secondarily to support the wider company. So organisational goals around quality get harder to drive from your end. I thus suggest.
Find a piece of work that you are doing well already, and has wider company value. Stabilise it and then share it with other teams with a view to building synergies. Basically finding something you do well, and using it to lead by example.
Find things in the org where teams in the same division as you are re-inventing the continuous integration wheel. Create a goal around these so as to build a common story/methodology. This will drive better test result reporting consistency. Sell the idea as a way to drive down costs.
I have found that the bigger the company, the more often we change the way we talk about pass/fail rates of tests, code coverage metrics. Do not be afraid to go back to basics like a manually populated excel spreadsheet to prove things as a once-off prototype. Longer term you might need to gather loads of detailed historical metrics data, be brave… this brings me to goal idea #3
3. I find that having an Audacious Goal to stabilise flakey automation is often widely accepted if you can come up with a simple dashboard that everyone in the company trusts, and shows you moving towards that goal (or not). Keep it simple though.
If you are using sprints, try really hard to fit testing tasks into the sprint cadence.
