My last post was an overview, but this one will dive into some of the problems I encountered when I was first getting started as the de-facto quality stakeholder and dig into what REALLY mattered when it came to the actual process of QA. Fitting into the development cycle is critical.
Dissect the Workflow
There is no better way to learn the workflow than to follow a feature through the factory and out the door. Make it a priority to see a feature from design to deploy as soon as possible.
Every team has idiosyncrasies that make experience a better teacher than a ReadMe.
When I was hired on my job description clearly included committing actual code so I also had the advantage of being able to make several early commits and deploys that far and away gave me a better idea than just being told. Do this if you can.
Once you know the workflow, agile or not, you can get a better picture of where QA fits. Almost always at the end of a cycle, but often interspersed with development under certain conditions. If your team uses a kanban board, a flow chart, a spreadsheet, or project management software the next step is to carve out a QA section and OWN IT. This is your wheelhouse, and when a ticket or a story enters it it must bend to your will.
Remake the Workflow
If having a QA engineer/Tester/Test Engineer wasn’t part of the teams workflow, or if testing was less of a process that was owned and more of a vague responsibility placed on each developer… then the workflow will need to change. You’ll be the catalyst here.
In order for your work to be effective you’ll need to start asking for things to happen upstream, long before they land in your lap. One of the best ways is to get your hands into the ticket/story system and outline steps that need to happen as that ticket is passed along to a developer. If your lucky like me, buy in from your manager here will be easy and they’ll be eager to help make that happen.
One of the simplest process wins early on was to simply request that every dev write a few short summary of how the feature should work, how it shouldn’t work, and finally how they had tested it.
Now you know how the “Happy Path” was tested (or if it was tested at all..) and you can immediately compare this summary with the feature spec in the story and make sure nothing was missed.
I was very skittish about walking into a new team, a new workflow, a new product, and a new codebase and then starting to make demands to make my life easier.
You need to suppress that doubting voice, ultimately you were hired to improve the product and build a process that makes more stability a foregone conclusion.
At a startup the only constant is change and you can rest easy knowing your changes will be the least of anyones concerns. As long as you explain the benefits of your decisions people are normally more than happy to hear the initiative being taken.
If you’re building a QA process for a startup then you are also the key stakeholder for Quality and by fiat you now have the opportunity to start instilling good habits. Don’t hesitate to advocate from a place of confidence if you know your changes will result in a higher quality end result.
When your team members start to reap the benefits of better quality any prior doubts will be washed away.