Introduction to Software Testing

Ramon Revuelta Gonzalez – Control Software Solutions

Introduction – Why Test Software?

Software is found in wide range of everyday devices, from a tablet or desktop computer, commercial or financial applications to large electronic embedded systems such as in car or airplane.

Software malfunctioning can cause loss of time and money, which could potentially turn into customer dissatisfaction. In the worst-case scenario, software failure could lead to human injury or death.

Therefore, the software testing process is an extremely import part of the software development life cycle. At CSS, we acknowledge this and have made software testing an important part of our development process.

In this post we introduce you an overview of software testing, what activities it involves and the different types of software testing.

Causes of Software Failure

Despite what some will lead you to believe – people are not perfect!

Since software is developed by people, and people are not perfect , it is possible that people will introduce bugs (defects). Pressures due to project constraints, time and cost increase the possibility of introducing defects. Defects can turn into failures once he software is executed. See the diagram below for illustration:

Defect Flow Chart

Test Phases

1. Planning and Control

In this early stage the objectives and the requirements of testing are defined. This task is usually undertaken by the project or quality manager.

2. Analysis and Design

In this stage the testing objectives are turned into tangible test cases. This would be done by someone with the role of a test author.

3. Implementation and Execution

Here the test executers or testers implement the test cases, either manually or in an automated system, and execute them

4. Evaluating Exit Criteria and Reporting

Once the results are obtained these are compared against the testing objectives and requirements stated by project management in stage 1.

5. Test Closure Activities

At this point management decides whether the project can be closed based on whether the objectives or other milestone such as code coverage has been met.

General Test Objectives

Although each project has its own objectives there are a set of objectives common to any software project.

Finding Defects

This is probably the most obvious objective. All software testing projects have a common goal of finding defects and build a more robust and solid software application.

Quality Assurance

Detecting defects does not increase the quality in itself, however by detecting defects early developers are able to fix them and hence the level of quality of the system increases. Fixing defects can result in a higher quality application and most importantly customer satisfaction with the product.

Decision Making

By finding defects in the system and providing detailed information about them, and which modules they are contained, project management can undertake key decisions. An example would be whether to postpone the release to the customer, or on the other hand to close the software version and hand it over to the customer.

Test Levels

Within software testing there are different test levels, ranging from a small to large scale. In this section the different test levels are briefly explained with a few LabVIEW code snippets to help to aid its understanding.

Component Testing

Component testing focuses on testing requirements, design and code.  This is normally undertaken by the developer and it includes test-driven development. In a LabVIEW environment this could be a unit test to check whether a subVI performs the function it was designed for. See below:

Component testing of a subVI

 

For more information on unit testing check out our blog post Unit Testing in LabVIEW

Integration Testing

Integration testing tests the interactions between different components or units. This is undertaken after component testing and it evaluates the software architecture design and workflow. It can be carried out at two levels: Component integration testing or system integration testing.

Component integration testing tests the interaction between components of the same system while system integration tests interaction between different systems.

For example, in LabVIEW a subVI queues a message and a calling subVI deques the message and processes some code. This would be a case of component integration testing. See below:

Integration testing

System Testing

This test level concerns with testing of the entire system or product. It involves use cases and functional specifications.

This test level is often undertaken by an independent testing team due its thorough requirements, as opposed to component and integration which are often carried out by the software developer.

Acceptance Testing

This test level attempts to test the system from a customer perspective. Attempting to recreate the scenarios in which the software will be used by the customer. This test type utilizes use cases which recreate scenarios of the system. This type of test also tests the interaction among the different components and hence it also includes integration testing.

Test Types

Within each level there are also test types, which test different aspects of the system.  These range from testing the functionality of the software to how it is maintainability or scalability.

Functionality (Black Box Testing)

This test type tests whether the software performs as expected in the requirements

Non-functional Testing

Here non-functional aspects such as loading and response times are tested.

Structural (White Box Testing)

This tests the structure of the software. The results for this test type are usually presented as a percentage of code coverage. A testing tool such as the LabVIEW Unit Test Framework is a good example of how much of your code is exercised by your unit tests. Providing the user with a percentage of code thoroughness of the application.

Regression Testing

When new features are implemented into the system it is important to ensure the previous features keep functioning correctly. The test type that checks this, it is regression testing. Test cases are run continuously to ensure new software features do not break the already existing ones. This test type is suitable for an automated system.

Illustration of the purpose of regression testing [https://testfort.com/blog/a-quick-guide-to-regression-testing ]

Conclusion

As people are not perfect, defects can be introduced and these defects can lead to software failure. Although testing in itself does not increase the quality of the software it allows us to find defects and correct them before releasing an application. Fixing defects increases the quality of the software and leads to increased customer satisfaction.

I hope this post has been helpful and has provided you with a more in-depth overview of why testing software is important and what activities are involved in testing software.

Ramon Revuelta Gonzalez

Graduate LabVIEW engineer (CTFL)        

References

1. ISTQB. Testing Throughout the Software Life Cycle. Certified Tester: Foundation Level syllabus: 2011.

2. A Quick Guide to Regression Testing. Available from: https://testfort.com/blog/a-quick-guide-to-regression-testing

 

Leave a Reply

Your email address will not be published. Required fields are marked *

thirteen + 12 =