What is QA though, really?
The following is a series of tweets from our founder and managing director, Jason Imms.
I’ve been talking a lot recently about quality assurance, with the launch of @TheMachineQA. But what is QA, really?
Most people tend to agree that in software development, QA is mostly testing. And that’s true! But it’s not the whole picture.
Testing is a huge part of QA. It’s the way we confirm whether a system is performing as expected. It’s a method for measuring completion.
But, there are a wide range of QA activities that inform and support the testing effort, increasing its effectiveness and project value.
For many small software developers, testing happens at the end of a project. It’s a question of budget and prioritisation of tasks.
And that’s fine, better than no testing at all! There are ways last-minute exploratory testing can be managed to make it more effective.
But, what does effective testing look like? What is the primary output of any good testing effort? It’s bugs/defects logged, right?
Only kinda! Logged bugs/defects/issues are a by-product of the testing effort.
Sure, each bug logged and fixed is one fewer for your end-users to deal with. One fewer negatively affecting your brand.
But without test planning, exploratory testing can’t truly speak to the health of your project.
A well-designed testing effort asks questions about what your project *should* look like. Test execution tells you whether or not it does.
After completing testing based on a well-designed test plan, you should have a report that clearly speaks to the health of your project.
So, if you leave testing to the last minute and your test report says your project isn’t fit for release… what do you do next?
You end up pushing your release, upsetting your stakeholders, and casting a lot of doubt on the entire project.
But, if you plan testing from the beginning, make it iterative, and train your QA staff to help take your project’s temperature throughout?
You’ll be able to spend your contingency money wisely (or avoid spending it!), release on time, forecast issues, and be confident on release.
Plus, your programmers will spend far less time post-release on fixing defects, because, well, you’ve already found most of them.
When issues are logged professionally, interruptions to your programmers and time lost to verification and investigation are greatly reduced
It’s hard to clearly quantify the financial benefits of QA, as it changes with every project. But good QA always results in a saving.
Whether it’s time saved on fixing defects early, identifying and avoiding risks, only releasing when confident, or any number of other ways.
*Any* money you spend on QA will improve these things. It doesn’t have to break the bank. Testing is only a burden if you don’t plan for it.
We’ve built @TheMachineQA to help developers find their way in this complicated area, and to customise QA plans to suit their budgets.
Get in touch today for an obligation-free chat about what you’re making, and how we can help you make it with confidence! http://themachine-qa.com/