Thunderbird and Quality Assurance

Well days ago I attended a nice talk about Quality Assurance (QA) in Thundebird and Mozilla, given by Ludovic Hirlimann which is in charge of thunderbird quality, so the purpose of this post is to talk a bit of the subjects or points that I believe were more relevant.

If you think about it most of the time in software projects or IT related projects what happens is something like this:

so this is the reason why QA end up being necessary.

The reason why the above image situation happens is due to that most of the times the IT projects begin with someone deciding that some solution is need it, so he starts to write some use cases, then this is given to develpment which understand just half of it so when they write the code it does half of the functionality, so when this code (product) is delivered they deliver something that really isn’t there. This is the time when QA enters, and using the use cases QA creates test cases to assure the software does what it is supposed to do.

When should QA really appear

But QA shouldn’t start at the QA departement, in reality it should appear at the very beginning when you start writting for the project because sometimes when you are writting something half of the context of what you are writting is still on your head, so the person that is gonna read the paper that you are writting gets a bit lost.

So the first quality starts at properly dumping your brain when you are writting the specification of the software. So you end up having a correct list of the things the software is going to do the much clear as possible for the person who is going to read it.

Despite of this there always will be software specifications that are going to be missing or misundestood, so this is the reason why usually the first place where QA end up starting is at engineering. This is where usually unit testings begin.

QA functions

The main functions of a QA department usually are: testing (test cases, maintaing test), manage bugs and singing off (software releases).

About testing well there is part of the testing which is expected but there is some other part which is not. So there are different types of testing, the ones to test functionality and the ones that are used to find errors.

The ones used to find errors are called ‘ad-hoc’, and this are the ones where you want to try to break the software (the ones where you have more freedom to interact with the system) and try to find the edge cases. Once you find this edge cases then you’ll have to fix them and become them into test cases.

And finally there are the unit testing which as they are described by there name, they are used to assure that a function does exactly what is supposed to do. These ones should be done at every build. One problem with this tests is that sometimes they have to change when functionality change, but you don’t notice it so you have to always check this when bringing new functionality.