Testers vs. Developer – United in the Name of Quality

In my last post I wrote about how the Product Owner can help to increase the quality of the software without crossing the line, staying in the framework given to the Product Owner role. Although I wrote, there are plenty of articles about how developers can increase software quality, I still want to do a follow up on my last post. Just to have both sides covered.

So what do we have in our toolbox for developers? First there are plenty of tools and it would take me a while to describe them all. Therefore I will elaborate on just a couple of them in detail.

I assume the fact we are talking or thinking about quality means we want to write good software and don’t want our customer to find any bugs. Therefore we are all testing our software. It starts with the developer, who will run the code he just wrote and ends with somebody testing the complete software. I am writing somebody, because some people might not have dedicated testers in their project. That’s the point to start at – get a tester!

Wait, wait! Don’t leave!

I know, it seems like it is a sure thing to have at least one dedicated tester, but not to all out there. Some people believe, if they click every single button, their application has, and they work everything will be fine. Later, same people wonder why customers start to complain and number of sells drop as fast as Voyager 1’s current relative velocity (61,452 km/h or 38,185 mph). A dedicated tester is doing much more than clicking buttons and checking the website whether it does or does not look exactly the same in every browser.

The tester works the software with all his tools all day long. He is the developer’s antagonist and buddy trying everything to break the software to get his win. On the other hand he helps the developer to write better software. This constellation keeps both in a continuous contest. The developer tries to write the best code he can, knowing the tester will try everything breaking it, but in the end they work as a team to deliver a great software.

Now let us become acquainted with some tools and practices, which will help you to write better code and find more bugs. Some of them are part of or emerged from eXtreme Programming. The first tool I will talk about are
Unit Tests they help you to test small and isolated units of your software. For example they can be used to test the value your method returns or if the right kind if value is received(e.g. the test will fail if you receive a string instead of an integer). In the last years, with the rise of agile development, it became a common practice to run automated unit tests and to write the test before your actual code. The latter practice is known as Test-drive development or short TDD.

Test-driven development is one of the most powerful practices in agile development some would even say the most powerful of all. It helps you to understand your actual requirements and therefore helps you to get a clear vision of the design needed and to write clean code. Some people also call it Design-driven development, because of that. You can practice TDD in so called Coding-Katas on your own or with a partner in a Coding-Dojo. It’s fun and you will not just learn about a lot about TDD, but also about refactoring by doing it. TDD also forces you to get used to refactor your code, which is another practice very important to raise code quality. For more information on TDD take a look here. Just one more thing, in 2003 Dan North introduced Behavior-driven development to the agile community. It is supposed to encourage collaboration between developers and QA. So may be you want to take a look at it, too.

Let us not forget about acceptance testing! By acceptance tests I mean automated acceptance testa. Automated acceptance tests will help you to save a lot of time. Time you can spend on new and even more tests. Selenium is probably the best known acceptance test framework to test your web applications.

The last practice I want to tell you about is called continuous integration. Continuous integration basically closes the circle and is very important. The first three recommendation of continuous integration are: to have a repository(no matter if it s Git, SVN or oldschool CVS), automate your build and make the build self-testing. This saves you a lot of time and gives you security knowing, that all tests were running and passed, assuming the build did not brake. These three recommendations, in my opinion, sum it up quite well, why I think continuous integration is very important, because it takes all the tests we have and runs them automatically. All we have to do set up our continuous integration system and write the tests needed. At least that’s the idea behind it. ;-)

So get yourself and the team moving setup your automated build system and start to write tests. It does not matter, whether you are at the start of a project or in the middle. Just start to write tests for every new module and every bug you find. You will see it will rock!

Leave a Reply

Your email address will not be published. Required fields are marked *