Software Test Organization Leader

To see all articles of ISTQB-ISEB Foundation guide, see here:

Software Testing-ISTQB ISEB Foundation Guide

Independent testing is testing carried out by someone other than the creator (developer) of the code being tested. By remaining independent it is possible to improve the effectiveness of testing if implemented correctly.

As humans we are all capable of making mistakes, from the simplest misspelling or wrong use of syntax to fundamental errors at the core of any documents we write. The problem is that as authors we are less able to see our own errors than someone else, who is less directly associated with the document, would be. This is a problem that is made worse, in the world of software development, by the differing ‘world view’ of testers and developers. A developer, as the creator and owner of documents and code related to development, perceives these deliverables as being correct when they are delivered. The general awareness that we all make mistakes is, at this stage, overridden by the belief that what has been produced is what is required. A tester, by contrast, will take the view that anything delivered for testing is likely to contain errors and will search diligently to identify and locate those errors.

This is where independent testing is important, as it is genuinely hard for authors to identify their own errors, but it is easier for others to see them. There are many options for many levels of independence. In general, the more remote a tester is from the production of the document, the greater is the level of independence. Below Figure indicates the most common roles and the levels of independence they bring.

Of course independence comes at a price. The greater the level of independence, the greater the likelihood of errors in testing arising from unfamiliarity. Levels of independence will also depend on the size of the organization. In smaller organizations where everybody contributes to every activity it is harder to differentiate the role of the tester from any other role, and therefore testers may not be very independent at all. The key in these circumstances is for the testers to have independence of mind, not necessarily to be in an independent (separate) team. In organizations where there are clearly defined roles it is a lot easier for a tester to remain independent.

It is also possible to mix and match the levels of independence, e.g. a test team made up of permanent resources, business unit resources and contractors. For large, complex or safety-critical projects, it is usually best to have multiple levels of testing, with some or all of the levels done by independent testers.

The ‘agile’ approach to development challenges the traditional approach to independence. In this approach everybody takes on multiple roles and so maintaining total independence is not always possible. A tester in this situation has to be able to switch to an independent view, at the relevant points in the project. Testers achieve this independence of view by not assuming anything and by not starting to own the software like a developer would, e.g. the view that was how it was developed to work.

Independence in the implementation of testing has some key benefits and drawbacks:

Features of independent testing

Benefits	Drawbacks
The tester sees other and different defects to the author	Isolation from the development team (if treated as totally independent), which will mean the tester is totally dependent on the test basis to understand what it is the tester is testing (documentation that is rarely up to date)
The tester is unbiased	The tester may be seen as the bottleneck, as independent test execution is normally the last stage and affected by any delays earlier in the process
The tester can see what has been built rather than what the developer thought had been built	Developers lose a sense of responsibility for quality as it may be assumed that they need not worry about errors because the independent test team will find them
The tester makes no assumptions regarding quality	The fully independent view sets developers and testers on either side of an invisible fence. This can be a hindrance to communication that would in normal circumstances ensure common understanding and effective working. It can also mean that developers are seen to ‘throw’ the software over the fence

Tasks of a Test Leader and Tester

Test tasks are traditionally carried out by people who make testing a career; however, test tasks may also be carried out by non-testers such as a project manager, quality manager, developer, business and domain expert, infrastructure or IT operations. The availability of resources usually determines the resource types that are deployed on each project, e.g. if there are no career testers available an organization may identify non-testing IT or business resources to carry out the role of tester for a specific project or time period.

The syllabus defines two testing roles, the test leader (or test manager/test coordinator) and the tester. Other roles may exist in your organization, but they are not covered here.

The testing roles can be undertaken by anyone with the required skills or who is given the right training. For example, the role of a test leader could be undertaken by a project manager. The decision as to who does what will depend on how a project or organization is structured, as well as the size and number of resources working on a given project.

It is important to understand here the difference between a testing role and a testing job. A role is an activity, or a series of activities given to a person to fulfill, e.g. the role of test leader. A person may therefore have more than one role at any moment depending on their experience and the level of workload on a project. A job is effectively what an individual is employed to do, so one or many roles could make up a job. For example, a test leader could also be a tester.

The tasks undertaken by a test leader align very closely with those undertaken by a project manager and align closely with standard approaches to project management. In this context a test leader is anyone who leads a team of testers (be that one or many testers). They are also known as test program managers, test managers, test team leaders and test coordinators.

Typical test leader tasks may include:

• Coordinating the development of the test strategy and plan with project managers and others.
• Writing or reviewing test strategies produced for the project, and test policies produced for the organization.
• Contributing the testing perspective to other project activities, such as development delivery schedules.
• Planning the development of the required tests—which will include ensuring that the development uses the correct understanding of the risks, selecting the required test approaches (test levels, cycles, approach, objectives and incident management planning), estimating the time and effort and converting to the cost of testing and acquiring the right resources.
• Managing the specification, preparation, implementation and execution of tests, including the monitoring and control of all the specification and execution.
• Taking the required action, including adapting the planning, based on test results and progress (sometimes documented in status reports), and any action necessary to compensate for problems or delays.
• Ensuring that adequate configuration management of testware is in place and that the testware is fully traceable, e.g. there is a hierarchical relationship established between the requirements and the detailed specification documents.
• Putting in place suitable metrics for measuring test progress and evaluating the quality of the testing delivered and the product.
• Agreeing what should be automated, to what degree, and how, ensuring it is implemented as planned.
• Where required, selecting tools to support testing and ensuring any tool training requirements are met.
• Agreeing the structure and implementation of the test environment.
• Scheduling all testing activity.
• At the end of the project, writing a test summary report based on the information gathered during testing.

These tasks are not, however, all of the tasks that could be carried out by test leaders, just the most common ones. In fact other resources could take on one or more of these tasks as required, or they may be delegated to other resources by the test leader. The key is to ensure that everyone is aware of who is doing what tasks, that they are completed on time and within budget, and that they are tracked through to completion.

The other role covered by the syllabus is that of the tester, also known as test analyst or test executor.

The tasks typically undertaken by a tester may include:

• Reviewing and contributing to the development of test plans.
• Analyzing, reviewing and assessing user requirements, specifications and models for testability.
• Creating test specifications from the test basis.
• Setting up the test environment (often coordinating with system administration and network management). In some organizations the setting up and management of the test environment could be centrally controlled; in this situation a tester would directly liaise with the environment management to ensure the test environment is delivered on time and to specification.
• Preparing and acquiring/copying/creating test data.
• Implementing tests on all test levels, executing and logging the tests, evaluating the results and documenting the deviations from expected results as defects.
• Using test administration or management and test monitoring tools as required.
• Automating tests (may be supported by a developer or a test automation expert).
• Where required, running the tests and measuring the performance of components and systems (if applicable).
• Reviewing tests developed by other testers.
  

If specialist testers are not available, then additional resources could be used at different test levels:

• For component and integration testing, any additional roles would typically be filled by someone from a development background.
• For system and user acceptance testing, any additional roles would typically be filled by someone from a business or user background.
• System operators (sometimes known as production support) would be responsible for operational acceptance testing.

As mentioned earlier, the thing to remember when looking at roles and tasks within a test project is that one person may have more than one role and carry out some or all of the tasks applicable to the role. This is different to having a ‘job’: a ‘job’ may contain many roles and tasks.

To check your understanding, I would again like to ask you some questions:

What other names are given to the test leader role?
Detail five possible tasks of a test leader.
Detail five possible tasks of a tester.
Describe the differences between a test leader role and a test leader task.

You may follow the complete series of Test Management articles here:

Test Management Risk And Testing
Software Test Organization
Software Test Approaches Test Strategies
Software Test Planning And Estimation
Software Test Progress Monitoring & Control
Software Testing Incident Management
Software Test Configuration Management

To see all articles of ISTQB-ISEB Foundation guide, see here:

Software Testing-ISTQB ISEB Foundation Guide