And he did. I met James Bach, a teacher, consultant and guru in the software testing field this week.
Here is how it happened. I am a recent involuntary Agile convert after 5-6 years of a solid waterfall testing career. In the course of the last Sprint, while continuously running exploratory tests to no end, I realized that crucial changes need to be made to my testing approaches or I would go crazy. I felt that I could not keep up with the pace of the project cycle. I tried to follow the old patterns of designing elaborate test cases based on high level user stories specs, but I was unable to as the requirements kept changing. My test cases kept getting obsolete, updating the cases slowed down my testing, and I was losing track of time and direction. Plus the whole team was under a lot of pressure. We needed to deliver a product every 3 weeks and we were at the end of the release. I felt anxious and frustrated. I blamed it on the Agile Scrum that I was forced to embrace a few months ago and on the overwhelming number of epic user stories that frequently made no sense. All of this helped move me out of my introverted comfort zone – I now had to talk to developers daily and IN PERSON.
I blamed myself most of all for not being to cope with all this better. I looked through my testing textbooks, I Googled for information on rapid and Agile testing and I read other people’s testing blogs and forums. Soon the realization hit me that what I am going through – growing pains – is not an uncommon phenomenon. Many colleagues of mine also started their quests for answers on how to better themselves and there is a growing ‘army’ of non-conformist testing professionals that consider agile, rapid testing and context-driven testing as a golden opportunity to learn, test effectively and make clients happy.
Somehow I landed on James Bach’s blog site – http://www.satisfice.com/blog/. It felt as if someone directed me right to the site. I noticed that he would be in Virginia within a week to teach his seminars on Rapid Software Testing. Wow! The timing could not have been better for me.
The following note on his blog prompted me to try and meet him:
“I’ll be traveling and training this fall. Take note of where I’ll be, because if I come near where you are and want some relatively free consulting, all you have to do is take me to dinner. I’ll do almost anything for free food.”
How cool is that! Is he really that approachable I thought? He is busy and famous and I am sure has lots of engagements on his calendar. What the heck – let me contact him and see what happens.
I contacted James via Linkedin.com to save time on self-introduction. I figured that he would be able to view my profile and see for himself that I am a fellow tester. To my amazement I received a reply within a few hours. I contacted his wife and business partner and set up dinner at local restaurant, Euro Bistro. It was so smooth and easy and felt too good to be real. I was so excited and nervous. I had so many questions for him.
Tuesday finally came. After work I headed to Euro Bistro a little early. Oktoberfest had just begun over the weekend and they played fun German drinking songs which put me at ease. I also invited my work friend and manager to dinner. My friend and I have been through a lot together learning about Scrum, overcoming growing pains and coming to agreement that testing is important. I thought he could also benefit from talking and listening to James. Little did I know that his presence would make me feel very uncomfortable when James challenged me with his puzzles and quizzes during dinner.
My husband picked up James at the hotel and brought him to the restaurant. I watched Google talk videos with James so I recognized him right way. He was casual with his Buccaneer-Scholar baseball cap which made him even more approachable. He had a broad, friendly smile and a strong handshake. Somehow it felt like I already knew him from some place.
We ordered food and kept talking about testing and other issues. He told us about his upcoming international travel plans, past experience and about his training and business. He told us about Context-Driven testing approaches, which was exactly what I was looking for in my quest. I was really psyched. But then he decided to challenge me with a few questions on my testing techniques and a couple of puzzles. I freaked out. After all I was having dinner with James (and I really wanted him to become my mentor!), my manager and my husband. OK, I was not worried about my husband as he has seen me in worse situations when I was put on the spot and tested for courage. However, I was worried that I might do something stupid in front of my manager. That would be great I thought.
I struggled with my answers on how I go about testing as I mostly rely on my test Yoda – intuition and idea formation from reviewing specs, attending meetings and talking to developers. I am a self-taught tester with no real formal training. I have read a couple of books (Testing Computer Software, 2nd Edition by Cem Kaner and Testing Applications on the Web by Hung Q. Nguyen and other authors). I picked up most of my skills on the job by watching other people and trying different things. I always liked puzzles and figuring things out, whether it was a mystery novel by Agatha Christie or a word or jigsaw puzzles. I have fun playing on and testing various web sites such as Amazon.com and Ebay.com and figuring out and breaking home appliances. I did not anticipate being tested out in the open. My heart sank.
James presented me with what he described as a simple problem – a flow chart that looked like this. He asked how many tests should cover it. In my mind I broke the model into a few sections and came up with roughly over 10 tests. Here are my thoughts and ideas –
- input field (GUI validation – look and feel (IE/Firefox if web app),
- field and data validation, length and boundary test – leaving the field blank, entering spaces, numbers – 3, 4, -3, .0003, large number, letters, Roman numerals, foreign/illegal characters, copy and paste values from a document
- error handling – will it actually be stopped, what kind of errors will be displayed, will some input data cause the application to crash?
- Pass: then what happens? And what about that Print Job? Are we printing to Color, Laser or Inkjet printer? Will it be in text, MS Office or PDF format? What else do we need to know about system and printer configurations?
As I started mumbling my answers James kept repeating that the problem was simple and that all the user had to do is to enter a value greater than 3 and the program would pass. I was petrified. He sounded like some of the developers I currently work with. I could not understand why he was arguing with me. He is a tester - shouldn’t he be on my side? Was I really wrong? I have been told before that I worry too much, over analyze and complicate things. Déjà vu I thought. To make matters worse my manager-friend was sitting next to me and watching this spectacle. The Print Job part bothered me the most as it was a real black box and a bugger to test but it seemed like James did not hear me. UGH!
He then asked my manager-friend and my husband for their answers. They suggested executing a couple of straightforward data validation tests. James acted as if he was agreeing with them. I felt bewildered. Then he smiled and announced that the guys fell for his trap. PHEW! So I was not paranoid after all. Can you imagine what I went through in the last few minutes?? My test Yoda was right though. He kept telling me not to budge and I am glad I did not give in. I got 8 out of 10. Not too shabby for a humble Siberian tester!
He asked me a few more questions and made his recommendations on what I need to work on - mainly to think how I think about testing, to utilize a Heuristic Testing approach which is ‘an approach to test design that employs heuristics to enable rapid development of test cases’ (see http://www.satisfice.com/glossary.shtml). He offered to be my mentor! Wow! I was thrilled. It is true - When the student is ready, the teacher will appear.
A quote from James Bach about this:
"It's tempting for people who read schematics to say that there is only two pathways through this program, and therefore only two or three tests at most to test it. The trap is that the boxes might hide considerable complexity. A good tester must not be fooled by the apparent simplicity of a specification or design model. I liked how Lena looked at this simple thing and saw through it to the possibility of murky complexity. In doing so she demonstrated the 'second sight' of a good tester."