| STAQS |
Software Testing and Quality Services Ubi dubium, ibi opportunitas. |
| Home | Articles & Presentations | [ Lessons Learned ] | Blog |
"I keep six honest serving-men (They taught me all I knew); Their
names are
What and Why and When and How and Where and Who."
- Rudyard Kipling
What I know about Software Testing comes from the School of Hard Knocks -- i.e. stuff I've read in books and on the internet, things I've tried (and failed and tried again), conferences I've attended, workshops and seminars that I've participated in, and from discussing ideas with some of the many smart people out there (consultants, authors, professors, fellow testers, my wife, and so on).
After a while you begin to see the patterns of what's likely to work and what won't in certain situations. This page captures some of the things I've learned about Software Testing over the years and some of the links that I've found useful on past testing projects.
| Quick Section Jump: | Ruby and Watir, Exploratory Testing and SBTM, Internationalization Testing, Security Testing. |
I have been using Ruby and Watir (Web Application Testing In Ruby) for a few years now, and I am totally hooked on Ruby! Never in my life have I been so productive in developing test automation scripts as I have been with Watir! (Mercury who?)
>> Navigate to my Ruby page for more information, tips, tricks and references. <<
Ruby and Watir together provide a free, powerful test framework to help you test your web apps. Where do you go from here?
The answer to that question is tricky. Many people think that the answer lies in the programming side, but I think it's more important to understand the testing aspect first. That is, do you really understand what it is you are asking the computer to automate? Is the test really worth automating? How will the computer detect errors or bugs? How will it recover from unexpected events or errors? What value will you get from running the exact same test repeatedly? and so on.
Final thought: Break free of the testing norms of specifying the exact steps and test data required to drive your test scripts. Teach your automated scripts to perform exploratory scripting -- i.e. learn as it goes, and vary the inputs for each run! (more on this topic another time..)
>> Follow this link for a page dedicated to the SBTM and ET lessons that I've learned over the years and to download my Ruby SBTM tools <<
Lots to say here. Where to begin? In a nutshell, ET is a form of unscripted testing that requires skill, creativity and discipline to effectively go where no tester has gone before. The productivity and effectiveness of an Exploratory Tester will greatly surpass that of any generic scripted testing approach any day. The reason for this is simple - the focus of this approach is on the learning and iterative nature of testing to leverage the system feedback to maximum effect. Traditional scripted tests put the focus on writing test documentation and test cases - which can be an incredibly huge waste of time, money and brain power.
There are few ET articles currently written that I really like. I recommend starting with the basics and moving on from there. It will likely be very difficult to learn to do this by reading alone, so I suggest you network and find people to share experiences and knowledge to help you pick it up quicker. Try conferences, workshops, or presentations in your local Testing community.
Start with an introductory article: "What is Exploratory Testing?" Exploratory Testing is defined here simply as the concurrent Learning, Test Design and Test Execution.
Once you accept the idea that unscripted testing can be more effective than the documentation-based alternative, you will need to find a Test Framework to help you manage your testing. I've used the "Session-Based Test Management" (SBTM) framework that James and Jonathan Bach developed. I've met some people who have used WIKI's as an alternative to SBTM. The idea is the same, just the metrics and visibility to the test notes are different.
I find that this style of exploratory testing is a perfect complement to Agile Development projects where changing requirements are common and rapid feedback is desired. ET is often my primary approach to testing new projects because it allows me the freedom to explore features and investigate ideas more rapidly than by other means.
Internationalisation (I18N) and Localisation (L10N) testing are a lot of fun! I wrote an article titled "Testing with an Accent" which appeared in the February 2005 edition of Better Software magazine.
There are a lot of useful links on the web. Here are a few:
Here are some ideas for when you're actually testing:
Fun, fun, fun! When all is said and done, how safe and secure is your application or system?
For me, much of Security testing is like I18N testing - an integrated part of how I just regularly test software. My focus lately has been on testing web applications. (Just the web application itself though, since the whole system is covered by a myriad of security protocols, audits, firewalls, and other barriers that are well beyond the scope of your average test team.)
Here are some helpful links:
Some starter books that might be of interest include:
| Home | Articles & Presentations | [ Lessons Learned ] | Blog |
Contact me at: paul [at] staqs [dot] c o m