Software requirements are undoubtedly the most valuable artifact of software testing. By requirements, I mean any textual document that describes what a functionality should do. Requirements tell us precisely what the software needs to do and what it should not do. They describe the intricacies of the business rules that the software has to implement and… Continue reading Introduction
Category: Uncategorized
What if you disagree with the testing pyramid?
Many people disagree about the idea of a testing pyramid and whether we should favor unit testing. These developers argue for the testing trophy: a thinner bottom level with unit tests, a bigger middle slice with integration tests, and a thinner top with system tests. Clearly, these developers see the most value in writing integration tests. While… Continue reading What if you disagree with the testing pyramid?
What do I test at the different levels?
I use unit tests for units that are concerned with an algorithm or a single piece of business logic of the software system. Most enterprise/business systems are used to transform data. Such business logic is often expressed by using entity classes (for example, an Invoice class and an Order class) to exchange messages. Business logic often does not depend… Continue reading What do I test at the different levels?
Why do I favor unit tests?
cAs I said, I tend to favor unit testing. I appreciate the advantages that unit tests give me. They are easy to write, they are fast, I can write them intertwined with production code, and so on. I also believe that unit testing fits very well with the way software developers work. When developers implement… Continue reading Why do I favor unit tests?
When to use each test level
With a clear understanding of the different test levels and their benefits, we have to decide whether to invest more in unit testing or system testing and determine which components should be tested via unit testing and which components should be tested via system testing. A wrong decision may have a considerable impact on the… Continue reading When to use each test level
System testing
To get a more realistic view of the software and thus perform more realistic tests, we should run the entire software system with all its databases, frontend apps, and other components. When we test the system in its entirety, instead of testing small parts of the system in isolation, we are doing system testing (see… Continue reading System testing
Integration testing
Unit tests focus on the smallest parts of the system. However, testing components in isolation sometimes is not enough. This is especially true when the code under test goes beyond the system’s borders and uses other (often external) components. Integration testing is the test level we use to test the integration between our code and… Continue reading Integration testing
The testing pyramid, and where we should focus
Whenever we talk about pragmatic testing, one of the first decisions we need to make is the level at which to test the code. By a test level, I mean the unit, integration, or system level. Let’s quickly look at each of them.
Verification is not validation
Finally, note that a software system that works flawlessly but is of no use to its users is not a good software system. “Coverage of code is easy to measure; coverage of requirements is another matter.” Software testers face this absence-of-errors fallacy when they focus solely on verification and not on validation. A popular saying that may help… Continue reading Verification is not validation
Context is king
The context plays an important role in how we devise test cases. For example, devising test cases for a mobile app is very different from devising test cases for a web application or software used in a rocket. In other words, testing is context-dependent. Most of this book tries to be agnostic about context. The… Continue reading Context is king