The Importance of QA in Software Requirements by Julian Flaks

Modern software engineering puts high value on unit and integration level testing of code. In some organizations, the strict (and sometimes misleading) metric of code coverage is held as the de facto proof of code quality. The details which code tests choose to dig into are driven largely by how developers approach problems and the way they break them down. Quality assurance (QA) will often test things from a very different perspective and at different levels, and will do so with much influence of innards of the software implementation. Accordingly, it's important for QA to have strong involvement in software development at all stages.

In traditional waterfall projects, QA might get involved from the start of the project, planning the verification stage of the software development lifecycle before the requirements were accepted and used to build. In agile processes, this closeness of QA to the project should be easier. Flexible and changing requirements taken on by a team constantly checking its own progress and adapting should allow for QA to be constantly involved and able to quiz a product owner on their intentions.

However, it's easy to end up with the opposite. In many agile situations one can find QA teams seeking reassurances around when they might get first exposure to a new feature, to avoid themselves becoming the latter stage of a mini-waterfall squashed into a small sprint timeline. When this moves to QA running in an offset way and testing code delivered in a previous sprint, the team as a whole can splinter more as QA struggles to catch up with work from which the development team has moved on. Further, developers involved in backlog refinement conversations or spikes can be building a picture of requirements in their minds when QA aren't properly represented, again because timelines make it logical for testers to be getting through tickets.

When QA is introduced late to a problem, it can present a number of difficulties. Developers may have to help them write testing tickets because diligence around written requirements was circumvented. Once test cases are considered in detail, already-developed features may be found to have logical gaps that did not occur to either product owner or developers, at which point there may not be a source of truth as to whether the software developed does or does not match requirements. This can be a process equivalent of the inefficiency which coders face with unit testing, if they write complex and complete code first and only think of how to test it second.

When QA and development collaborate at the right level, the benefits are enormous. The additional diligence around requirements lends itself to easier documentation of what is built. Strong requirements allow code to be written closer to its true requirements the first time around, rather than tweaking a mistaken design. Once software written this way enters the maintenance or enhancement stages, the sureness in the team about the logic of the product makes future code edits a more pleasant and structured experience.