1.5.The Psychology of Testing (K2)

Software development is a human-intensive activity so not only is there a potential for errors there is also an opportunity for emotions to influence actions. It can happen during any phase of the software life cycle but testing seems especially susceptible.
The Reason for Testing
Testing is best defined as executing software for  finding  defects and to demonstrate that they are fit for purpose. This definition captures important distinctions not present in the other definitions below.

Definition #1: The goal/purpose of testing is to demonstrate that the program works correctly. After testing we feel more confident about the reliability of the program, but stating this as a goal leads us toward ineffective tests. If the goal is to demonstrate that the program works correctly, we have an unconscious tendency to avoid tests that can demonstrate that the program does not work correctly. This is one of the reasons that developers must not test their own programs. They have an emotional stake in the outcome

Definition #2: The purpose of testing is to demonstrate that the program is defect free. In most cases it is impossible to test every input combination (and sequence of inputs for sequential programs) and so it is impossible to prove that there are no defects present. This is a bad definition because it creates an impossible goal.

Definition #3: The purpose of testing is to demonstrate that the program does what it is supposed to do. This definition is only partially true. The purpose of testing is also to show that the program does what it is not supposed to do. (The purpose of testing is to find errors.)

So the correct or good definition of testing is that testing is executing software for the purpose of finding defects and  to demonstrate that they are fit for
purpose. . The goal of testing is to find defects and verify that the software meets the needs of the user, not to show that the software does what it was written to do. Testing must demonstrate that the system meets the needs of the user, not just that it runs.

Testing is difficult and requires as much creativity as new development. However, some organizations consider testing as a less desirable assignment than new development. One possible explanation is that when performed ad hoc and without much support, it is a less challenging and a less desirable position.



The Tester-Developer Relationship
Testing is, often seen as a destructive activity, even though it is very constructive in the  management of product risks. Looking for failures in a system requires curiosity, professional pessimism, a critical eye, attention to detail, good communication with development peers, and
experience on which to base error guessing

.

If errors, defects or failures are communicated in a constructive way, bad feelings between the testers and the analysts, designers and developers can be avoided. This applies to reviewing as well as in testing.

The tester and test leader need good interpersonal skills to communicate factual information about defects, progress and risks, in a constructive way. For the author of the software or document, defect information can help them improve their skills. Defects found and fixed during testing will save time and money later, and reduce risks.

Communication problems may occur, particularly if testers are seen only as messengers of unwanted news about defects. However, there are several ways to improve communication and relationships between testers and others:

§ Start with collaboration rather than battles – remind everyone of the common goal of better quality systems.
§ Communicate findings on the product in a neutral, fact-focused way without criticizing the person who created it, for example, write objective and factual incident reports and review findings.
§ Try to understand how the other person feels and why they react as they do.
§ Confirm that the other person has understood what you have said and vice versa.
§ Sharing test scripts between teams.
§ Distributing the ability to execute smoke tests.
§ Performing runtime analysis together.
§ Using log files to isolate problems.
§ Using defect-tracking systems effectively.
§ Face to face communication.
§ Programmer sharing details of the software like changes done, areas difficult to test and so on to the tester.
§ The tester providing a simple test that the developer can run to find a problem before releasing the code for testing.
§ Management motivating the testers to find and report problems within the system as quickly as possible, while they are motivating the developers to complete code as quickly and accurately as possible in order to move on to the next problem.

Independence
The mindset to be used while testing and reviewing is different to that used while developing software. With the right mindset developers are able to test their own code, but separation of this responsibility to a tester is typically done to help focus effort and provide additional benefits, such as an independent view by trained and professional testing resources. Independent testing may be carried out at any level of testing.

A certain degree of independence (avoiding the author bias) is often more effective at finding defects and failures. Independence is not, however, a replacement for familiarity, and developers can efficiently find many defects in their own code.

Objective, independent testing is a more effective way to conduct testing. If the author conducts the tests, then the author carries his/her assumptions into testing. People see what they want to see and can have an emotional attachment and a vested interest in not finding defects.

Developers and organizations must not system test their own code. The development organization is often under pressure to deliver a product according to a strict and often short schedule. The schedule is very real and the value of delivering on schedule is easy to measure. The value of testing is harder to measure. There is always the chance that testing won’t find any errors. Add to this the natural optimism and the several emotions affecting the decision about how much to test. For this reason we often have separate groups responsible for conducting independent testing.

A certain degree of independence (avoiding the author bias) is often more effective at finding
defects and failures. Independence is not, however, a replacement for familiarity, and developers
can efficiently find many defects in their own code. Several levels of independence can be defined:
Several levels of independence can be defined:
§ Tests designed by the person(s) who wrote the software under test (low level of independence).
§  Tests designed by another person(s) (e.g. from the development team).
§  Tests designed by a person(s) from a different organizational group (e.g. an independent test team) or test specialists (e.g. usability or performance test specialists).
 Tests designed by a person(s) from a different organization or company (i.e. outsourcing or certification by an external body).

0 comments:

Post a Comment