Quardev speaks, exhibits at the 2005 StarWest Conference
Quardev Laboratories, a premier outsourced software testing and technical writing company, will be exhibiting and speaking at the 2005 StarWest Conference. We'd love to meet you! Stop by our booth (#68 near the food service area).
Our own Jon Bach will be speaking in two time slots - both are sure to be worth your time to attend:
How Much Quality Is Enough?
Jon Bach, Quardev Laboratories Wednesday, November 16 @ 11:30 A.M.
Are you striving for more quality than you really need? How would you know? Good enough quality does not mean substandard or mediocre but is actually an optimal and responsible economic principle we use everyday. Managing test lead for Quardev Laboratories, Jon Bach says because quality is expensive, the good enough framework provides the criteria to enhance decision-making about when to ship. He discusses the perils of quality-at-all-cost techniques and shares examples of software that features sufficient quality. Find out how testers and test managers can help project stakeholders know whether they are releasing software with too little quality or are unnecessarily striving for too much quality.
- Four criteria to assess if your software is good enough
- Three context-driven questions to ask when deciding if software is ready to deliver
- A simple spreadsheet technique for measuring good enough-ness
Presenter's note: This talk was created because I wanted there to be a voice for those with common sense -- who know that there are many techniques and approaches for testing software, but who may be feeling pressured to use every available technique there is out of fear of missing something. That fear is natural and healthy, especially when people talk about the common economic realities of software -- little time and little budget. But wait let's talk more about those two constraints before we delve into our fear! Could it be that the testing we have is good enough for now, or good enough for our customers, or good enough to meet perhaps not all of the objectives we set forth, but the most important ones?
To me, that's what "Good Enough" means -- "not more quality than we need." One definition of quality is "value to some person that we know of." Let's talk about who that person is. Are we trying to build more features than they need? Or we running the right set of tests to find the problems they would likely find? Could it be that the software we just bought at OfficeMax for $2.99 has more than enough quality for us? Since you can't make a decision about whether something is "good enough" without also talking about economy, let's talk about how we choose test techniques and approaches in terms of the cost we pay versus the value we get in return. This talk is meant to help that discussion.
Testing Outside the Bachs: A Hands-on Exploratory Testing Workshop
James Bach, Satisfice and Jon Bach, Quardev Laboratories Thursday, November 17, 9:45 A.M.
Simply put, exploratory testing means designing your tests as you perform them. When it's done well, its a fantastically productive and rewarding approach to testing. However, to do it well requires training, practice, and discipline. Lecture presentations about exploratory testing are a poor substitute for seeing it and doing it. So... plan to bring your laptop to this session and test along with James Bach and Jon Bach as they demonstrate exploratory testing in a live testing workshop. Participate or just observe as exploratory testing is performed in real time with play-by-play and color commentary. Learn how to bring structure to this apparently unstructured testing method. See if you can find bugs that they do not find as you test outside the Bachs!
If you plan to bring your laptop and join in this live testing workshop, email firstname.lastname@example.org or email@example.com, for directions on downloading the software onto your laptop.
Presenter's note: My brother James and I were asked to do this talk. When it was posed to us, it was easy for us to accept. We're both testers, James with over 20 years of experience, me with an even 10. But even with all this experience, we consider ourselves students of exploratory testing. For example, just this year, I got interested into how exploratory testers take notes as they test. I've also been fascinated how some testers never run out of ideas, and some run out after an hour of exploration. This has prompted me to study heuristics in greater detail, and more specifically, how we're triggered into thinking and inventing new test ideas on the fly.
We're on a bit of a crusade, my brother and I. After decades of exploratory software testing in action and only slightly less of that time with it defined as "exploratory testing", we find that people still don't understand what it is -- even people with years of experience in software testing, including us. What we hope to do with this demonstration is get the audience involved, to demonstrate (and learn) new ways of thinking about exploration, and to show that exploratory testing is not a technique, but an *approach*.
There's an important difference in these two words. An *approach* is a way to engage a particular *technique*. For example, an exploratory testing *approach* can involve *techniques* like claims testing, regression testing, stress testing, scalability testing, compatibility testing, and on and on. Likewise, you can use those *techniques* with a scripted *approach* (like test cases).
But even if your tests are scripted, you are doing exploratory testing whenever you improvise your testing based on the results from the test case -- for example, inserting and executing a new, unscripted test idea that occurs to you as the steps of the test case unfold. This is why people get confused (and rightly so) between an approach and a technique because where does scripted stop and exploration begin?
I like to think of it this way -- exploratory testing is like playing 20 Questions. You likely won't win by submitting your questions in advance, so to guess the animal, vegetable, or mineral that the other person is thinking about, you have to adapt your questions as they are answered. This talk is a demonstration of that kind of real-time adaptation.