Quality Assurance in Software Development
A QA engineer walks into a bar. Runs into a bar. Crawls into a bar. Dances into a bar. Tiptoes into a bar. Rams into a bar. Jumps into a bar.
— Adrian Zyga (@VolPL) September 4, 2013
Quality assurance separates great software from the remaining sea of hopelessly buggy and detrimentally bad code. Quality assurance separates serious code from academic code. Quality assurance separates ideas from businesses. Quality assurance separates success from failure.
If your startup does not take quality assurance seriously, you will have a subpar outcome. I’ve tried to explain some of this before in comparing messy code to messy kitchens.
A lot of great quality assurance technology exists to facilitate robust software development practices; we like Jenkins. These tools automatically apply the unit tests you write to the code you commit. Done right, your tests will provide comprehensive coverage of all potential use cases. The tests will reveal bugs before they are released into the wild.
Quality assurance testing includes checks for:
- Does the code build? Does it build on all the target platforms?
- Does the code return the correct answers? Does it return the correct answers for all the different kinds of inputs (e.g. different sizes, shapes, and types of data)?
- Does the code perform well (i.e. how fast does it run)? Or did you introduce something that has degraded performance?
- Are all the visuals, GUIs, and displays accurate and responsive?
- Does the code exit properly and clean up after itself?
- If present, does the software licensing system work for all the variants of licenses?
These are just some of the checks that must occur to ensure robust software. Open source projects rarely do a very good job at covering all these bases because it requires a special kind of motivation (e.g. money-making motivation) to pay that close attention to the nitty-gritty-yet-vital details.
What are your thoughts on the importance of quality assurance?