The title says it all. Some employees in our company believe that automated tests are "easy" and that it "should take a day" to write suites of COM and UI tests. What can be done to counter this?
Note: I'm not asking about how to promote automation. That isn't the problem. Automated testing and processes are being promoted and requested all the time here. The issue is that some individuals don't understand that automation is not "easy" nor is it "fast".
Next time you get a request try to break down as much of the automation process down into chunks of time. I think when they realize that it takes 5 minutes per text field or button push they start realizing how long it takes.
For instance, maybe why it takes so long is that they start introducing interdependence among the fields: e.g. only allow them to proceed if this is filled out but not if this this aren't, except when....
Try to educate them on WHY it takes so long, but not so much as you lose them through the "learning" process.
In my roles i've come across many "x is easy" people especially on development projects. In my mind there are three reasons for this:
1) They really don't understand what they're talking about but very much like to sound like they do.
2) They've read a couple of books and think they know what they're talking about
3) Lastly people assume because a computer is doing the testing its fast, because computers are fast.
The one sure fire way to combat this is to engage users on a regular basis, communication strategies for projects are key, certainly explaining the ins and outs of automated testing to non technical users is going to be futile but making them aware of the processes involved can be beneficial. You can do this either via documentation, workshops or just a friendly chat next time your passing through.
I've even seen a BA single out the loudest of these "x is easy" people and simply invite them down for a day in the department, with the thinking they'll either walk away understanding more about what you do OR they'll simple come away thinking "god I really don't know what i'm talking about, I think I was wrong".
Software is the business of automating things.
We write software to make boring, repetitive, and labor intensive tasks easier for us. We write software to automate making reports, gathering data, communicating with others, etc. Writing automated tests is really just writing software to make sure our other software works the way we expect it to.
If your coworkers understand that writing software is hard and takes time, it should be fairly easy to show them that writing more software should be hard and take time. It would be nice to get all the benefits of automation for free, but, as always, we need to put the work in up front to get the benefits later.
If they don't understand that, you either need to work on teaching them that or work on polishing your resume.
Most employees spend their time in either the "front" (client- boss- stakeholder- facing) part of the company or the "back," (where the "real" work gets done). These two functions are different, almost opposite. (And very few people have worked in both). As a result, there are often misunderstandings between the two groups.
The best way to educate e.g. "front" people, is to have one or a few of them spend a day in the "back." If they completed "A day in the life of...," they would have a more realistic idea of what can be done in a day, and why it takes more time and effort to run automated tests. Likewise, "back" people could benefit from a day or two at the "front."
In "How to be Rich," John Paul Getty (a tycoon for his time) advocated such "cross-training." In his view, a salesman who spent time on the assembly line where the product was manufactured would do a much better job of selling, and likewise an engineer who spent a day with clients would do a better job of "debugging."
The issue is that some individuals don't understand that automation is not "easy" nor is it "fast".
I don't agree with your premise here.
I am a big proponent of automated testing, no matter if it is unit testing, integration testing or UI testing. There are a lot of great tools available to implement automated tests.
Let's compare automated testing vs. manual testing based on the following example:
In a web application, test the "Change Password" functionality of an existing user using a browser.
Manual testing:
Easy? Not really. There are a lot of possible pitfalls in the process.
Fast? No. Manual work takes time.
Now, lets try to write an automated test:
Easy? No! We needed to research the tools, implement them, fix some bugs in our tests.
Fast? No! It takes even longer than doing a manual test.
But, there is a big difference here: For future tests, you only need to write the test itself, the last bullet point in the list - which was done comparable fast. All research and init-scripts do not need to be done for further tests.
And after you have written the test, you can start it easy. In a few seconds (or maybe minutes, if starting of the database and webapplication takes long) you see if the "Change password" routine works or works not. If there is a bug, fix it, and run the test again - you will immediately see if the bug is fixed. Fast and easy.
Writing automated tests is neither easy nor fast in the first place, but executing them is.
And this is the point where the invested time comes back.
Testing in general is not easy, and nor should it be. If Boeing or Mercedes didn't test their products as rigorously as they do then they would either be bankrupt due to law-suits or go out of business for selling such poor quality items. Would you drive a car at 70 miles an hour knowing that the steering wheel may or may not fall to pieces?
It's very hard to suggest ways to cope with the mindset without understanding who those people are, or their reasons. Most managers and directors think of costs and are judged by what is produced. Using this criteria makes it very difficult for them to justify spending time on tests. If this is the case with you then you will need to find ways to present this task as being beneficial in the long run, which of course it is.
Just because software isn't tangible doesn't mean that we can get away without thinking about the implications of the systems we build not working. I bet Amazon have automated tests and I bet there are people there who know only too well the cost implications of their websites/services failing.
2 +2 = 4 is one of the most simple piece of code that everybody understand; And you can see how is easily understand. But this does not mean it's a “easy” equation. The level of abstraction that are needed to reach the simple equation is quite complex. Same happens with the software and software testing methodologies. The level of abstraction that requires a piece of code takes a lot of work.
It is true that a good practice leads to reuse classes and objects but equally, to reach this state is necessary to invest time and effort.
There are two sides to this question.
On your side, you appear to think that you are doing a good job, and that the "Automation is easy" group don't know what they are talking about.
On their side, from what you say, they see automated tests taking (in their view) a long time to produce.
From this distance, with the little we have to go on, we don't know who is "right", or if anyone is "right".
How to deal with the automation is easy mindset
Talk to them. Honestly ask for their ideas on how it can be done better. Get them engaged and involved. It's the only way to find out if they really have anything positive to offer. Maybe they do have some worthwhile contributions to make, and you can achieve a win / win.
If they don't have any real idea how programming and automated testing works, or realistic ideas for how to improve productivity, then having engaged them positively you can show how it's done and where the time goes. Be humble and positive, thanking them for their input / ideas. Think about what they've said: maybe their suggestions will trigger a different way of thinking for you. If so, give them that feedback. By being humble and positive you can make it a win / win also.
Before you talk to them think about how you build, run and manage your tests. What framework(s) are you using? Are there others that could be better? Do you have "standard" boilerplate that you adapt? Could building the tests be more automated? What's holding you back?
