Part I. Poor Trees
I really see no advantage of having all these test scripts that are made as excel spread sheets and then printed out in hundreds (don’t you hear trees begging: “save us”?) and given to QA team members to spend a couple months to follow and make sure every little condition/case is met.
Guess what happens when new requirements come in, or the old ones get changed… Spend a week or two going through all these excel files, manually refactoring every little condition/case effected. And then what? Regression testing ..ummm.. another two months?
Oh.. shoot requirements changed in the middle of testing, what should we do.. hmm.. print more paper. Poor trees…
Part II. Can I get some sleep please?
Let’s make all this process twice as effective, let’s offshore 50% of the QA (testing). Oh.. ok:
– Hello? Do you speak English?
– Yes, hi we are a great software company, and yes we do speak English.
– Great! Can I outsource 50% of my testing to you guys, so we have 24 hour coverage?
– Sure – we’ll be glad to do that for you.
– Awesome! I just sent you the package with everything that needs to be done.
2 a.m. “Hello. We are looking at requirements, and we did not find any definition for ‘A’..”
3 a.m. “Hello. We need to make an important decision, and we were wondering… ”
5 a.m. “Hello. Before we send you today’s status, we wanted to make sure..”
…
Part III. Open up a little
Of course we need people in charge of QA, and we need QA teams – the guys are great! They make us shine when we ship our high quality creation out the door. But can they be more effective, and do less work at the same time? Can they use technologies that are available, instead of using MS Office for things that it was really not made for? Can they ensure that whoever comes to test after them will not be lost, can pick up where they left off, and keep doing an awesome job? Yes, Yes, and Yes, and many more Yeses!
The hardest part is to let go the fear and the standards that were set 20, 15, 10 years ago for Software Testing. Yes, it made sense then ( maybe :) ), but now there are dozens of tools and practices that will increase productivity tenfold, you just need to open up a little. You can do it!
Part IV. Automate yourself!
Let’s look at the simple example of using some of these time saving tools. Here is how one of the test cases can be automated by using easyB and Selenium. The automated test itself will worth a thousand words, so here it is:
before "start selenium", { given "selenium is up and running", { // start selenium } } scenario "a valid person has been entered", { when "filling out the person form with a first and last name", { selenium.open("http://acme.racing.net/greport/personracereport.html") selenium.type("fname", "Britney") selenium.type("lname", "Smith") } and "the submit link has been clicked", { selenium.click("submit") } then "the report should have a list of races for that person", { selenium.waitForPageToLoad("5000") values = ["Mclean 1/2 Marathon", "Reston 5K", "Herndon 10K", "Leesburg 10K"] for( i in 0..< values.size() ){ selenium.getText("//table//tr[${(i+3)}]/td").shouldBeEqualTovalues[i] } } } after "stop selenium", { then "selenium should be shutdown", { // stop selenium } } |
And, let’s say Groovy is not your first language, and maybe you’re not a programmer at all, but really, can you read, and understand, that:
when 'filling out the person form with a first and last name' and 'the submit link has been clicked' then 'the report should have a list of races for that person' |
Ok, granted, you may not know regular expressions, and “//table//tr[${(i+3)}]/td” may be just a little over your head, but guess what.. It was auto-generated (by selenium) for you the first time you drove through the screens. And you know what the beauty of it is? It can run on it’s own, and it can tell you whether your application satisfy “this” particular requirement. You can schedule it to run every day, if you’d like, or every time the code is modified, or every Labor Day, or… you get the point. :)
Part V. We still need people, but they can be more productive!
“So what?”, you say, “One little test case – we have hundreds, and it would take us a month to create all these “automated” cases and scripts.”, and I say – yes, it may take a month now, but it will save you a year later. Why? Because if you create these scripts carefully, reflecting all the business requirements, these scripts will turn into the fastest, most accurate and “easy to interact with” QA team on Earth for your company/project. And that I would say, worth a month of work!
easyB example was taken from an extremely good presentation Industrial Strength Groovy by Paul King. Thank you Paul!