Gå till innehåll

2

Update: This is what James has to say about his class

I am a self-educating tester. For the ambitious thinker, self-education is a way of life. For the ambitious tester in particular, it is indispensible. If you think about it, testing itself is a learning process (and also a process of unlearning what is not so). In this tutorial, I will tell you how I do it. My self-education system has been, for me, a substitute for institutional education and a competitive advantage. Although I left school at an early age, if you already have a higher education, so much the better! You get the best of both worlds.

I will explain and demonstrate the methods that I use develop ideas for my articles, books, and classes, so that you can use them draw out and codify lessons from your own experience.

I will discuss:

- The fundamentals of adult self-education
- Entry points for testing education
- A personal syllabus of software testing
- How to identify, articulate, and test your own heuristics
- How to assess your own progress

Tobbes Comments

James Bach is the person that has taught me the most useful stuff about software testing.  The first time I met James in person was at the Rapid Software Testing Class in Sweden about six years ago. I had earlier read articles and talked to colleagus about issues that sparked my interest. For three days he questioned many of our beliefs about testing in specific and reasoning in general. I started to think about why I had the knowledge I had and if there was any good reason for having it. I had a lot of problems applying a lot of common testing methodology but still tried since so many authorities stated that "this was the way to do it". I suddenly realised that not all testing experts had the same thoghts about what effective and effecient testing was.

JMBach-166x220A very important part of the class was James methods for learning. Experiental training inspired by Jerry Weinberg made the experience fun and easy to remember. He also talked very much about how we know what we know - also known as epistemology . He talked of areas I had never heard of before like Abductive Inference and told us to actively search for knowledge. James told us about his way of learning and I thought, Wow - it sounds like a treat!

From that day I started to buy lots of books and my self-studies increased in intensity. Together with that I started reading blogs and joined the context-driven testers discussion group. For me, reading interesting things is an enjoyable experience. Learning new things in the areas of Logic, Lateral thinking, Philosophy, Psychology and many more areas has benifited greatly to what I know today and I strongly believe that the success of any tester, or any other career for that matter, lays for the greater part in the hand of the person itself.

And now he has finally written a book about his self-study method.  ”Secrets of a Buccaneer Scholar”  has references to the Buccaneers that pirated the South Americas in the 1600s and he compares their way of organising with his own search for information. He also has a dedicated website on the subject.

For the first time ever in Sweden he gives a Tutorial on Self-Education for testers. Anyone interested in educating themselves and thus becoming a more valuable resource should seriously consider this opportunity. If you have already taken the RST class and want to have som more inspiration - this is your chance to continue!

The tutorial takes plave 25th of march 2010 at SAS Radisson in Gothenburg. Take me to more practical information and registration detailsbuccaneer

1

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

The Sticky Minds website is now featuring a review of my book Essential Software Test Design The reviewer finds the content great but the many proofing mistakes bothering. Funny thing since I paid a fortune to an English speaking translator who then proceeded to make both spelling and grammar mistakes. The whole book project is a tale of how to NOT publish a book. No direct communication with whoever did the work, everything went through the publisher. In the end, she just vanished and after receiving my last payments she failed to pay the guys she hired to do the job. Luckily the version on Amazon is a print-on-demand version that has many - but not all spelling mistakes corrected. If I ever write a book again I will be sure to have a professional editor handling it.

There are not that many good books on test design out there, most testing litterature is about process and documentation. I use Lessons Learned in SW Testing (Kaner, Bach, Pettichord) as a way to get inspiration and new ideas, How to Break Software (Whittaker) has helped me a lot understanding the root causes of failures and I use the techniques daily. Test design for the practitioner(Copeland) inspired me to add some content to the final version of my book - I read it the first time when I was almost done with the first draft of the original Swedish version of my book and I thought - wow here is almost the same book I am writing! My recommendation to the professional test designer is - read all of these as well!

The art of giving and receiving feedback. Another brilliant book by Gerald Weinberg.

As with all of the Weinberg books I have read so far the book is both fun and interesting. It discusses many myths regarding feedback and opens the eyes of the reader. It talks about both giving and receiving feedback which are closely connected. The main lessons learned for me is

- Timing: Give feedback when a situation arises, not a week or a year after.

- Shutting up: Do I really NEED to give feedback right now is this situation? Do I think the person will appreciate it or even listen? Or do I just believe that I have such important information that it is worth risking a relationsship telling it?

- Walking in their shoes: What if I was in their situation, how would I have acted? Maybe my understanding of a situation is totally wrong? Think about the reciever before opening your mouth!

- There is a big difference between observation and interpretation. Feedback can contain both parts but observation is often more useful and appreciated.

- Be specific and clear: if you wrap it up, it will likely be misunderstood.

- We can all get better by practicing! And that is very important for our personal and professional life

In my current It-project I realise that half of my work is about communicating with other people and feeback is a central part of that.

Read it!

The book can be bought new from Bingham House Books <binghamhousebooks@comcast.net>

1

I had the pleasure to invite Ingrid Domingues for dinner this week. Ingrid is one of the authors of the book Effect Managing IT that I have read at least three times so far. There has been a lot of discussion in, at least the context driven testing community, on how to increase the value of testing.

An IT-system is built to solve a problem - if the problem is not solved the product does not work!

So we need to focus on the users/customers to ensure that they get good usage of what we build. Effect manging IT puts the focus on what effects we want to achieve and what roles of users that can achieve them. This serves as a basis for requirement and testing where we try to make sure that the most important effects are realised. We then have a pretty clear idea of what the consequences are if we remove a certain function or if we find a problem in a part of our system. Ingrid told me she is a bit tired of waiting for the business to understand the concepts off effect managing and start working with them. Instead they choose to work towards unclear goals with the result of not optimizing their earnings. Well, I have said the same thing about testing for fifteen years, how come the understanding is so slow to penetrate our industry. ISTQB certification is part of the answer. It is hard to change to the better when the old ruts are sold as the one and only solution. Most testers that I respect believe it is useless or plain wrong but a lot of managers and some novice testers think it is important. That often changes when they take a testing class like RST or my own test design class where they are shown alternatives and are encouraged to think for themselves instead of beeing dictated to. I will leave that discusson for now.

Testers should be business analysts, many have said. But how come the important part of business analysis is just thrown at the testers? Shouldn´t the whole project be customer focused? As it is now, not even the customers themselves seem to be business driven! Looking back at most of the projects I have worked on the last 15 years, the greater part of them are function driven or maybe "project driven".  What I mean with that? Well, how come all project management and system development methods focus on getting a bunch of functions completed within in a certain time limit and within budget? There is little engagement from the customer side, lately it seems to have become even less rather than more. The roles system analyst, business analyst or whatever they may be called never seem to have anyone assigned. And what about the roles interaction designer and usability architect. They are surely legends because I have heard about them but never seen them in any project so far.

The truth about IT-projects is that the only ones making money on them are whoever is developing them. Whoever pays the bill hopefully earns some money AFTER the project is put in production. So their goal, and the project's, should be to maximize the earnings after the project has ended. If that would be the focus we would not only look at effects but at all the important quality factors that are alomost always conveniently forgotten by everyone engaged in builing a system. What are the support costs? How can we update, upscale, change platform? Are the users happy, if so the usage of the system will increase hence we make more money.

It is time to stop running IT-projects and start to run business projects! All other industry does it or they go bancrupt.