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.