Category: Software Testing Basics

VSR-II enables potential customers to configure their own vehicle on a computer screen. The extras available for specific models and the possible combinations of options and preconfigured models are subject to a complex set of rules. The old VSR System allowed customers to select combinations that were not actually deliverable. As a consequence of the VSR-II QA/Test planning requirement Functional suitability/DreamCar… Continue reading Testing effort and vehicle variants

Testing effort depends on the project (environment) Testing takes up a large portion of the development effort, even if only a part of all conceivable tests—or, more precisely, all conceivable test cases—can be considered. It is difficult to say just how much effort you should spend testing, as this depends very much on the nature… Continue reading Testing Effort

Test basis The test basis is the cornerstone of the testing process. As previously noted, the test basis comprises all documents that help us to decide whether a failure has occurred during testing. In other words, the test basis defines the expected behavior of the test object. Common sense and specialist knowledge can also be… Continue reading Test Artifacts and the Relationships Between Them

The various names used for different types of tests can be confusing. To understand the naming of tests it is useful to differentiate between the following naming categories: As you can see, not all of these terms define a distinct type of test. Instead, the different names highlight different aspects of a test that are… Continue reading Scheme for naming different types of testing

Testing is not debugging In order to remedy a software fault it has to be located. To start with, we only know the effect of the fault, but not its location within the code. The process of finding and correcting faults is called debugging and is the responsibility of the developer. Debugging is often confused… Continue reading Testing Terminology

Customers can use the VSR EasyFinance module to calculate various vehicle-financing options. The interest rate the system uses is stored in a table, although the purchase of vehicles involved in promotions and special offers can be subject to differing interest rates. VSR-II is to include the following additional requirement: REQ: If the customer agrees to and passes an… Continue reading Vague requirements as a cause of software faults

The test basis as a starting point for testing A situation can only be classed as faulty if you define in advance what exactly is supposed to happen in that situation. In order to make such a definition, you need to know the requirements made of the (sub)system you are testing as well as other… Continue reading Defect and Fault Terminology

There is currently no such thing as a fault-free software system, and this situation is unlikely to change for systems above a given degree of complexity or those with a large number of lines of code. Many faults are caused by a failure to identify or test for exceptions during code development—things like failing to… Continue reading No large system is fault-free

Testing isn’t just about checking that a system fulfills its requirements, user stories, or other specifications; it is also about ensuring that the product fulfills the wishes and expectations of its users in a real-world environment. In other words, checking whether it is possible to use the system as intended and making sure it fulfills… Continue reading Verification and validation

Alongside the dynamic tests that are performed on a computer (5), documents such as requirement specifications, user stories, and source code also need to be tested as early as possible in the development process. These are known as static tests.The sooner faults in the documentation are discovered and remedied, the better it is for the… Continue reading Static and dynamic testing