Scope
This article gives an overview of a Testing Team. It highlights the common issues encountered in a testing team and also discusses about the changes that can be effected to have an effective and efficient testing team.
Introduction
The software testing process has evolved considerably and has reached the point where it is a discipline requiring trained professionals. To succeed today, an organization must be adequately staffed with skilled software testing professionals who get proper support from management. –"Software Testing In The Real World" Edward Kit
Testing is not an entry-level job or stepping stone to other things. Many people find that when done properly, it surpasses the challenge of product development. It should be organized so it can faithfully maintain allegiance to the customer. It should not be subservient to or be positioned for easy overrule by the product development or any other organization. Testing should be independent, unbiased, and organized for the fair sharing of recognition and rewards for contributions made to product quality. –"Software Testing In The Real World–Improving the Process", by Edward Kit
These two statements very clearly portray the importance of a Testing process and an efficient team to enforce that process in any project or company. Gone are the days when the same set of people could deliver a project by wearing different hats at different points of time. Now, to be able to successfully execute a project one needs to have dedicated teams working on different aspects of the project. Most projects have Business Analysts or Project Managers involved in gathering the requirements and taking care of other tasks like resource and time management. The development team is involved in the design and coding while the Testing/QA team is involved in building up the testing resources.
Unless these happen in parallel, one cannot envisage the project completing on time and with appreciable quality.
Then
The developers acting as testers worked fine in the days gone by. The same individual would do the coding and once he/she completed that task, would then begin the task of testing the code. This testing could neither be classified as Unit Testing or Functional Testing. The testing efforts were happening as isolated tasks. The result- Last minute surprises! Modules were not working well when integrated. Applications were crashing during the implementation phase. All this resulted in last minute recall of product, bug fixes and increased expenditure.
These scenarios and the practice of contracting work to other companies have given rise to more and more managers insisting on a dedicated Testing or Quality team whose task is to test and verify the code on a continuous basis throughout the life cycle of the project. This might not make the product defect free but at least it establishes checkpoints all through the life cycle.
Now
Agreed that we need a testing team. But, Who does the work? What is the role of the team? When do they begin their work? How do they do their work? Answers to these simple but critical questions will ultimately determine how effective the testing team is going to be for the Project and to the Company in the long run.
To understand the role of testing as a task and to build a team which will be competent in accomplishing this, let us look at each of the questions raised above.
Who does the Testing?
This is where the majority of the damage is done. Wrong Staffing – a curse for any project manager. If a developer with the wrong set of credentials or without the required experience is chosen then one is bound to face some crisis down the line. Hence in most projects utmost care is taken when staffing the Development team. This could also be due to the fact that managers have been hiring developers for years and they know how to hire the right people for the job. The concept of an independent testing team itself is fairly new with which most managers have very little or no experience. So what happens at times, is that the wrong sets of people are thrown together as a team and assigned the task of testing a product. Result–Disaster.
Many a time, testing is viewed as a task that does not require any special skill set. The common feeling is that anyone can test. As a result, the team gets staffed with fresh recruits who view this as an entry point into a reputed firm. To such people, testing becomes a mere launch pad to bigger and better things, a test bed where an individual can prove his resourcefulness to the organization and then switch to other areas like Programming.
This defeats the entire purpose of having a dedicated team for testing in the project as first and foremost, the most important factor "dedication to the task" is missing. Unless an individual is dedicated to the task he/she is doing, one cannot expect useful results. So when staffing the team, both the Managers and the candidates need to understand a few things.
The Managers need to understand that for a person to test efficiently and to be able to contribute to the success of the project he /she needs to be as technically qualified as any developer. If not, they are neither going to be able to grasp the project concepts nor are they going to gain the confidence of their team members. And both these factors are critical for testing the product and the success of the project.
The testers for their part need to understand that testing is not a lowly task and is as specialized an area as any other in the Project. So they should take this up only when they feel that they have the penchant for it, otherwise it would prove detrimental to both them and the Project.
Team Lead
A good testing team needs a good team lead. It is always a good practice to not to have the testing and development teams reporting to the same individual. A programming team lead should not be made the testing team lead or vice versa. This is because there will be numerous situations where the lead might be put in a dilemma when a decision has to be taken. For instance, when he/she has to decide if a problem reported by the testing team has to be fixed or not. Their primary role as a programmer or a tester would cloud their judgement. Hence it is always a good practice to have separate individuals to lead the testing and development teams.
What is the role of the team?
To Test. Everyone knows that. But is it as simple as that? There are times when a project has a testing team but it still does not serve the purpose. The reasons could be many. Testing is considered secondary and not enough importance is given to the work done by this team. Issues raised by the team are not being analyzed and targeted. Or the team does not come up with results in time. Defects are found, but late in the project cycle when it is too late to correct them.
These happen when the role of the testing team is not defined properly in the project or when the testing team does not realize its role in the project correctly. Everyone individual in the project needs to understand the role that the testing team plays in the project.
Most teams face the problem of clash of interests between the development and the testing teams. Developers at times feel that testers are raising unimportant issues at crucial stages in the project or that they are not testing critical functionality. The testers feel that the developers do not complete the work in time thereby cutting down the testing time or do not give enough importance to testing. They feel that the issues raised by them are either being ignored or being pushed aside as unimportant issues.
The developers have to understand that, when the testers report bugs they are not trying to point fingers at any developer. They are not criticizing the work of any developer. They are just doing their job. Doing what they are paid to do: find bugs and make the quality of the product better.
The testers for their part need to understand that, no product is 100 per cent bug free. Neither is it practically possible nor is it required. When reporting bugs they have to analyze the seriousness of the issue. How critical is it for the performance of the product? What would be the effect of this bug surfacing in a real-time scenario? The job of a tester is not just to report bugs but also to analyze the issues. They have to realize that there are 100s of Beta testers available all over the world to use a product and report the issues. Bug reporting is not the only job of a testing team. If they stick to just that, then they defeats the purpose of their existence.
Hence the major onus is on the Project Manager (or the company) to define the roles and responsibilities of the Testing team very early in the project life cycle. The testing team on its part needs to know what is expected of them. They have to grow up from a team just policing the product to a team that is the interface between the developer and the user, who can translate user requirements to the developer. For this, the tester should not only understand the design of the application but also try to understand the way in which the product is being used in real time by the end-users.
When to test?
When does the testing team begin its task? This is a tough question to answer for any manager. The sooner the better, but how soon is soon? This can be viewed by categorizing projects into two different kinds. Development projects and Maintenance projects.
In Development projects or new product development, the process involves gathering requirements, preparing Use cases, design and the coding. Here the testing team should be involved right from the requirements stage. Once the Business Analysts have gathered the requirements, it is the task of both development and the testing team to review these requirements. A proper requirement analysis eliminates or in the least reduces the chances of last minute rework. Being involved right from the requirement stage provides the testing team with the opportunity to understand the requirement better and as a result come up with issues and suggestions during the design phase itself. It also helps if the testing team could start working on the test plans in the design phase. With the test plans ready and in tune with the requirements, the testing team can start testing as soon as the coding begins.
If the testing team were brought into the picture after coding begins, it would give the team very little time to analyze the requirements and verify if the design meets the requirements. Also the time and effort for any rework that is identified at this stage would be monumental.
In case of Maintenance projects, there are no specific beginning and end stages. The coding and testing begins almost at the same time. The entire process is iterative with repeated bug fixing and some enhancements to the existing product. In this case, the work for the testing team is going to be a continuous one.
How to test?
The most vital aspect for any testing team is - How to go about the testing tasks? This decides the effectiveness or ineffectiveness of any team. For a project to be successful the testing team needs to perform its tasks diligently and within the constraints of time and budget. Accomplishing this would need proper planning and having a proper process. A process driven approach is a sure shot passage to progress. It is at this final hurdle that many teams stumble.
Planning
Planning is very essential for any task and testing is no exception. Before embarking on any effort, one has to plan the effort. Estimate the time, resources required (both man and material), the process that is to be followed, the targets and the deadlines. Testing without planning is not going to yield any results and is a waste of time, effort and money.
Process
A definite process is required for any testing team to be able to achieve its goals. The process should be easy to adopt and also be repeatable. It is not necessary to have the complete process defined right at the outset. This can be an iterative process. Additions and modification can and should be done to the process as the project progresses. A process definition without any changes over a period of time is just too good to be true or it simply means–No one is following it. As important as defining the process is to follow it.
Test Plans
There is nothing more useful than a well-laid out test plan. The first draft of a test plan can be prepared even before the actual coding begins based on the requirements and the design documents. The test plan helps the tester to go about their task in a phased manner and take it to its logical conclusion. ‘Working off the top of ones head’ or ‘shooting in the dark’ methodologies might produce results in the beginning. But they will neither help in the long run nor are they recommended. For the most part, we are sure to miss out on serious bugs if we do not have test cases listed out in a document. Also the test plans are very useful if the same issues need to be revisited. They are also very helpful for change management.
Regression test suites
Regression Test suites or scripts are more suited for projects of long duration and ones with potential future releases. The Manual regression test scripts are usually checklists or test plans, which are used to execute the stated steps repeatedly at various stages of the project or with every code change. This is suited for smaller projects. When the size of the project is large, then performing the regression tests manually becomes tedious and also error-prone. Automated regression test suites or scripts generated using various testing tools is a good solution for large-scale projects. The automated scripts help in covering a large number of test cases over a matter of hours. This helps in saving time and better utilization of the resources for other important tasks.
Continuous testing
Testing needs to be done on a continuous basis. When testing a product, the testing team should not restrict itself to the tasks of daily execution of automated regression scripts or testing of bug fixes. Testing of the product needs to be done outside the scope of bug fixes and test scripts. The more the product is tested, the better the quality. But this would hold true only if the testing being done is meaningful. Unstructured testing of just clicking on all the options available on the screen is of no help at all. Systematic and Structured testing is required for the testing to be effective. A good tool for this are the checklists.
Checklists
Checklists need not be elaborate documents following strict templates. A tester can prepare his/her own checklists. Before starting to test a module, testers must spend some time analyzing the requirements and note down areas to be tested that they deem critical to the success of the module or project. These are the checklists that they can use to actually test the code.
The checklists are also useful in cases where a part of the product is being enhanced or numerous changes are being done to it. In this case, the testing would be done at various points of time and not at a stretch. The checklists then would help in tracking what was tested and what was not. One important thing to be remembered with checklists is that, these shouldn’t be static documents. They have to grow with use. The testers need to update their checklist as and when they come across new issues.
Conclusion
No Project manager should release a product if the Testing team does not sign-off on the Product. At the same time no Project Manager should let the project drag on for months on end, just because the testing team feels that the product is not 100% bug free. The testing team should not be a hurdle in the path to project completion but a useful facilitator.
Finally, it is not enough to have a testing team. One has to have the RIGHT team. A team that knows its roles and responsibilities and is dedicated to it. A team which can deliver the goods the way it is required and when it is required.
