We are planning to build QA in a Product team. Currently in few products QA is performed by Po’s and dev. For QA’s to start
What would testing team need from Product team/owner?
What areas should should testing team focus on?
where to manage test packs/plans?
4 Likes
I’m in a similar situation and I noticed these things to be important:
What would testing team need from Product team/owner?
- Knowledge mostly - of business, product and project history, risks, details on their testing, operations they might be doing instinctively, product interfaces, known limitations or bugs; It should take weeks for a simple product, years for more complex ones(from a specific company I heard they expected a person to need at least a year to understand the context, a few more to be reasonably experienced).
- Tools they might be using; documents, references to internal or external resources, guides, tickets, collections of API calls, scripts, macros/formulas, pipelines, etc.
In a new place, many things are implicit with experienced people. About 90% of what they do or know you won’t get easily - pair, observe, ask many questions, explore, experiment, ask more. - Tasks, responsibilities they expect you to do/have; some of them you might be surprised, but they aren’t about testing.
What areas should should testing team focus on?
- That’s up to the Management, Development Team, and Testing team to uncover or underline the risky areas in your specific product & business that require the most attention;
- What’s the goal of the company? of the department? of the team? of the business? - sell more, build more features, deploy faster updates, reduce costs, get more client satisfaction, reduce technical support cost, automate some people’s jobs, beat another competitor product in terms of quality, understand the quality of the app better to not be embarrassed during product presentations…?
where to manage test packs/plans?
- See what’s already being used;
- Get reasonably comfortable in doing what the people doing the testing before were doing;
- Understand the mission that you have for the testing;
- Evaluate the time available to achieve your mission, skills necessary, approach to reach, strategy to guide you;
- See the experience and expertise of the testing team, as it can influence the amount of guidance and scripted/written documents;
- Have a chat with your manager, what reporting do they expect, how often?
- Understand what’s useful for developers as well (report by a chat message, a call, a drop-by her desk, a comment in git, etc…)?
- A tool would be the result of knowing what is required of you, and what is missing for you to achieve your job.
3 Likes
Hi!
- I would start with an high level architectual overview - the PO should know what the business should do
- Then the team should do a risk storming (or another kind of risk analysis but in a workshop with min. the 3 amigos (business people, [operations people], code developers and testers) are in that workshop) to find the black holes which risk have not been mitigated by tests now. From the result you get the answer of what to test next (test strategy)
- Take care on the non-functional aspects (use ISO 25010 as a inspiration paper)
- The artifact from that workshop should be a test strategy and a test plan
- From the risk analysis workshop your team will get the input which quality aspects are most important to get the product done (=where are the high risks to fail).
- Get the team into quality and test techniques. If they have low knowledge, try to give them the basics to get their work for the team also checked by themselves. Mob/Ensemble testing, test pairing, makes sense to get all on board to test with fun and reach an acceptable quality the team is happy with.
- Everything should be transparent for all members - use a Wiki, a task management system - whatever you want and the team is familar with but make it open to all and create a summary page that everybody, including management, can see the status of the activities. You do not need a status meeting anymore if everybody can see it live.
- We use Confluence in combination with Jira queries to get that done. The tool is not the key, the outcome is it: Make it open for all.
Feel free to ask more 
Yours,
Jogi
2 Likes
Would a tester be able to make any useful suggestions for a test strategy/plan after just 2 meetings as you’re suggesting?
Shouldn’t the tester be the leader and advocate for dealing with most of the risks that she/he finds by learning first about the context of the business, product, company, or technology?
With a testing approach that is led by anyone else but a knowledgeable and responsible tester, I’ve seen about two dozen failed testing projects, and about 6 poor-quality products as a result, with failed deadlines and some heavily over-budget.
Moin,
It is a team play not a tester-fits-it-all We support the teams more if we use the ressources instead of being the ressource. The tester will learn in ongoing job where support for identifying risks is needed, especially in the risk storming session ideas from testers are very welcome.
That’s why the tester is with us right from the start and provides methodical advice. It makes no sense to leave the responsibility solely with the tester. It has to be a team task - that’s how we do it and the results look very good. We have training courses, instructions with examples and templates for most things and, if questions arise, we have a short session and clarify open questions.
Quality scales exclusively through the team.
Yours,
Jogi