Paperwork Implies Something... it does not Do Something

Okay, so now I had a certificate up on my wall... Did that make me a good tester?

Have you ever met someone who went to school to become, let's say, a teacher? If this person has all the paperwork to prove they can be a teacher, does this mean they are a teacher? Anyone who has spent any time in school has met someone who should not be at the head of the classroom. At the same time, surely most have met someone who had no paperwork, no college education whatsoever, and has taught them a lot. Paperwork implies something, it does not do something.... and when tested under fire, it is useless.

Not long after becoming certified, I was exposed to two of the best training courses available for software testers...

In our weekly team meeting, it was announced that the organization I work for was going to be providing us with a 3 day Rapid Software Testing course with Michael Bolton. I was excited to have an opportunity to learn more about testing.

This course helped me to take ownership of my testing. The use of heuristics and oracles was something I had never taken into consideration. It is not that I had not used them - everyone uses them to some degree , but I didn't know how to use them smartly.

The course also gave me confidence in testing. Not only did I believe that I could test any application/product set before me, but I went on to do so with success, on each of the projects within the facility I work for. In short, the tools provided by this course have enabled me to organize my mind in my testing.

I knew some time after this course that I needed to test myself. I knew I was good at what I was doing, but I was unsure if what I was doing was good. At this point I signed up for the Association for Software Testing's BBST Foundations course. This course was great. There were all levels of testers in the same "class". The points of view brought in were amazing and the main project allowed me to gain some experience in working on a geographically dispersed team. This ended up helping me quite a bit when I was actually involved in a four-location project.

This was an intense, fast-moving course that provided me with an opportunity to learn from not only the course materials, but other testers from all over the world. It not only added to my testing knowledge, but to my communication skills as well.

I would highly recommend both of these courses to all testers regardless of time and experience they have in the field.

Taking the Test... Twice

The test that was specially created for those of us who were applying for the permanent QA position included multiple choice, essay, and lateral thinking questions. The multiple choice and essay questions were taken from the ISTQB syllabus.

I have never had much difficulty in taking tests that involve memorization. I have been able to simply read through the study materials a few times, take a test, and pass. This information is generally only placed in a temp file in my brain. It does not actually commit to memory unless I need or want to keep the information. So I began to read through the materials each day until the day of the test.

I passed the test and was offered the job. I accepted with a literal shout of joy!

There had been talk about certification in some of the QA meetings that I had been in prior to taking this test. Because the test was based on the ISTQB syllabus, and because the ASTQB was going to be in Boston in a few weeks (about 400 miles from where I live), I decided to take a trip and take the certification test.

As luck/fate would have it, my brother in law was a pilot for an airline that flew out of the local airport and he was able to get me a ticket that only cost me a little - round trip. And my baby brother, Josh, lives in the Boston area. Being a single income family, it took a bit of sacrifice from all of us to scrape together the necessary costs associated with taking the certification test, but we did it.

Long story short... I took and passed the test. I was proud of myself for making the trip and for challenging myself to go a step further than I had to. I put no stock in the certification even at that time because to me it was just memorization of terminology. However, the challenges to get there, and the impact it had at my job, was well worth it.

A couple of months from the date I took the test in Boston, I would be exposed to something that would empower me to embrace the way I think, sharpen my understanding, and give me a great set of tools that can be used both inside and outside testing...

Exposure to Outside Influences...

My first exposure to information on software testing from outside the office came in the form of a couple of the web site links the QA Manager shared with us temps.

The first was the Center for Software Testing Education & Research. The second was StickyMinds.com. Both of these web sites were, and continue to be, great resources for learning.

The first book that I borrowed from the QA Library was Testing Computer Software (Kaner, Falk, and Nguyen). I read the book cover to cover and now own a copy of it myself and use it for research and as a resource in my testing activities.

So much of what I was reading, learning, and doing caused me to come to the realization that this was the job for me. Certain personality traits that I had been told, from significant people in my life, were negative, turned out perfectly posititive for testing. I felt at home with this job.

The trouble with feeling this way about my job was that it was only a temporary position. There was a scheduled end-time and the QA Manager made sure we all knew that. One by one I watched the other temps leave. Whether it was finding another full-time, permanent job or because they did not like testing, only two of us remained to the end of the temp time.

A couple of days before I was supposed to get done, the Manager came into my office and told me that my time had been extended by a couple of weeks. I was quite happy with that. I had decided not to panic at the end and start looking for another job in the area. I had decided to continue to learn and keep the worries at bay while I did so. I had made a decision that, even if I were only hired on as a temp, I was going to continue to do my job as if it were permanent. I had decided that this was a career I wanted to pursue. I had been bitten by the software testing "bug".

It was not long after this that I was told a permanent position was going to be made available. There were other candidates within the organization who would be applying for the job as well. We would have to take a test as part of the application process...

Ahhhh.... the Questions....

My previous blog entry ends where I begin to ask questions about what I am doing, what the product/application is doing, and everything in between :)

The senior members of the QA team that I was hired on as a temp to help, were very helpful and patient in answering or finding answers to any and all questions that I asked.

Not long into running test cases, I began to submit bug reports. Being a "newbie" to the whole software testing field, these reports were generally missing something. Fortunately the development staff where I was hired was again, like the QA department, very patient and helpful. If they thought there really might be a bug, they would come over to the temp office and work with me to find the information that was lacking in the bug report. They would also give me further information about the product/application and the whole "system" in order to provide me with more information to use in testing and submitting bug reports.

A lot of the required reading materials spoke about the friction between development and testing. I did not understand this while I was reading. Wasn't the goal supposed to be to get a product/application/system out to the customer in the best shape it could be in? Wouldn't we all be working for that same goal?

Turns out I was lucky to be hired on to an organization that really believed that. If there was any friction between QA and Development, I did not see it.

It was at this point that I wanted to learn more....

In the Beginning...

My life had dramatically changed and I needed to find a new job. I filled out an online application for a temporary QA position in the city next to the town I lived in. I had no idea what Quality Assurance was, but I had some of the qualifications they were looking for. To my surprise, I was called to be scheduled for an interview.

In the reception area, I was greeted by the QA Manager. He was dressed in jeans, Hawaiian shirt, and sandals - this weirded me out, but was a bit humorous as well. I followed him down a long hallway to his office, where he proceeded to sit down and put his feet up on the desk filing cabinet.

The interview was unlike any I had ever had. It seemed to have nothing to do with work at all. When the interview was complete, he had to ask me if I wanted to know what the job was. I had enjoyed the interview process and the odd questioning so much, it never occurred to me to ask :) The one thing that stuck out above all else was that the man was all about his team. He was as proud of them as a father is of his children. This made me want the job more than anything. Like an awkward teenager wanting to not be picked last for a sports team in gym, is how I felt when I left.

I got a call a couple of days later. My children were in the room with me when I received the phone call. They waited with patience as I spoke with the QA Manager on the phone. When I got off the phone, I let out a rigorous "Yes!" and slid on my knees across the linoleum on the kitchen floor. (All the children left the room, not sure why.) I was picked for the team... of what, I did not know, but I was picked. (Thanks Bob!)

The first three days at the job, me and the other temps hired on, spent reading software testing materials. I have always loved to read, so this was no big deal to me. What was a big deal to me is that I thought... "this job surely requires a college degree". In spite of the fact that I did not instantly understand the information, I decided to continue to read anyway and hope that this, as most of things I learned in my life, would be comprehensible when put into action.

After the reading days, we were set to task running scripted test cases for a product. The information that I had been reading was still floating like fractals above my head, but the test cases that we ran were written understandably enough for me to understand what I was doing in the program/application that I was exposed to. (Notice I did not say that I was testing it.) Here is where I began to ask questions...

Tester Types...

Rob Lambert has done a great job of asking What tester are you? on his blog. What makes me think this is great, you ask? Or maybe you don't....

I am a firm believer in personal growth and personal accountability/responsibility. These blog posts are a great way to take personal inventory of a few things:

1. Who am I as a tester?
2. Can I quantify what I do?
3. Do I behave in a civil manner?
4. What can I do better?

I personally sent these "tester types" to the members of my organizations test team. Knowing human nature is to "type" other testers, each time I was approached with "so and so fits this type" I said, "this is for you to find your type.

While these "tester types" may not be scientifically proven, or even viable in all cases, we should all take some time to think about who we are as a tester, a team member, and a person from these definitions. Or at least ask ourselves "What type of tester am I" and find a way to improve.

Thanks Rob!

A Compact Fluorescent Lightbulb Moment...

Two testers on two different projects. Both working for the same organization. Both on an email thread describing processes/practices currently being used or intended on being implemented in the future - across the board - as best practices. For one of these future goals, tester A says it would be a good idea to implement it. Tester B says no thank you.

I was tester B. Later on, I was asked personally why I said no. I explained why, based on my project and my team. But I felt like I was missing something in my "arguement" and I felt like more explanation was necessary though I could not verbalize what that was. Days passed and I could not stop thinking about the missing peice. I could have argued about "best practices", but that did not seem to be the right route to take. I had to take some time to think this out, and time is a precious commodity when releases are pending and you have to balance those late days with your home life.

I kept talking to myself (I tend to do that alot :)) about the different projects in my organization. About how project A differs from B in some aspects, and project C is in a league of its own. The differences in the projects range from code language, release cycles, size of product/application, and how test leads manage what/how it is tested, etc. When you have multiple projects in test, it seems to be a valid point to attempt to take what works on one project and apply it to the others in an effort to have "best practices", so continuing to talk about the differences might only illicit that same feedback... so I continued to think about it.

I don't believe in adding processes or tasks to a testing project that do not benefit the success of the project. I need suggestions to be validated, even if it is in an abstract form initially, in order to see the value of doing something. I do not believe in wasting time because time is limited, testing takes time, and testing costs the organization money - it does not make money - so it should spend both wisely. Because I feel this way I think not only about whether or not a practice is best, but whether or not it is time/cost effective.

It was at this point that I remembered something. A compact fluorescent lightbulb went on just over my head... The Seven Basic Principles of the Context-Driven School. While I had read this before and read several debates over it, I had not realized the importance of what it was saying. This was my missing peice. Co-authored by Cem Kaner and James Bach, this is a very well thought out and written explanation of my sub-conscious reasons for not wanting to see processes/practices implemented across the board whether or not they benefit the individual projects (or taking that down to the root - whether or not they benefit my project).

Today I will share this explanation, along with my new found understanding of it, with those who asked me personally why I said "no". At the very least it will give us all something to think about and talk about.