Introduction To Software Testing

Posted on Apr 17 2009 - 4:55pm by Raj

This article is a good place to start your Software Testing learning. If you are a fresher or computer hobbyist interested in software testing as a full-time job, or an internee, or a career changer wanting to move from her field of expertise into the software industry, start here and it will give you a jump start in your testing career.
There are lots of opportunities for non-software experts to apply their knowledge to software testing: programmers, software project managers and other people who make up a software project team.

What is the Goal of a Software Tester?

In simple words the goal of a software tester is to find bugs, find them as early as possible, and make sure they get fixed. A fundamental trait of software testers is that they simply like to break things. They live to find those elusive system crashes. They take great satisfaction in laying to waste the most complex programs. They’re often seen jumping up and down in glee, giving each other high-fives, and doing a little dance when they bring a system to its knees. It’s the simple joys of life that matter most to them.

When you are assigned to a software testing project, you will need to do the following things:

1. Requirement Analysis: Go through the user specification of the application you are going to test.

2. Test Architect: Write down the test conditions or test objectives from the user specs. This is equivalent to defining the architecture of the application. Do not skip this test. Say, for a calculator application the requirement says addition functionality for a calculator. Here the test objectives will be:

a. Validate that addition of two positive number gives correct result.
b. Validate that addition of one positive and one negative number gives correct result.
and so on.
3. Then write down the test cases from the above objectives. Here you will mention the detail level steps. eg

step1. Open the calculator application.
step2: click on the number 2
Step3: Click on +
Step4: Click on 3
Step5: Press = and get the result etc..

4. Test execution: At this stage you need to run the application following the test case steps and record the result.

5. Defect reporting: If step 4 gives correct result,  you mark the test case as passed. If it give a wrong result, say 
2+3 = 6 etc, then you need to log a defect. This defect will go to the developer who has developed this calculator application. He or she will fix the defect and send you the fixed application.

6. Retesting the defect: Here you need to retest the defect and, if it is actually fixed, you will close it and mark the test case as passed.

Above is the overall lifecycle of any testing project from a junior tester’s point of view.

How will you understand that Software has a bug?

Well most of the time if you find any of the following situations then you can safely say the software has a bug and can log a defect against it:

1. The software doesn’t do something that the product specification says it should do.

2. The software does something that the product specification says it shouldn’t do.

3. The software does something that the product specification doesn’t mention.

4. The software doesn’t do something that the product specification doesn’t mention but should.

5. The software is difficult to understand, hard to use

Some common testing terms:

1. Static vs. dynamic testing

Static testing is performed using the software documentation. The Code is not executed during static testing. So here you will find defects which are related to requirements (documentation related defects), whereas in dynamic testing you will run the application and find the actual bugs in the code.

2. Software verification and validation

Verification and validation are often used interchangeably but have different definitions. These differences are important to software testing.

Verification is the process confirming that the software meets its specification. Validation is the process confirming that it meets the user’s requirements. These may sound very similar, but an explanation of the Hubble space telescope problems will help show the difference.

Software Quality Assurance (SQA) (wiki)

Though software testing may be viewed as an important part of the software quality assurance (SQA) process, in SQA software process specialists and auditors take a broader view of software and its development. They examine and change the software engineering process itself to reduce the amount of faults that end up in the delivered software: the so-called defect rate.

What constitutes an “acceptable defect rate” depends on the nature of the software. For example, an arcade video game designed to simulate flying an airplane would presumably have a much higher tolerance for defects than mission critical software such as that used to control the functions of an airliner that really is flying!

Although there are close links with SQA, testing departments often exist independently, and there may be no SQA function in some companies.

Software Testing is a task intended to detect defects in software by contrasting a computer program’s expected results with its actual results for a given set of inputs. By contrast, QA (Quality Assurance) is the implementation of policies and procedures intended to prevent defects from occurring in the first place.

Testing methods – Black Box Vs White Box testing

Software testing methods are traditionally divided into black box testing and white box testing. These two approaches are used to describe the point of view that a test engineer takes when designing test cases.

White box testing, in contrast to black box testing, gives the tester access to the internal data structures and algorithms (and the code that implement these).

This is good enough for a start. Software testing has many areas, and there are many testing methods which you need to learn to be successful in your testing career.

About the Author

Leave A Response