2 Ways Developers Can Contribute to Better Testing
Development teams expect their testers to do a good job. This usually means the testers need to find important information about product quality, present it in a way that can be acted upon, and do these things in a timely manner. We also want to get this information in as much as a hands-off manner as possible so the team can keep making software.
Here are two ways the development team can help testers in their efforts toward great testing.
Monitoring
Some of the things you do in a browser only happen in the browser. You can see the good and bad of working in your web browser by opening the developer console. If you want to save or retrieve data, though, you’re going to want to make a call back to a server.
These calls show themselves in the network tab. Every time you submit a form, the associated call and response will be in that tab. When something goes wrong, you can hunt down the call that failed and look at the response for the HTTP code and any message that was sent back.
Monitoring makes software more testable because you can get an email for every error that happened—even if you didn’t know it happened—right in your inbox, accompanied by the full stack trace. Now all you need to do is remember what you were doing when the error happened.
Unit Testing
Unit testing improves your ability to test in a sneaky sort of way; you have to look to see it.
A couple of weeks ago I was working on an untested bit of code. It was complicated because it was using recursion, and it did not have any unit test coverage. We had a hierarchical data set that was originally only displaying children, and now we want to display parents, too.
My coworker and I iterated over a few (not so great) ideas and then settled on a good path forward. We started with a couple of tests and worked our way through the rest of the change, adding tests where we thought they were appropriate.
The resulting solution was easier to understand, and it was unit tested, so if any further changes broke something we would know right away.
Since the code was simpler and supported by tests, this change was easier to explain to the customer. We had a full comprehension of the data model, knew what the customer was expecting from this graph and how it supported their work, and understood how our change would make them more effective.
Code that has been unit tested is generally simpler, better understood, and has a more thought-out design.
The main goal with these two techniques is improving your ability to observe your product. Monitoring your test environments helps the test team know when something bad is happening that they would otherwise not know about. And unit testing makes the code easier to observe because simple code can be better understood and explained.
