Quality Engineering Involvement in Test Driven Development

The main objective of this article is to describe the extended role of the Quality Engineer (QE) in Test Driven Development (TDD).

What is Test-Driven Development?

Test-Driven Development is a commonly used development methodology. Since development is driven by tests, this methodology is called Test-Driven Development. The test code is developed before the application code. The test will fail in the first execution. The objective the developer has, is to pass the failing test by developing the code. The main benefit of TDD is that each time the developer makes testable code, that code is deliverable.

TDD Lifecycle

TDD Lifecycle

1. Write a test and confirm that the test fails
2. Write code to pass that test
3. Refactor the code without changing existing functionality

The primary goal behind TDD, is to ensure that developers think through the requirements like a QE would, before they start writing code. Quality Engineers comes into play from this point.

In the TDD approach, both developers and QE use test cases to do development and execution. To make TDD successful, the test cases need to have good coverage of the requirement.

Quality Engineers have more understanding about business scenarios since they test the system from end to end. Therefore, QE can engage in writing unit tests that would add more value to TDD. This will make it easier for developers and QE to identify core functionalities before coding.

I will explain what unit testing is, and how it relates to TDD later.

But before that let’s talk about, what made us choose TDD.

We had a legacy system. Our goal was to extract a subset of functionalities from the legacy system and replace it with a new system, without impacting the legacy system. This doubled the testing effort, since we had to make sure none of the existing functionalities of the legacy system got affected while testing the new one. The legacy system did not have 100% unit test coverage, but we had to ensure 100% unit test coverage for the new system.

Considering the above factors, we found that TDD approach is the best methodology to reduce effort and detect bugs early.

These are the execution steps that we followed in our project:

1. Scenario identification from the requirement by QE
2. Review identified scenarios with developers
3. Write failing unit test cases with skipped state
4. Create pull requests for developers to review
5. Implement code made by the developers
6. Produce unit test reports with all the passed test cases
7. Verify the additional impact by QE

Before diving in further, let’s talk about unit tests. The Test Pyramid is the best way to understand Unit Tests.

Unit tests form the base of the testing pyramid. Individual functionalities or components can be tested using unit tests to validate that it works as expected in isolated conditions.

The unit test suite must be written to run as quickly as possible since this is the largest subset of the pyramid. A fast running test suite encourages developers to run the suite as often as possible.

Since TDD requires testing before the coding, the code ends up being clearer, simpler and bug-free. We can reduce testing effort if we have good coverage on unit tests.

The real challenge in TDD is how to identify unit tests.

To identify unit tests, we have to go through business scenarios and identify independent atomic business operations required to complete the scenario. For example, in the scenario of adding an item to order, we can identify the following steps:

1. Fetch an Order
2. Construct an item with all the required data (price, quantity, taxes, who added the items, etc.)
3. Add the Item to the Order
4. Calculate and update the Order total and order fields
5. Save and release the Order

We can consider those individual scenarios as candidates for unit functionalities, which can be tested individually. For each of those steps, we can reconsider whether we can break those functionalities further while preserving the business meaning of the functionality.

When we have such a set of unit functionalities, the code becomes like an article which can be read by anyone. Going through unit tests allows anyone to understand what each function is supposed to do and what it’s not supposed to do. That is the beauty of unit tests.

As a Quality Engineer, these are the benefits which I gained by using TDD.

• By providing tests at the start, developers can get a better understanding of the requirements. This would help the QE teams to save time on finding requirement related bugs.
• Atomic business flows get covered through unit tests. Therefore, QE’s can focus more on exploratory and adhoc testing.
• End to end tests does not need to include tests done in the unit tests. This saves time for end to end testing.
• If a change request or improvement pops up in the feature, there is a high chance that existing functionalities are affected. But with TDD, developers can run all the unit tests after the code change without running the end to end tests.
• Fullstack capability of QE teams improve. Quality Engineers get the opportunity to understand the code and contribute to coding.
• Improves trust between QE and developers.

You may think that QEs have to put extra effort writing unit tests in TDD compared to other methodologies. Yes, initially the time spent to get used to TDD may be huge. But time spent on generating tests is saved later in the development cycle.

After all, TDD will make life easier for both QEs and developers.