In search for lazy testers…

5 thoughts on “In search for lazy testers…”

1. I agree. Nice article

   Reply

2. Hi, nice article
   “We’re working too hard and thinking too little. ”
   I agree, this may be a problem sometimes
   “Automate testing as much as possible, banish manual test activities where and when you can!”
   I don’t agree with that, manual testing is sometimes far superior to atomatic. Sometimes it’s vica versa. But it is definitly not “where and when you can”, it is “where and when it is a good solution”

   Reply

3. I am unsure where to start with this post, it has set of so many alarm bells I am still trying to turn them all off after 15 minutes.
   So am I going to start at the top.
   Why are you leaving this “regression” testing to the last minute, why aren’t you thinking critically about the areas that new work may have impacted and testing those while you are testing new features?
   Why not address why these “inadvertent” errors are creeping in instead of using “regression” testing as a safety net for poor development practices?
   Regression testing, is testing, therefore it cannot be automated. Testing can only be performed by humans. What you post mainly refers to is checking, you can read more about that here, http://www.satisfice.com/blog/archives/856.
   Regression testing is testing focused on seeking regression, automated checks can be great test ideas for this. But checks can still pass and a regression be present, so be wary relying on just checks for your regression testing.
   You make a valid point, humans are bad at checking, we’re curious, and observant. Our eyes provide information continuously which our minds promptly digest, formulating new questions we could ask the product, continuously seeking new information, testing. Computers cannot do this, as they cannot think, they are dumb, they can only do and observe what we tell them to do, perfect for checking.
   So now let’s talk ROI. Why do we need an ROI for creating some automation? We are testing, just happen to be using a tool, automation in this instant, to support our testing. It is not separate to testing.
   “100% predictable in their actions”, they are that. But the system they interacting with is not. So surely you would want to add some maintenance into that ROI equation. They continuously need re-educating, again something only a human can do.
   “Testers of the world, I call on you: unite and be lazy! Automate testing as much as possible, banish manual test activities where and when you can!”
   I have to assume being a professional tester, that what you have written here is not what you intended, perhaps a little sloppy in your writing. Something I can certainly not critique, but am going to attempt to translate this to what I think you intended to say.
   Testers of the world, I call on you: unite and be smarter! We know there is a difference between testing and checking therefore use automation intelligently, we know checking is important and best suited to automation, so let’s do that. We are humans, we process the skills do seriously good testing, we want ot avoid wasting them manually checking. But we also know that checking cannot exist without a human tester re-educating it, so we always need to be seeking new information about the product to ensure our checks are checking for changes in the information we care about. Testing is a manual activity, checking is encompassed in testing, just happens be to one aspect of many where tools can support us. Be critical, be smart, utilise tools where you can.

   Reply

4. Hmmm… You seem to have got it all wrong with your last sentence, and it is very misleading to anyone who reads the article. Its a major misconception about automation that many people have, so I’ve commented so that I can try and dispel this misconception so that you can then promote what automation is and what automation is not, so that others don’t fall into this false “magic wand” belief.
   1) You simply cant automate everything. You can only automate what you know and expect. This means that if you know how something should work and have an expectation of what will happen when you perform an action, then you can automate it. You are “checking” that the system conforms to what your expectation is… But, you CANNOT automate anything that you do not know. I repeat – anything that you don’t expect you cannot test for using automation. Computers cant think. They can only do what you script them to do.
   2) You never know everything. Especially up front in the project. What I mean by this, is that you might get a nice requirements document, with lots of requirements, but I can 100% say for sure that the requirement will not give you 100% of the information. The requirement will also have multiple ways that it can be interpreted. An example (lets make it a really simple one) – Lets say that a customer asks for a new text field to be added to a form and the field is mandatory. You might write an automated script to check that when you enter data into the form and save the page, then check your expectation that the form has saved correctly. Then you might script another check to try saving no data into the field and check that the correct validation message that you expect actually appears. But did you know that there are actually over 60 different other ways that this input field might fail?
   Think about all the different input types? How does your field handle ASCII255 characters? How does it handle spaces (if its supposed to be mandatory)? What about security? How does it handle a javascript alert script being entered into the field? What about a SQL script or HTML tags? What about the character limitations for the field? Can the user enter more 500 characters (and if so, what happens on the server side? is it limited to 255 on the server side? wouldn’t that frustrate the user if they had entered 500 characters on the client side?). Then what about the different ways a user can enter data into the field? How about pasting data in from the mouse? Or pasting from the browser? (I’ve seen bugs surrounding these tests). What about accessibility? Tabbing on to and off of the field? The colour and size of the text field? What about the placement of the field? Is it intuitive? What about interruptions? if the user tries to save the form and there is a validation problem on another field – is the data removed? that would be frustrating for a user, eh?
   This leads me to the next point…
   2) Is there value in trying to automate everything that you know?
   The way I see it, Automation is fantastic. I’m not being sarcastic here – I genuinely love automation. You need to utilise automation to be agile. But, it wouldn’t be very lean or agile if you tried to automate everything that you know, because that’s just not valuable. The biggest benefit for automation is REPEATABILITY in the sense of a check having to be repeated over and over again in the exact same way.
   Would you need this for all of the 60+ different tests for each of the text field? Nope. You’ll probably want to have repeatability for the happy path and the validation rules around the field.
   I hope that this comment gets approved, and if not, I at least hope that you take the time to read this comment and learn why the last sentence in teh post can actually be quite damaging to people who don’t fully understand automation, as it can harbour false beliefs and misconceptions, which are bad for everyone.

   Reply

5. I totally agree with the comments from Richard and Dan Ashby: they gave a really good explanation about the huge difference between a check and a test and about the automation use and its reliability.
   I think the article was not meant to be too serious but more an encouragement/provocation for test automators…or am I wrong?

   Reply