Change-Based Testing (also known as “delta” or “incremental” testing) is an applicable approach in situations where the software is evolving rapidly, and frequent changes are being made. Instead of retesting the entire application from scratch with each update, change-based testing saves time and resources by concentrating efforts on the areas that have been altered. It helps streamline the testing process and enables quicker feedback on the quality of recent changes.
Change-based testing is related to both requirements traceability, and to change impact analysis.
Change-based software testing focuses on testing only the portions of a software system that have been modified or updated since the last testing cycle. The idea behind change-based testing is to efficiently identify and verify the impact of recent changes on the existing functionality and to ensure that the modifications haven’t introduced new defects or regressions.
For any safety-critical or security-critical application, it is likely that the resulting development process will need to be audited to meet certification or qualification requirements.
Even if the process and resulting code don’t need to meet stringent certification demands, proactive requirements traceability will ease the identification of code requiring retest, maintaining high levels of code quality while keeping test overhead to a minimum.
Change-driven testing is simply another name for change-based testing.
Delta testing is simply another name for change–based testing.
Incremental testing is simply another name for change-based testing.
The process of change-based testing typically involves the following steps:
Incremental development is a software development methodology that focuses on building a complex system in small, manageable increments or iterations.
Incremental development can take many forms. In the case of a new application development, incremental development breaks down the project into smaller, functional components or features that can be developed and tested independently. These components are then gradually integrated to form the complete system.
Incremental development can be a powerful approach when creating a core system that serves as a foundation for various projects with differing requirements. An initial “vanilla” variant of a system is often developed with a particular application in mind, perhaps for an initial client. Subsequent developments will build upon that foundation, with new functionality being added as new customers demand variants of the original core system. These enhancements are then integrated into the core foundation offering, which becomes ever more sophisticated and configurable over time.
Such systems may well evolve over years, and the development team members will likely change continually over that time. Maintaining software quality in such circumstances depends on a tight control on requirements, and development standards. Change-based testing lends itself ideally to such circumstances.
A baseline is a reference point in software development – a “line in the sand”. It may be marked by the completion of software configuration item(s), the end of a development phase, or by formal approval. Conversely, it may be timed quite arbitrarily to provide a “snapshot” as a reference point to monitor progress – perhaps weekly or monthly.
The LDRA tool suite supports development teams who are working in a formal development process to improve code quality and maintainability, including static and dynamic analysis, coding standards compliance, and unit, integration, and system testing.
TBmanager is a component of the LDRA tool suite. It is a role-based requirements management tool that supports team members in their work on allocated activities and links the resulting code and verification artefacts back to higher level objectives.
Pertinent functionality offered by TBmanager includes project baseline generation, and code change impact reporting.
TBmanager highlights the effects of changed requirements and changed code. So, if a stakeholder specifies a new or changed requirement, then the impact can be assessed – and conversely, if a failed test results in changed code, then the implications of that change on other tests can also be shown.
TBrun is another component of the LDRA tool suite. It is a unit/integration test tool, providing a complete verification environment for the automated generation and management of test harnesses and unit/integration tests. The regression test facilities it provides are a significant element of the tool suite’s support for requirements traceability.
TBevolve is an optional plug-in for use with the LDRA tool suite. It enables project teams to monitor the impact of code changes on their testing process. By comparing the current code base with a baseline copy, it highlights changes and reports on any untested source code impacting code coverage statistics.
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707