Kategori: Conferences and classes

The following text is copied from James own website www.satisfice.com and describes the purpose and content of the Rapid Software Testing Class

When someone tosses you a program and says "you have one hour to test this" can you do it? Are you confident in your work? Can you explain what you did and why?

This unique 3-day course introduces you to Rapid Software Testing, the skill of testing any software, any time, under any conditions, such that your work stands up to scrutiny. Based on the ideas of James Bach, Michael Bolton, and Cem Kaner, with substantial contributions by other members of the Context-Driven School of software testing, this is the closest thing in the business to a martial art of software testing. Because we emphasize exercises, it is challenging for experienced testers, but works for new testers, too. This course provides hands-on demonstrations and drills as well as portable heuristics that help you create tests quickly.

Take me to Registration and course information

Are you looking for a practical class?

In this class we test real software, under time pressure. You will practice cutting applications down to size with rapid idea generation techniques. You will practice critical reasoning on your feet, by yourself and in small teams.

James Bach originally developed this class from his own experiences at Apple Computer, Microsoft, Borland, and several software testing companies. This is the best of West Coast software testing practice. The methods presented are not hearsay, but represent what we do on a daily basis, on real test projects. The class is taught only by the people who own and author the material, so you are getting first hand knowledge.

Why rapid testing?

Most testing classes try to teach you how to test thoroughly. But their idea of teaching is to recite terminology and the names and descriptions of techniques. They don't build skill, and they don't help you break down and tame a realistically complex testing problem. Besides, almost none of us are given the time and resources to execute a "thorough" test process from beginning to end. Rapid testing is a way to scale thorough testing methods to fit an arbitrarily compressed schedule. Rapid testing doesn't mean "not thorough", it means "as thorough as is reasonable and required, given the constraints on your time." A good rapid tester is a skilled practitioner who can test productively under a wider variety of conditions than conventionally trained (or untrained) testers.

The other reason to study rapid testing is your career. Historically, testers have had trouble gaining the respect of developers and other people on a software project. After all, from the outside, the testing activity doesn't look like much. Most of the value of testing comes from how testers think, but even excellent testers struggle to articulate or justify their ideas about how to test. Rapid testing is a personal discipline, teachable and learnable, that allows you to think and talk about testing with confidence. By contrast, a conventionally trained tester generally is limited to complaining about how the requirements aren't fully documented, or about how some other condition necessary for arbitrarily thorough testing has not been met. That behavior rarely inspires respect.

Rapid testing is indispensable when you are asked to test something on short notice, off the top of your head, early in the development process, or when you're in the process of developing test cases and procedures for future use. This approach is also useful even when you're called upon to test more thoroughly, and given the time and resources to do so.

How does rapid testing work?

Instead of explicit algorithms and instructions, we emphasize skill development and heuristic methods.

A core skill is the ability to think critically. Thus, we discuss and practice the art of being skeptical and of separating observations from inferences. This is a thread that runs throughout the class. We will listen to you report bugs and challenge you to explain the relationship between your conjecture that something is amiss and the observations you made. A good tester thinks like a scientist or a detective.

Rapid test design is an organized process, driven by a set of concise heuristics (think of them as guidelines) designed to assure that you don't forget to test anything important. For new testers, the heuristics provide basic guidance. For experienced testers, the heuristics help you organize and access your experience, so that even under pressure, you perform like an expert and feel like one, too. With practice, you get better and better at testing rapidly while still being fully accountable for your work.

Another element we emphasize is exploratory testing, which is the opposite of pre-scripted testing. There are often good reasons to pre-script tests, but there are also many situations where defining and recording tests in advance of executing the would take far too long and find far too few bugs. In exploratory testing, the tester designs and executes tests at the same time.

Where did the rapid testing ideas come from?

From 1987 to 1995, James Bach worked mostly alone to develop a systematic heuristic-based test methodology that applied to commercial mass-market software projects. Traditional test methodology didn't work well for market-driven test project. Starting in 1995, he began to collaborate with other thinkers and writers in the field, who helped find and fix errors in his work, and helped extend it beyond the scope of market-driven projects. What began, for him, as his own vision of testing merged with other ideas to become a community vision. Some of his colleagues eventually came together to identify themselves as the Context-Driven School of software test methodology. Others helped create the Agile Alliance, which published the Agile Manifesto. Cem Kaner, James Bach, and Brett Pettichord published the first context-driven testing textbook Lessons Learned in Software Testing. James and his colleagues speak and write regularly about testing, doing their best to advance the state of the art.

The ideas in this class are drawn not only from experience, but are also grounded in epistemology, cognitive psychology, decision theory, and other fields. Testing is a far more interesting field than most people realize. We're at the crossroads of many other traditions.

The original motivation for all this was James' personal quest to be a truly expert software tester. It is an ongoing journey, and this class represents the best our community has to show for it, at any given moment. Our goal with the class is to propel each student forward on his or her own quest for expertise and self-confidence.

Who is the ideal student?

The ideal student is anyone who feels driven to be an excellent software tester or software test manager.

The class is useful to all levels of tester, but seems to be most appreciated by experienced testers who want to become expert testers. The class works well when strong-minded and skeptical students attend the class. They challenge the instructor and make the class better, just like testers should. We try to make the class the most stimulating intellectual experience you can handle.

Another ideal student is the tester whose job is to check the work done by offshore outsourcing firms. You don't have time to do a full-blown test project. So, learn how to make a brief test project work.

Here are the slides and notes for the class. These do not include the exercises, though, which are really the heart of the class.

In this course, you will learn:

• Concise, universal heuristics and models for instant test design
• How to tackle any product or product idea instantly
• How to analyze a test heuristic or practice
• How to test despite ambiguous or missing specifications
• How to deal with overwhelming complexity or confusion
• How to know when to stop or suspend the test process
• How to prepare and deliver an impromptu test report

Course Outline

Introduction

• Rapid Testing Defined
• What is Testing? A Questioning Process
• The Themes of Rapid Testing
• How Rapid Testing compares with other kinds of testing

KEY IDEA: Rapid Testing is Personal

• The Test Project Context
• Testing Under Time Pressure
• The Importance of Testing Skill

KEY IDEA: Thinking Scientifically

• Mental Traps
• Questions, Explanations and Predictions
• Confronting Complexity
• Observation vs. Inference
• Models Link Observation and Inference
• Spotting What is Missing
• Using Heuristics

KEY IDEA: Know Your Oracles

• Consistency Heuristics
• Coping With Difficult Oracle Problems
• Quality Criteria and Oracles

KEY IDEA: Know Your Coverage

• Structural Coverage
• Functional Coverage
• Data Coverage
• Platform Coverage
• Operations Coverage
• Time Coverage
• Ask for testability!

KEY IDEA: Use Exploratory Testing

• ET is a Structured Process
• ET is a Cyclic Story-Building Process
• Testing to Learn vs. Testing to Search
• High Learning ET
• Contrasting Scripted and Exploratory Testing
• ET Dynamics
• Focusing and De-focusing Heuristics of ET

KEY IDEA: Know Your Procedures

• Four Elements of Test Procedure
• Focusing and De-focusing Heuristics of Test Procedures
• Exploiting Variation To Find More Bugs

KEY IDEA: Know Your Test Strategy

• One way to make a strategy
• General Test Techniques
• Value (or Risk) as a Simplifying Factor
• Cost as a Simplifying Factor
• Can and should tests be repeated?

KEY IDEA: Rapid Test Documentation

• The First Law of Documentation
• Common Problems with Test Documentation
• Concise Documentation Minimizes Waste
• Consider Automatic Logging
• Taking Notes
• Documenting Test Sessions

KEY IDEA: Rapid Test Reporting

• Reporting Considerations
• The Dashboard Concept

KEY IDEA: Getting started with Rapid Testing

Testing Exercises (distributed throughout the class)

• Test the Mysterious Sphere
• Wason Selection Task
• Test the Famous Triangle
• Test Cases for a Calendar
• Test This Dialog Box
• Find a Particular Bug
• Use Exploratory Modeling on a Small App
• Find an Oracle for Font Size
• Discover the Role of Repetition in Test Strategy
• Report the Completeness of Testing
• Exploratory Testing with Playing Cards

Comments from Students:

"I really enjoyed having the opportunity to attend this seminar at your company in "good old Virginia"! It was very valuable to me and has definitely provided me with new ideas...No doubt, this will be one of the memorable seminars. Big thanks also to onathan and Lenore for their organization and contributions. You guys are a great team!!!"

"Equipment, space, materials... all excellent."

"Content: very clear. The exercises really reinforced the concepts presented."

"I really like James' approach to teaching. I think learning is most effective when students are challenged to re-think assumptions. He openly invited comments, questions, challenges, which makes learning engaging and fun. I really like the way James handled students' comments and questions. Very impressive instructional skill."

"Excellent class. Being a new tester of only 3 months, I learned many ideas and techniques to improve my critical thinking and areas to explore."

"Class was structured well, good material, slick technology, fun diversions (video clips)."

"Now, will I be able to put the concepts to good use? I believe so, although it will require practice. After 15 years of highly structured development and testing, not to mention a lifetime of linear thinking, such "anarchy" makes me uncomfortable, and it will take me some time to get good at this style of testing. Thanks for presenting it as an alternative, and teaching us how to decide when to take advantage of it (instead of a more biased view)."

"I had taken James' Exploratory Testing class already, so this was somewhat of a review for me. However, the review impact was more effective this time around because I had more experience. The new material really solidified the basic principles for me. The facilities are excellent."

Excellent material on best testing practices-well seasoned from tried and true practices. This material is useful to develop individual test skills and would be effective to deliver to whole teams together. I am not exactly sure how I will successfully disseminate the wealth of information back to the organization when I return, but I will try my best. Very worthwhile -- an understatement. Thank you for challenging us and being generous with your experience and knowledge."

"You guys rock!! This class was a great experience! Loved the variety and guided hands-on exercises."

"A. Ideas I will consider with my team/company will be:

• Defining beforehand what our 'good enough' testing is
• Exploratory testing -- especially the note-taking portion
• Pairing of testers for complex work (at least a more conscious application of it to get the most)
• Claims testing and random testing
• Test planning
• Dashboard

B. Good, stimulating, challenging presentation

C. Great venue

D. Learned a lot from James (and Jonathan)

E. It was fun too!"

"1. Great course, packed with useful tools, tips, approaches.

2. Good class space, hands on very good.

3. Wish we could have seen all the material discussed, but all said/did was useful.

4. Overall, best testing training I've had. Thanks!"

Registration and course information

Befinner mig just nu på Öredev i Malmö. Det kan nog mest beskrivas som en utvecklarkonferens med ett testspår. De svarta kostymer som brukar synas på EuroSTAR lyser med sin frånvaro. Jag kostaterar att det inte är speciellt mycket tjejer här.

Guldkornen från idag: James Bach höll en keynote kallad The Renaissance thinker. Det handlar om att i renässansen var det männsikor som vill gå vidare från det gamla sättet att tänka med religion, filosofi och vetenskap som trodde att de redan visste svaret på allt som var värt att veta. Om vi gjorde annorlunda skulle världen riskera att raseras. James vill att vi testare och andra inom mjukvaruutveckling ska se framåt. Han tar Agile och Exploratory testning som exempel på att vi kan gå framåt. vattenfall, V-modell och ISTQB är hinder för att vi ska kunna utvecklas. Vid middagen på Mosaik ikväll berätade han att hans största frustration är att de som tänker olika i testfrågor - som Paul Gerrard och Stuart Reid - tror att han inte menar allvar utan bara vill provocera. Inget kunde vara längre från sanningen. Det är faktiskt lite tragiskt att de som jobbar så hårt för test i Storbrittanien, Holland och Tyskland strävar så hårt efter att hålla kvar oss testare i det gamla tankesättet med ISTQB och TMAP. James är som alltis inspirerande att lyssna på, om man är villig att öppna sinnet vill säga.

En annan intressant talare var Nicalai Tillman från microsoft. Han demonstrerarde PEX - ett verktyg för automatiserade programtester för .NET. Det finns idag en akademisk version att ladda ner för Visual Studio 2008 men ingen kommersiell. I VS 2010 kommer det enligt planen att finnas med som en del. Finessen är att du skriver koden och verktyget känner sedan av vilka villkor som finns och skapar testfall för att täcka in alla villkor plus att du får se en lista med indata och resultat. Du kan spara testsviter till senare ändringar. Jag hoppas det blir ett naturligt sätt att utveckla inom några år - så enkelt att det inte går att motivera att INTE använda det!

Sista presentationen var Pradeep Soundarajan från Satisfice Indien. Med en amerikansk accent och en stor portion huor berättade han om testandets vedermödor i Indiska projekt. Problemet är att allt är skriptat ner i minsta detalj, alla är ISO-certifierade och har en massa omständiga men ineffektiva procedurer. Han avslöjade också att de företag han jobbat på fejkade extra dokumentation inför sina audits så att de får behålla "kvalitetsstämpeln". Intressant att höra att det är en BLUFF!

Fredag

James Bach med fem koppar kaffe i kroppen gjorde en stark insats då han beskrev hur vi kan göra Exploratory Testing med mer kontroll.

Karen N, Johnson gjorde en lite blek insats om et spännande ämnen storytelling. Innehållet var intressant men energin ganska låg.

Beneath the surface med Daniel Makoski från Microsoft berättade om nästa generationens gränssnitt MUI - Natural Usier Inerface. Proffsigt framfört och intressanta idéer - amerikanarna är duktiga på att snacka.

Slutdebatten med agilisterna och James Bach var underhållande. Alla inblandade var överens om att samarbete istället för att kriga. Ta det bästa och jobba mot professionalism. Det viktigaste vi kan göra för samhället är att göra ett så bra jobb som möjligt.

Min egen insats då? En hel del grönt, lite gult men inget rött. Lute svårt att få igång publiken sent på fredag eftermiddag. Vi har diskuterat igenom insatsen nu ikväll och Patrik S har gett sin feedback. Nästa gång blir det ännu bättre!

Over and Out från Malmö i snöstorm.

På måndag Rapid Software Testing i Göteborg. 

Vi som läser hans blogg regelbundet har sedan ett par veckor tillbaka sett att James på grund av personliga skäl väljer att inte resa mer i år. Hade sett fram mot att lyssna på hans inledande keynote mot certifiering och att engagera mig i diskussioner med vår guru. Har inte sett någon information om detta på EuroSTAR-sidan förutom att de diskret tagit bort hans tutorial. Det ska bli spännande att lyssna på Michael Bolton leverera samma salva då han och James jobbar mycket ihop. Modigt och roligt ändå av Stuart Reid - vår certifierings och standards guru att bjuda in en person med så starka ståndpunkter mot det han själv arbetar med nämligen ISTQB och IEEE. Har själv insett att IEEE inte vill att vi vanliga människor ska kunna komma åt deras alster utan att betala en rejäl slant. En sann standard borde ju vara öppen för alla att komma åt. Dessutom måste man köpa loss deras artiklar för att få läsa dem till hutlösa priser. Tittade på vad det skulle kosta att ladda hem lite olika forskningsartiklar från våra svenska testdoktorer - det var nästan lka dyrt att ladda hem en enda artikel som att köpa en bok! Ja inte riktigt men det lät bra att säga det. 19 dollar för en artikel är ju rena rama rånet! Mycket tråkigt eftersom det är här de flesta stora forskare publicerar sina alster. Snacka om att hindra informationsspridningen!