Breaking the Rules, Pushing the Limits

Testers should break the rules....

I come across a lot of Developer In Test roles these days, its a new trend that a large number of companies are adopting as they fully embrace Agile and BDD practices, or at least try. I think its good and productive to embrace Agile, its something that works and as a tester far better than waterfall era of giving everything to test in a short space of time at the end of a project. 

I am concerned however in the trend of the DIT role and what its doing to the test horizon, what worries me is this now huge lean on automation, and companies losing sight of what testing is really about, now it seems automating your Cucumber feature files are more important than actually finding bugs, and in some companies I have come across, leaving functional testing to the BA's whilst your DIT's just write automation code or even worse, making the developers that actually wrote the code now functionally test it (recipe of an apocalyptic ELE for your project).

Testing is about finding bugs, about hacking and breaking, its about pushing the application you are testing to the limit, and as a tester to get the golden egg, is to make the application fail, or even better crash. 

Can you find bugs automating? well if you are automating correctly yes, if you go beyond the UI layer and start interfacing into the service layer and back end systems you can learn a great deal about a system and how it works, and the most useful automation suites I have come across and developed do this, automation goes beyond the Selenium/Webdriver tests that have come to gain huge popularity and notoriety like Kim Kardasian after her sex tape, you have to get past the surface and beneath the sheets (no pun intended and certainly no links included).

Automation is your safety net, and if done correctly as part of the testing process a great and important safety net to have, but you must do it properly, and if you want to learn to do it properly follow these blogs, for me these are true experts in the automation field:

1. Nat on Testing - If i am having trouble automating a feature, i come here first 9/10 hes already done it and blogged about it.
2. The Evil Tester - Mr Richardson has a great Selenium/Webdriver course on Udemy, if you want to learn how to write automation code in java properly, I strongly suggest you take it.

Im writing this because I recently got dropped onto a project that was about to go live, there had been a huge push on automating the application, and indeed a lot of time and money invested in this task. When I got given the application to test, in the first 10 minutes I found a major bug, its one of the first things I test for when I get given an web application.....XSS. What really struck me even more was how easy it was find, I didn't have to pollute some AJAX requests going on behind the scenes, that I only found by looking in the Firebug Net tab, nope all I had to do was put some encoded js into the url after the search input parameter, it was really that simple. 

It certainly showed me that the testers were far to busy automating than finding bugs, they lost their identity, they were not the super hero testers that they should of been, they became developers writing automation code, a waste of testing talent.

So by all means automate, but remember why you are there, and why you got into testing in the first place, push the application to the limit, and break the rules. Ill leave you with a great clip from an average movie, here the test pilot and his pilot buddy are set the task to test out a couple of drone aircraft that apparently are suppose to wipe the floor with their human counterparts, study what Hal Jordan does to beat them, and try and take this metaphor with you to work, albeit without the green spandex.