Wednesday May 24th 2023
“Blocking issues just before our release date, again!”, “Why do we always find our defects so late?”. Who does not recognize the frustration of this anonymous IT manager?
We usually manage to find defects on an integrated production-like system such as during integration and acceptance testing. And otherwise, they will be found in production by users. Finding defects late in the development process is unattractive. It delays planning and disrupts predictability of delivery, and don't mention problems in production. Fortunately, several ways exist to find defects early in the development process.
Use Model-Driven Design (MDD)The best time to find defects is early on in the specification phase, before a single line of code is written. Specifications are often defined using natural language in a Word document. A tool like Word is actually not suitable for this job, as such a tool does not help in creating unambiguous and complete specifications. Consequently, this approach often leads to incomplete and for IT-professionals unclear specifications, resulting in incorrect functionality or test cases.
An interesting approach is the use of Model-Driven Design. In this case, the specification is written in a so-called model, possibly with tool support. On the one hand, this forces the modeler to be precise and complete; on the other hand, this model allows the computer to assist in the development process. For example, by automatically checking the design for inconsistencies or automatically generating test cases.
Generate hyper-realistic test data
Realistic data is important to cover all functionality of the system, especially exceptional and error cases. However, realistic data is often not available during development. It is often not possible to use production data, and such data often does not have the diversity of cases needed for testing. For testing, exotic and unforeseen test data, also called hyper-realistic data, is required. Creating and maintaining such test data manually takes developers a lot of time, if they do so at all. Therefore, the best option is to generate data with generators.
Software engineers often do not have access to adjacent systems during development. As a result, communication with these systems can only be tested properly during integration testing. Adjacent systems can be mimicked with simulators, allow for performing realistic tests during development. The more realistic the simulator, the more defects can be found.
Defects late in the development process slow down delivery and disrupt predictability. Detecting defects early prevents this and allows you to release your software with confidence.
- Use Model-Driven Design to prevent errors in specifications.
- Use data generators to test with (hyper-)realistic data and cover all cases during development.
- Use realistic simulators to test communication with other systems well before integration testing.
One can opt for open-source solutions here. Alternatively there are also commercial solutions on the market. The unique Axini testing platform offers the above three solutions and more. Axini helps organizations deliver complex software products on time, without concessions on quality.