write the results to HTML on a network share everyone can access, send mail when the test finishes that the results are available (or better yet embed the report in the mail).. or link to it from sharepont or your team wiki or whatever collaboration tools you are using.
(see the html reporting class in the examples for a starting point) Run them really frequently (like if there is an automated nightly 'full build') so you catch a problem as soon after it occurs as possible. Then pray to your favored god(s) that a dev messes up and the tests expose the problem, because the instant that happens, management starts to see the value in what you've done. Seeing the tests pass is a 'feel good' and gives managers a nice 'warm fussy' feeling, but demonstrating that they can catch a regression that might have otherwise gone out the door is a whole level better than that. (because that kind of mistake can be potentially costly) The best way to silence naysayers is with results. If the results happen to be a nicely formatted HTML page, with the company logo on it, and nice color coded PASS and FAIL stuff, so much the better since managers eat that stuff up. The more visible your work is, (providing you are doing good work) the higher up the food chain in your org, the more likely you are to get support for what you are doing. On Apr 6, 9:54 am, George <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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?- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Watir General" group. To post to this group, send email to [email protected] Before posting, please read the following guidelines: http://wiki.openqa.org/display/WTR/Support To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/watir-general -~----------~----~----~----~------~----~------~--~---
