Tester-Driven Unit Testing: Taking an Active Role

Developers have so much to do that unit tests often fall by the wayside. One solution is to train testers to handle them. Testers get involved earlier in the development lifecycle, they can enhance their programming skills, and bugs are found and fixed quickly and easily, reducing the functional testing phase. Consider taking an active role in unit testing.

In software development projects, starting the testing process as early as possible in the coding phase is advantageous because bugs can be found and fixed quickly and cheaply. Depending on the company and project, of course, testers are expected to review and approve functional documents, and after approval, testers go on to design tests and prepare charters or scripts for the functional testing stage, once the software is “ready.”

However, very often in my experience, unit tests have been regarded as the development’s team responsibility, and—regrettably, for numerous reasons—the unit tests are not done. The main reason is that developers think there is not enough time to write and execute unit tests.

I understand that development teams are under big time constraints to code and move on to the next feature, and consequently, the functionalities agreed on in the documents often are not possible. Poorly documented or even undocumented changes are passed on to the testing team. At this point the testers are under time pressures to change and execute their tests to explore how the system now works.

As a test manager, I have asked if there is a way to solve these problems that appear in the late stages of development.

Getting Testers Involved Earlier

One solution that has worked well for my teams is for testers to take an active role in the late stages of coding, or even earlier if possible, by being responsible for unit testing. Whether the entire unit testing effort is taken over by the test team or testers just sit in as part of the development depends on the project, but I have seen positive results when testers take responsibility for writing and executing unit tests.

A further advantage of including testers in unit testing is that, by observing the code and creating unit testing assertions and verifications, testers learn the flow and function of the code and can use this knowledge in later test design. The testing team can and should be included in code reviews, but creating and executing unit and integration tests gets testers interacting with the code even earlier in the development process. By doing so, additional tests can find issues that the developers who wrote the code would not expect.

Testers who create and execute unit tests do so not with the developer mentality—that is, wishing to show that tests pass and that the code therefore “works”—but to write multiple tests that have finding bugs as their main purpose. Also, by tasking unit and integration testing to the test team, developers are freed to continue developing other features, reducing the time of the development stage.

Streamlining the Unit Testing Process

As I see the future of testing, I think that due to the rise of DevOps, agile, and continuous integration, testers with good coding or scripting abilities (the language depends on the tester) will be necessary.

The role of the software tester has become more complicated. No longer can we just read requirements, create and execute cases, and write bug reports. To thrive in the increasingly rapid world of software testing, we need to be able to understand and write code. A great start is to learn to write unit test cases.

I once worked on a project to test the website of a large telecommunications company. We were falling behind schedule, but luckily, we had an open-minded development manager who had no problem granting code access to a small group of technically minded, Java-educated, and, at that time, underworked testers.

User Comments

Simon Rigler's picture

Completely agree this is necessary for testers (including me), but I think you're making it sound easier than it actually is, for most of us! As you r said, you were technically minded and Java educated. There's a lot of testers that are starting much nearer to the beginning than this. Its a great goal though, and will be very satisfying to achieve, I just think it will be more than one project before we are writing the unit tests.

April 4, 2017 - 2:26pm
Priya Soundararajan's picture

Nice article. I did find it very difficult to switch to "unit" thinking from my "systems" mindset. Especially working with mocks, testing non-functional parts of the code etc made the learning curve quite steep for me. But nevertheless, I agree that it will bring a lot of benefits to the team as a whole. 

April 6, 2017 - 7:27am
Sanjay Srinivas's picture

How did this impact on the velocity ? Was testing able to absorb unit and integration testing ? Was functional testing replaced by unit testing or was that still conducted.


April 10, 2017 - 2:00pm
Anastasios Daskalopoulos's picture

With the cooperation, assistance and even encouragement of the Development Manager, Testing was able to write unit and, to a smaller degree, integration tests without any real impact on velocity.  I should have made it more clear (thanks for pointing this out) that we still conducted functional testing.  

In fact, creating the unit tests forced us by necessity to know the code well, with the result that we were writing more effective functional tests because we had a better idea where bugs were more likely to be found. We could also test with the advantage of critical distance, since it wasn't our own code we were testing.

April 10, 2017 - 3:13pm

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.