Component Test Overview
This guide provides a quick overview of component tests and when and how they should be used.
Intended for
Software engineers, scrum masters, and test engineers.
What is component testing?
- Component testing is a type of software testing that is performed on each component separately without integrating with other components.
- Generally, software is made up of several components. Component-level testing deals with testing these components individually.
- It’s one of the most frequent black-box testing types, and the scrum team performs it.
- Unit tests check individual units/components of the code in isolation. Component tests check collections of units that work together as a single component. Integration tests check the interaction between multiple components to ensure that they work together as a system.
When and how to perform component testing
Component testing is performed soon after the developers complete the unit testing, and the build is released for the testing team.
Main recommendations:
- Automate as much as possible.
- Allow/encourage testers to do some additional creative/free testing (let them find what they think might be corner cases).
- If issues are found during free testing, potentially add a bug and a test case, but at the very least, let the developers know.
- A domain expert might be required for “free” testing.
Positive and negative testing: both important
Positive testing, often called “happy path testing”, is generally the first test a tester performs on a component. It is the process of running test scenarios that an end user would run for their own use. Hence, positive testing involves running a test scenario only with “correct and valid data.”
Sometimes, there may be more than one way of performing a particular function or task, intending to give the end user more flexibility or general product consistency. This is called "alternate path testing", which is also a kind of positive testing. In alternate path testing, the test is again performed to meet its requirements, but using a different route than the obvious path. The test scenario would even consume the same data to achieve the same result.
Negative testing, commonly referred to as "error path testing" or "failure testing", is generally done to ensure the stability of the component.
Negative testing involves applying as much creativity as possible and validating the component against invalid data. Its purpose is to check if the errors are shown to the user as supposed to, and to handle a bad value more gracefully.
Only effectively designed negative scenarios can quantify the functional reliability of an application or software. Negative testing aims to uncover potential flaws that could seriously impact the product's overall consumption and can be instrumental in determining the conditions under which the application can crash. Finally, it ensures that the software has sufficient error validation.
Test cases
Test cases define the sequence of actions required to verify the system functionality. A typical test case consists of test steps, preconditions, expected results, and actual results. Scrum teams usually create test cases from test scenarios. These test scenarios provide a high-level overview of what testers should test regarding user workflows and end-to-end functionality to confirm that the system satisfies customer requirements.
Entry/exit execution criteria
Entry criteria
- The feature acceptance criteria are defined and approved.
For teams with dedicated testers:
- Test cases have been prepared.
- Test data has been created.
- The environment for testing is ready, and all the required tools are available and ready.
- A complete component implementation has been developed, unit tested, and is ready for testing.
Exit criteria
- All the component test cases (manually or automatically) have been executed.
For teams with dedicated testers:
- No "High" or "Medium" bugs related to the developed component are pending.
- Any minor bugs related to the developed component have been reported and acknowledged.