There has been a lot of chatter recently regarding QA and the role it plays in security testing. Hashing this out over Twitter with 140 characters per post just makes things more confusing. While I think that Twitter helps start some of the most important discussions, there is a need for other mediums to expand on the topic. In this series of posts, I want to take the opportunity to bring up some of these topics and hopefully expand on then a little bit. We all have our opinions and we will certainly not all agree on everything, however these are conversations we need to have.
What do you think of when you hear Quality Assurance (QA) mentioned in a conversation? Is it just a process that documents or processes go through to make sure they are sound? Do you think of that group of people that test applications to make sure they function as they should? It is important for everyone in the discussion to understand the context in which the term QA is being used to ensure everyone is on the same page.
As mentioned above, there are a few different things we think of when we hear the term QA. The one that comes to mind the most to me is the team that tests applications or software to ensure that they are working properly. Most likely I go this route because I come from a lengthy development background and that is the QA I mostly dealt with. This QA team is responsible for identifying bugs in the system, documenting them and getting them back to developers to resolve them. This team is engaged after software is written (well, during the iterative development process) and before it is released to the production environment. Even this group can be very different between companies which I will talk about in future posts in this series.
Other people when they hear about QA think about a different group (most likely) that is responsible for reviewing documents and procedures to ensure accuracy. One example of this is sending requirements or design documents through a QA process to ensure they are correct.
Of course there are other types of QA, but those are the two we will focus on throughout this series. If you have other examples, please feel free to send them my way on twitter (@jardinesoftware) or james@jardinesoftware.com. The more we start distinguishing the context we are discussing the more we can get done by cutting through the confusion. Defining our context is a critical first step.
In the rest of this series I will dive into the different types of QA and how they relate to security. What role can they play. What should they be able to do and what should they not be able to find. Can QA find security flaws? Follow me on this short journey to see what we find out.