Skip to Content

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.

 

QA Process 

 

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.

 

 

Phase1: Requirements

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.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Thomas Alexander Ritter
    Nice guide to one of the standard ways of doing QA. My question is do you incorperate developer testing (unit testing) and does the QA offer the developers (who have less test experience) any support in that matter?
    cheers Thomas
    (0) 
    1. Folkert Eilts Post author
      Hi Thomas,

      we do indeed incorporate unit testing and furthermore also integration testing in our overall QA approach. Whenever applicable we try to encourage developers to implement unit tests along with their implementation. Since SDN is a fairly complex application by now and release cycles are pretty short it is quite important to have as much testing in place as possible, especially before QA starts with any tests. Currently we focus on technical (in comparison to end-user) integration tests provided mainly by development. Meaning we have a set of test cases which will be executed after the first deployment on a test system and which focus on basic SDN functionality like any service or API call or which are checking correct configuration etc. The next obvious step will be to include basic end-user tests into these integration tests.
      We are in the lucky position that some of our developers do have unit test experience but of course we try to support as much as possible in such matters.

      Regards
      Folkert

      (0) 

Leave a Reply