In many (Agile) projects, it is common to see a backlog with strong prioritization. Often, that priority is heavily focused on development items. At the same time, however, dozens of people may be waiting for a new build version.
What is going wrong here?
The issue is that sometimes, simple adjustments can significantly reduce the test effort throughput time. Read that again—we can have it tested faster!
But how? Let’s consider an example:
Scenario | Problem | Solution |
---|---|---|
Functional Regression Test | Test steps require looking up information from a table. | Enable table sorting or filtering functionality. |
You might think this only saves a few seconds or, at most, a few minutes. But how many times do you encounter that particular test step?
This example shows that sometimes, it’s worth giving a little more attention to software testing. By doing so, you can achieve a faster overall process, helping the team get back online and in business more quickly.
Example | Description |
---|---|
SQL Query Creation | The creation of a SQL query that delivers the information from the database after testing (instead of looking it up manually). |
Correct Test Data Environment | A test environment that has the correct data with all possible scenarios but no duplicate entries or duplicate data. |
Stable Test Environment | A test environment that is made stable before testing starts. |
Short-Term Code Freeze | Changes in code that make it possible to have a (short time of) code-freeze so that it is no longer "shooting at a moving target." |
Do you see where this is going? You need to plan when these actions are happening. Additionally, you need to know whether the Poker points of a Story include or exclude those test work actions. Take a look at the test policy template.