A fairly common understanding of us QA people is “… well these are only a bunch of people clicking some links or running some odd tests at the very end of the development process before new functionality will go-live”. Arrrgh, so you also belong to this crowd? So make up your mind, either you can leave this blog and continue life with your prejudices or you keep on reading and broaden you horizon about the real world of Quality Assurance (QA).
How do we define our work?
Well to phrase it in one sentence: “Quality Assurance is an integrated part of the Development process”. What does that mean? Quality Assurance is not restricted to pure testing at the end of a development phase. So it is not like development is done, they throw their stuff over the fence and the QA guys try to make the best out of it. Guess our approach will become a bit more obvious looking at the following diagram.
First at all, to avoid any misunderstandings, our approach is nothing brand new. I worked in a lot of projects where this was standard procedure but at the same time I know that there are even more projects which are run completely different. So when you look at the typical development project it includes four major phases which can be divided into:
Requirements > Implementation > Test > Rollout
As you can see in the diagram the interaction of the QA team already starts at the very beginning of a development project.
QA people should get involved during the requirements definition/gathering. Why that early you may ask:
- A rough scope of required test cases can already be determined. This allows to think about any methods and tools required for the upcoming tests.
- QA could provide feedback/input for additional required development activities. For instance it might be necessary that development provides certain functionality of an application which is outside the actual requirements but which facilitates the QA team to run specific tests like faking interaction with another application or being able to manipulate data transfer etc.
This was extremely important for the QA phase of the Subscription Program.
Phase 2: Implementation
Once the implemention kicks off the requirement documents should be more or less signed off and hence the full scope of the new functionality is known. This allows to create a test plan which specifies the scope of test activities and dependent on that necessary test methods will be determined. Furthermore a detailed specification of the identified test cases should be done.
The percentage of specified test cases at that stage in relation to the actual needed ones really depends on the quality of the existing requirements documentation. In case that these documents a very detailed and cover most of the use cases of the future application a fairly high percentage (> 80%) of needed test cases can be specified at that project phase.
Phase 3: Test
The development has been completed, the new functionality got deployed to the Test system and hopefully the application still comes up. Well that dependents on other fairly important quality measures which might be worth to mention in another blog. Ok so lets assume the new application is ready to be tested. The QA team will execute all specified test cases and along with that task missing test cases are normally identified and will be added.
During that phase the new functionality should be tested under all functional and if required non-functional aspects. Depending on the scope and complexity of the new functionality this phase can take up to weeks/months since several iterations are necessary till the predefined quality (or the go-live date) is reached. During this period there will be cycles which consists of:
Deployment > QA Iteration > Bug Fixing > Deployment > QA Iteration > …
Phase 4: Rollout
The big day arrives and the new functionality will get deployed to the productive environment. This does not mean we as the QA team are done. After the deployment we run at least a subset of test cases which have been applied during phase 3 to make sure that everything works ok.
Since we are dealing with software there will be of course still bugs in the system (most of the time only minor ones since we are doing a brilliant job …). The required bug fixes will be scheduled into monthly releases – or if necessary will be applied as hotfixes which is not that often the case – and we will find ourselves back at phase 3.
This is a brief sketch of our existing general QA process. We made fairly good experiences with this approach and I guess it shows its benefits since there are not that many bugs out in the system which you have to face.