Dreaming of Software

Testing your software will make you happy, and do you know why? Because this will make your customer happy and trust me: Nothing is worse for a Software Developer than an unhappy customer as it means your boss is unhappy and then … you know the rest for sure.

But why is testing software carefully then something that is neglected by a lot of software developers? The answer is easy: Testing is not seen as the fun part. It is not seen as part of the creative side of this work in comparison to the actual software design and coding (huh, that is cool). It is typically perceived as boring. And of course as a developer you are anyway sure that everything works, I mean hey, YOU have coded it and you have taken care of everything, don’t you?! Finally testing - at least in traditional development methods like waterfall - is always happening at the very end of a project. And as the project is anyway already late some program and/or project managers will push you - the poor Software Developer - hard to get things finished. Fine for the developer, who anyway hates testing, and is just throwing it over board happily. Thus getting rid of that “stupid task”, saving time and thus bringing good news to your project manager as. A very dangerous combination that is unfortunetly seen far too often still.

Sounds familiar? No? Then you are probably a happy developer already! Yes? Let’s try to change something as the described scenario is not caved in stone.

Let us assume you are a software developer who is responsible for testing as well; what can you do? (Things will be different - not necessarily easier - in bigger companies having own test departments.)

• Accept testing as part of your job - or try to get rid of testing entirely
  You do not have to love it, but it is part of the job like software design and coding is. So you better start accepting it as such and not just as a nasty aside. Or maybe you have the opportunity to get rid of it more or less entirely. I know of one brilliant software developer who is really awful in testing - and everyone in the company knew it - so basically testing his software is most often assigned to other developers. Maybe this is a possible way to go, but open communication on this within the project is the key here.
• Learn something about Software Testing
  I am sure you have visited some trainings about oo-design or read a book. You are constantly looking for the latest design patterns in your favourite blog and of course you learn the changes in the API of every new Java Edition that is released. Ok, then why don’t you do the same thing for the testing part (uhm, I remember, I was writing it is boring)? But maybe it will no longer be that boring once you have learned more about it. It might even feel extremely cool delivering software with less bugs. And I am sure there are even ways to be very creative in testing. Test automation could be the key here. I am sure it is worth it. But keep in mind what is the sole purpose of testing and let’s not be taken away by trying out every fancy technique leaving you with - you guess it - no time for the actual testing in the end.
• Consider testing when asked for effort estimations
  Sounds trivial? Yes it is and it is nevertheless not considered far too often. The project manager is asking you for some effort estimate and the thinking goes like “yeah, small code change here, some XML changes there, nothing really impressive, let’s say 5 hours”. The project manager answers: Great, this is really urgent, do it right away, we will deliver tomorrow afternoon! Well, noone was saying it must be delivered, I mean, this is changing quite some part of the entire logic and … well, bad luck, too late. When we have productive software then changing parts of it in 99% of the time means it must be productive software still afterwards. And that means it must be tested and even if the change in the code takes only 5 hours it might be very well the case that re-testing these changes takes several days. Period. (Of course this does not mean that there is not some project manager promising things earlier nevertheless, but that seems to be somehow unavoidable.) Thus always include testing in your estimates unless you explicitly state it is not included.

Of course there is a hell of a lot more to say on this topic, but I want to come to an end for now. There will be more posts on this topic here for sure. For example testing in an agile project setup has quite some other/additional challenges, but this does not mean you can do less testing. The opposite is true as you are delivering more often. I already touched the aspect of test automation which is the key here for sure.

I was also mentioning working with a test team earlier in this post and want to say at least a few words on this still. Of course this changes everything as typically software developers are then no longer responsible for the actual testing (I am not talking about module/JUnit testing here of course). But typically this requires then some close co-operation and thus we are back in the testing business somehow. This setup indeed has its own pitfalls and I think it is worth a blog post of its own as well at some later time. But just in case you have not yet heard of it the IBM Black Team might give you some inspiration what good testing is about and that it indeed can be very satisfying.

Now, IBM in the 60s was not exactly known fostering creativity in the workplace. Corporate identity was bound up in dark-blue suits and starched white shirts. Management, however, not only tolerated what was happening, but loved it. Perhaps they felt some admiration for a group so passionate and dedicated, but the bottom line was that software quality was improving at a rapid rate.

Personally I have no real preference for doing the test job as then I would be a software tester and not a developer. But from experience I have simply realized the importance of doing a good job in testing … and coming back to the beginning: It gives me some peace of mind as I know who is in trouble in the end if things are not working as desired.

Somehow I feel that I have doomed myself with this blog post as I am quite sure my boss and collegues will dig this out the next time I mess things up … I better do a really good job in testing ;-).