Quality ≠ Testing. OK, so this isn’t entirely true, there’s a lot of testing involved in ensuring quality no matter what field you're working in. Still, in software development when someone says quality, most people immediately think of testing the code, either automatically through things like unit tests or manually with a real person at a keyboard pressing buttons. However, if this is your approach to ensuring “quality” you’ve probably already failed!
KOPE works in both the software and construction spaces and in construction you’d never think of waiting until after a building is complete to test it. The cost of the building failing post construction tests, and possibly collapsing, are too great to even contemplate and therefore a huge amount of rigour is applied to testing the designs for the building and ensuring that all scenarios that could affect the building are accounted for. For example, does it have to withstand the sea, hurricanes, earthquakes etc.
For some reason this sort of thinking is often thought of as “Anti-Agile” in the software community and therefore bad. Companies strive to be seen as “Agile” and any work before development begins is seen as waterfall or not LEAN. Agile is a mindset not a specific list of activities, it is about using information as it becomes available to make decisions fast and not being too beholden to previous decisions, it’s not “planning is waterfall and therefore we don’t do that”. By taking this approach quality is pushed down to the post implementation stage and therefore becomes remedial and incredibly expensive.
What is Quality then?
Quality in software development, like most other disciplines, is about ensuring that the best outcome is achieved at each stage of the process. A flaw not implemented is far easier, and cheaper, to resolve than a flaw in a finished product. Everyone involved in the delivery of the software product needs to be empowered to call out quality issues at any stage and for them to be taken seriously and ideally there needs to be at least one person involved right from the beginning of the process whose primary responsibility is to represent quality and search for issues.
Missing requirements (both functional and non-functional), logical flaws, unconsidered external factors can all seriously disrupt the development process if not caught early enough, an empowered quality team can enable developers to pick up features to implement, confident that they are truly ready for development.
What about Testing then?
By clarifying that testing is not about trying to break the final product but instead about validating assumptions and decisions along the way, we show that the “Testers” are always engaged with the team, indeed should be part of the team, and run ahead of the developers testing designs, producing test-cases for the desired product before it’s implemented and finally executing those test suites on the delivered product. The idea of quality assurance being a separate team isolated from the process where completed product is thrown over the fence to them should therefore be countered wherever possible.
Where does security fit in?
A good mantra for this is, like quality, “Security is everybody’s responsibility!”.
Some businesses may have separate security teams, either for physical or digital security (hopefully both) and it can be appealing to say that security is their problem. However, they aren’t the ones writing the code or reviewing the product requirements and generally can only catch security issues after they’ve been written (and potentially deployed). This is again very expensive in terms of remediation and potentially opens the product and company up to attack until remediated.
By making security part of the quality process and getting the team to do proper risk analysis as part of a secure software development lifecycle, this makes the development and product teams more aware of the wider impact of their initiatives and reduces the likelihood of major security or quality issues reaching the production environment.
In summary
Quality management or quality assurance is often seen as a cost, something that slows down progress or gets in the way, however in reality if applied correctly and early it can save organisations vast amounts of both time and money, and, depending on which industry and domain, potentially save lives too.
