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.
Let's Talk About Tests, Baby 