IT Reflexions

A few years ago I used to work in a young IT Company as a software developer at first. As the company grew, the need of a specialized Testing Department grew even larger so I was appointed as the Testing/Quality Assurance Manager. I was to coordonate a team that had no experience related to what software testing really was.

So, me and my team, started from the scratch trying to organize the testing department according to the needs and the budget of a 20 programmers company.

First we started doing some research regarding what testing actually was and how to organize the testing process as efficient as posible. We started looking for some standards and software quality assurance books and as well some tools that we could use.

One of the definitions of quality assurance was:

The process consisting of all life cycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects.”( ISTQB definition).

If you search on the internet I’m sure you will find many definitions of what testing actually is. So, the software testing is a continous effort that should be sustained along the entire cycle of the project.

As we have seen the fundamental test process consists of the following main activities:

• planning and control;
• analysis and design;
• implementation and execution;
• evaluating exit criteria and reporting;
• test closure activities.

As a result, we decided that the quality assurance team should be involved starting with the preliminary phases of the project in order to be properly planned and executed.
The test plan would usually specify aspects like number of human resources used, tools, allocation of time and tasks, deadlines, deliverables that should be provided to the client, the frequency and the way the activity reports would be provided to the client.

After planning and analizing the project, the time was to start performing the actual tests. For organizing our work, writing the testing scenarious, assigning the test cases and gathering statistics and managing the various builds of the tested application we found lots of tools, some of them very expensive, others free.

Of course we started focusing on finding a free tool and TestLink(http://testlink.org/wordpress/) seemed to be exactly what we needed. This proved to be very useful for us, the testers, and for me to be able to allocate the resources to the tested projects properly and to offer to the clients a proffesional way of generating the test cases.

When performing the test cases usualy faults or bugs start to show up and developers should be informed as soon as possible about them in order to be able to fix them.

DEFECT = FAULT = BUG = PROBLEM – A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system.

So we needed another tool that would help both us and the developers to organize the bugs found and we decided to use Bugzilla(http://www.bugzilla.org/). It is an web application that proved to be very efficient in reporting bugs to groups of developers, showing the status of the bugs and providing a pattern that would describe the steps needed for an accurate report of the bugs.

Below is an example of how the testig process should be managed using Bugzilla(http://www.bugzilla.org/) as a bug & task manager tool.

Regardless of the types of tests performed, weather manual or automatic, these proved to be some of the basic steps needed to start organizing the software department.