Testing In Principle: Relaxation

At the time I first took a class with James Bach on Rapid Software Testing (RST), I had been studying t’ai chi chuan for about 7 years. Throughout the class I kept hearing James say the same things my instructors told me: relax, be open to the energy of what’s around, listen and adapt, and keep your balance. Of course, he didn’t use those exact words. What he said was, “To do Rapid Testing, you don’t need permission. It is completely within your own control.” Keep your balance. “Rapid Testing is like team sports: quickly establishing the proper relationships with your team, handling the ball properly when it comes to you, passing it off to the right person at the right time, staying aware of the time and the score, and furthering the goals of the team.” Adapt to your situation. “Give up responsibility for impossible testing tasks like ‘complete coverage’ and ‘zero defects’, and instead do your best with what you have and be prepared to explain the choices you make.” Relax. “Do everything you can to improve your skill as a testing problem-solver and teller of the quality story.” Practice, practice, practice. T’ai chi will aid everything else you do.

Key principles taught in t’ai chi class are Relaxation, Straightness, Separation of Yin and Yang, Empty Steps, and Focus in the Tan T’ien. I’d like to share how I apply these to Rapid Software Testing.

Imagining Strength, the Relaxed Way

My first t’ai chi teacher, Dan Ogrydziak, made a point about strength. He said that strength is not just in how much we can do, but in how easily we can do it. Imagine, he said, a cartoonish strongman and a pencil-necked geek each lifting a 10 lb barbell. They each could do so, probably, but the stronger one will be much more relaxed about it. Now imagine the weaker man practicing lifting that barbell with as much relaxation as possible, with the goal to be as relaxed as the other man – what would his body look like when he was done? What would lifting that barbell feel like? What else could he lift, or do, more easily? T’ai chi is a path to explore the benefits of this re-definition of strength, strength through softness rather than through the usual method of over-work and damage and rebuilding the muscle tissue, which leads to hard, stiff, bulging muscles.

I had to make a similar transition between the goals I wanted to achieve when I began practicing rapid testing. I’d been told that I was “in charge of quality” and that “we should have bug-free software”, so I was pretty stressed: bugs were my responsibility, since I was in charge of quality, but I didn’t have any power over the bug-insertion process. I looked at the software and decided the UI was too complicated, so I tried to get the design team to change how it did its business, and promptly created significant ill-will with that team. I did not understand the central engine of the software, and did not want to appear dumb by asking too many questions, so I remained ignorant and covered my tail by finding low-hanging bugs. At the same time the code was being developed and morphed at a dizzying rate by a young, talented design team. I was in over my head, and tried to control the chaos by doing what I had been told: Requirements – Test Matrices (“Where are the requirements docs? How can I work like this?”), being the Gatekeeper (“We don’t release it until I say it’s fully tested!”), trying to nail down a Dev Process (“Which bug was this fix for? No bug, no fix!”). This is like being the weak guy, and coveting the way the strong guy looks, with his big bulging, inefficient muscles and his injury-prone joints.

The RST class gave me a new frame of reference for my success: actual value to the team, instead of control of the product. I began by throwing away the process documents and matrices, and asking the people who were in charge what they wanted from me right now. I kept lists of concerns raised by people who mattered, and followed up on them as well as I could. I swallowed my pride and got training in the innermost workings of the system, and ultimately decided that it was not worth my time to test it explicitly, since the developers were using TDD and xUnit – but at least I had done so rationally and with a clear conscience. And I involved the whole team in testing their product with several after-hours bug hunts where the Design team and I assigned user personae to the team and we all acted out scenarios – this built bridges back to the Design team, and also gave the developers a taste of testing, immediately improving my credibility when I asked them for testability suggestions and improvements. In other words, I gave up trying to control everything, and redefined my job into something that I could do where I was with what I had.

I resumed sleeping at night, another fabulous side benefit of practicing relaxation.

Letting Go of Preconceptions

When we relax under our current burdens, we become usefully strong in all the ways that can help us do what we are doing right now. The most important thing that relaxation does for us is to open the pathways of chi energy in our bodies. The feeling is immediate and clear: better blood flow, more energy, better coordination, more sureness and precision in movement. The same physical letting go I do when I relax can have immediate mental and emotional effects too: a clearer sense of the din, the energy right around me, less anxiety, a more appraising eye, more self-confidence and humility. This in turn leads to considered action which is more likely correct or correctable.

In the RST course, James spoke about this by saying, “Testing is applied epistemology.” If we want to know how a thing works, we have to open our eyes and ears and gather evidence, and open our analogic mind to create testable hypotheses which interpret that evidence. Then to test the hypothesis we need to separate what we want to keep stable from what we want to vary, and introduce those variations in a controlled, observable way. The enemy of this process is preconception. Tension, whether mental, emotional, or physical, is the result of anticipating something happening to us like something that happened in the past, and being on hair trigger alert to respond in the pre-planned fashion that our tension facilitates. We become predisposed to interpreting any stimuli as being whatever we are anticipating, whether it really is or not, and once we do that, we trip the trigger of whatever response we have already decided on and have prepared to do. Obviously, this is terrible testing practice. How many entire problem spaces have I ignored because I was not open to seeing any problems there?

James also addressed the idea of using the benefits of relaxation when he spoke about testing in a “flow state”, usually during exploratory testing. When we have granted ourselves the freedom to act as we see fit and to follow up on any leads we see, even within the bounds of a charter, we have chosen to test with our minds open. We can use our enhanced awareness of the energy of the team, of the project, and of the software itself to guide our tests to focus on the greatest risks or the most pressing needs. This is important when we are going to report our testing status and need to be accountable for our decision-making. It was easy when I had my matrix to be able to say, “I had to cover squares B5-C12 today. It isn’t my fault no one cares about the contents.” Now I need to be able to tell my team that I spent the week trying to calm down this particular customer, even at the expense of following up on that bug fix that the developer wanted feedback on. I find that I am in much closer touch with my leaders when I use this approach, because I have to make sure that they buy into my read of the situation. I find I’m usually right, and when I’m not, I am able to change course and accept the new direction with equanimity because my criterion for success is value to the team, not control of the product.

Avoiding Injury

Another important benefit of relaxation is that you avoid injury from failing at something that is too much for you. Tendon and ligament damage only happen when you cannot lift something with some relaxation. By working to do everything with relaxation, we start to notice when we can’t be relaxed, and perhaps ask ourselves what the problem is: too heavy a burden? Too hard an assignment? Too contrary a lover? Too high an expectation? Then we can work to shed the excess and recover our marginal capacity, and our relaxation, and our productivity, and our health.

The analog in the RST course is the Status Report game. “On a scale of 1 to 100”, asks your boss’s boss, “how done is testing?” The sort of answer James was looking for is, “0 to 100 what? I have a better idea, let me tell you about our product and our testing.” The usual answer, of course, was something like “85 – We’ve done most of our testing, there’s still a bunch to go, and 80 sounded too small.” People fall into the trap of playing up to the expectations that they believe others put on them, and then they paint themselves into a corner. Much better is to tell the story of quality, plainly and openly.

In terms of project work, the analog is to say, “I don’t know how to do that (ensure zero defects / program in PHP / make sure we are CMM-Level-2-compliant)” or “You might want to find someone else who can help you with that (gin up numbers for a sales brochure / close out defects to hit a quota / give the thumbs-up for a release)”. Otherwise I just take on stressful jobs that I can’t do.

Better Listening and Responding

One interactive t’ai chi activity we practice is called push hands or listening hands. We stand a few inches apart and place our hands lightly on one another’s arms. Then we relax and listen to each other’s bodies as we move our weight back and forth, with the goal to unbalance your partner while remaining balanced, and to use as little force as possible. It is a lot like trying to hack a system and keep from being hacked, and relaxation is your firewall and also your penetration strategy. With more relaxation you can hear your partner’s body, its limitations and its intentions, sometimes even before it physically moves. At the same time your body loses its tendencies and predictability, gains flexibility in the joints, and is able to sink lower and lower to be more stable, so you are harder to unbalance.

James and Michael Bolton have come up with a vast array of lists of options that are available to a tester: test techniques, analytical methods, planning methods, logistical issues, reporting techniques, and on and on, coalescing the hard experience of decades of testing and thinking into a diamond-dense pith of instantly-accessible heuristics to apply. Much of the RST course is built on these lists, and the goal is to open the student’s eyes to the incredible array of possibilities at their disposal without making it seem like to landscape is so limitless that they freak out. For some reason, my mind does not do well trying to memorize these lists (even though I can remember thousands of lines of song lyrics – strange). But I’ve developed a working familiarity with them, so that I understand when I’m in a situation where one might come in handy.


The most satisfying testing, though, comes when my interaction with the software takes on the characteristics of push hands, and I am working on its balance with variations of data and timing and environment, and it is challenging me with nuances of responses that require deep analysis to be sure what they are saying. Was that “success” message really valid, or was it given to me erroneously? Did it round down properly, or just truncate the response? One false assumption, and I miss a lead, and down I go on my butt when a customer calls with a a bug report. Or, when I write the exact right oracle utility (using perl, of course) for a new feature, and find the hidden showstopper – boom, down the app goes on its butt.

RST = Relaxed Software Testing

A Rapid Tester relaxes and remains useful while situations change around her. She has good work capacity and precision, dampens stress and anxiety, and inspires confidence. She appraises the energy around her and is able to respond appropriately: this rumor is a new risk item, this nagging flicker might be a bug, this email is a charter, this design tidbit is a model update. The Rapid Tester sheds what she cannot lift: she knows when to ask for guidance or state that she does not know how to accomplish an objective. She does her best and reports plainly on her progress. She knows her tendencies, her strengths and weaknesses, and exploits them and those of others in service to her mission. She can pinpoint the source and nature of the issues she encounters, and can imagine options to choose from in how to solve them.

Does this sound like you?