Head over to the new site over at letstalkabouttests.xyz!
If you asked me what I do, I’d say QA and testing. I wouldn’t say I do QC, though I almost definitely do, testing, after all, is part of QC. But I do far more QA than QC. QA is a process, from the start of the project, all the way to the end, not a hurdle to be passed over to get the product out the door.
Sometimes, when working with developers you get a very ‘over-the-wall, done’ feeling from them. They’ve done their bit and now they don’t have to think about it because its with you. Which generally I put down to a workload problem, or a lack of communication and team problem. I can’t do anything about the workload problem, but teamwork and communication? I can try to help out with that.
So ideally, when approaching a project, you need to go about team building, and not in a ‘trust fall’ or ‘human knot’ way or any other weird activities, but getting a team to communicate and work together well.
Bringing the team together early in the project, to plan, set up, and prepare, even if its a short kickoff meeting, means that communication can start to happen when the team may be apprehensive, but not stressed is the first step. And it sounds obvious but just a quick meeting of, this is the project, this is how the sprints are structured, this is the team (with intros if necessary), this is what we’ll be doing I find just breaks that ice a little bit.
Ideally a intro to the client by the PM would happen as well, just to bring everyone in on the loop and recognise names and roles. Simple stuff but it works.
Sprint planning is a great way to get everyone in on the act of QA – once AC is written up, the devs (all, or most relevant to the work, depending on team size) could look over AC before it hits the client to make sure the that the devs are on the same page as the tech lead and that all the devs are on the same page as QA.
This process also works when coming into a project that’s started already, or providing new work on a completed project. You can start your QA processes around a new sprint, and start planning there, which I think helps with getting the QA in as a team member, because sometimes that can be daunting, especially if you’re not a coder (remind me to tell you about my imposter syndrome sometime).
This week I sat down with some support devs to go through some of the new processes with them, because we’d finally got the processes down how we wanted them, and I wanted to go through and make sure they got what we wanted to do, and why, with examples of why we want them to follow this process. It seemed to go well (though that might be partly related to the chocolate cheesecake brownies I baked for the meeting?). And I really enjoy good process, so I enjoy explaining it, and I know if you don’t know why you’re doing a thing, you’re likely not to do it, or realise the process is there for a reason other than hoop-jumping, so you’ll do it grudgingly.
Another way of incorporating QA into the team is that we can act as proxies for the product owner in times when a quick, not business-critical decision needs to be made. This can be ‘use this and see if it’s intuitive enough or the help text makes sense’ or ‘what would you expect to see here’ or ‘we need a name for this’. Depending on the set up of the project QAs can also triage bugs coming in from the product owner and feedback there, or improve the bug report if needed.
The idea of QA is to oversee and implement processes to help the team make better products. Its not a step that’s done at the end of the build process. Hell, QC and testing shouldn’t be done at the end of the project, it should be as iterative as possible, but that’s still a step – this has been built, so lets test’. But I think QA, and getting everyone involved in the process is the best way to get everyone to buy in to the QA process, which leads to better work from everyone.
As the slightly out of date reference to a killers song that is the title suggests, I’m talking about humans and testing.
This week I discuss eBay UK’s announcement that they will not be supporting or adhering to ISO29119.
Episode Two: Acceptance Criteria and You
Here we go, episode one! 😀
This episode is partly based on a talk I gave at MCR Tech Nights earlier this year. I had a lightning talk, which was five minutes, but I crammed about 20 minutes worth of talking into those five minutes.
I say partly based as episode two will cover Acceptance Criteria in detail, and this will cover another portion of the talk.
This episode covers:
- A quick intro to Agile and Scrum
- Sprint Planning, Acceptance Criteria, and QA’s role there
- Other QA roles in an Agile/Scrum team
The slides and notes from the talk I gave can be found over on my blog here
Drop the show an email.
Check out the Soundcloud page, or subscribe to the show on iTunes or whichever podcast programme you use. If there’s a podcast programme that doesn’t have the show available, please drop me a line and I’ll get on submitting it there!
Please rate and review the show on iTunes if you enjoyed it!
Theme music credits:
“Itty Bitty 8 Bit” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
This is not an episode. This is a prequel to episode one.
Show notes: None. Join us on Thursday for the first full length episode! 😀
Drop the show an email.
If there’s a podcast programme that doesn’t have the show available, please drop me a line and I’ll get on submitting it there!
Please rate and review the show on iTunes if you enjoyed it (hopefully the iTunes overlords will approve my podcast by the time this goes live!)
Theme music credits: “Itty Bitty 8 Bit” Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 http://creativecommons.org/licenses/by/3.0/