Right now, I'm creating simple regression tests that we can run after every patch/version update. And, you're right - there isn't much of a chance of these tests failing. We're automating this because it's boring to do manually.
As far as the quick win, I have already completed quite a few scripts for a couple of our web apps. My manager has actually been great as far as being an advocate. The challenge for me as a beginner is that I'm constantly seeing ways I can refactor the code to make it better, or add functionality (such as writing the results to an Excel file), so I may be working a little too long on these. Perhaps with the introduction of the Watircraft framework, the process of writing scripts can be a little more streamlined. Truth be told, I actually don't mind the unpaid overtime. Learning Ruby/Watir is a lot of fun and it doesn't even seem like work to me. It's just unfortunate that official work time can't be alloted to this effort. On Apr 5, 5:11 pm, Chuck van der Linden <sqa...@gmail.com> wrote: > I've run into both. I've seen orgs where the mandate 'automate > everything' came down and everyone had to become a SDET (software > development engineer in test) or find other work somewhere else. > I've also seen places that having been burned by automation snake oil > (see stuff by james bach for good examples of this) and there was a > strong mindset of 'automation doesn't work' > > I my mind it's just a tool, a powerful tool if used wisely, but an > expensive and frustrating one if not used properly. In terms of > tools, if manual testing is a drill, then automation is a hammer. > while it might be possible to somehow use one to do the job of the > other, it's not generally the best idea. > > It seems to me that you are in a trap. You've been given a task but > not empowered to complete the task. That's frankly not fair to you, > as you are being setup in a situation where you have to work basically > unpaid overtime or fail in your goals. > > One potential way out is to get yourself a quick win, demonstrate some > success with automation (and learn the time it takes you to do it) and > then demand that they either give you the time or remove the task, > since you are in a no-win situation otherwise. > > Testing automation works best IMHO in one of the following situations > > 1) same test repeated frequently e.g daily unit tests, build > validation tests, acceptance tests (if you are using them as a way to > track progress and show what's working and what's not instead of just > at the end) > 2) same test repeated with different data: e.g. combinatorial testing > (like testing the word 'font settings' ui), or testing an input field > with a large number of 'valid' vs 'invalid' values to see that they > are all properly accepted or rejected. > 3) not humanly feasable or possible (loadtesting, performance testing) > 4) Utiities to save time (does it take 2 hours to setup your test env > and load it with data? automate it) or improve testing process (is > the environment setup complicated with ots of settings that need to be > set the same way to allow test results to be replicated?) > 5) regression suites which are boring as hell to execute manually over > and over.. > > One problem is that many of these rarely find bugs after the test is > first written. and since a tester's goal is generaly to find bugs, > that can be a problem. > > If I'm looking for a quick win, I want something that can benefit the > entire team, so something like a useful utility script (if you've a > need for one) or a BVT type test to save people from wasting time with > bad buids, might be your best bet.. The tests of type 3 are often > complicated to setup and may require a speciaized environment to run > them, so that wouldn't be my first choice, OTOH managers LOVE graphs > and numbers so something that reports on the product performance and > can be run on each build might be a way to gain some good visibility. > > What is it you are assigned to do in terms of scripting? can you find > something in there you believe might represent a potential 'quick win' > and/or proof-of-concept? > > On Apr 4, 11:14 am, George <george.sand...@gmail.com> wrote: > > > It seems that I've been encountering more people within my workplace > > (and, alas, even within my own QA team!) that are not sold on test > > automation. From what I've learned so far, there seems that automation > > will never cover 100% of what needs to be tested, but this doesn't > > negate the need. > > > Another frustration is that I've been tasked to write automation > > scripts as part of my year-end goals. However, I haven't been assigned > > hours in my work week to do them! All of my script development has > > been after-hours and weekends (notice I'm posting this on a > > Saturday!). > > > Has anyone else run into naysayers? How can I convince the decision- > > makers that this is a worthwhile effort? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Watir General" group. To post to this group, send email to watir-general@googlegroups.com Before posting, please read the following guidelines: http://wiki.openqa.org/display/WTR/Support To unsubscribe from this group, send email to watir-general-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/watir-general -~----------~----~----~----~------~----~------~--~---
