Me Versus Them

This past week was a bit more frustrating than what I am used to. Almost everyone and everything I came into contact with had a slight “Alice in Wonderland” aspect. For nearly three straight days I was sure that I had drank from the same little bottle that Alice did and ended up in an alternate universe instead of Wonderland. I did not know if this temporary insanity was attributed to the people and things that came in and out of my life; or if it was internal and personal. I ended up attempting to understand it with a Me versus Them mind set.

Me versus Them means someone is to blame. I do not usually go down this path. It is non productive and results in negativity. I knew I needed to sort through the thoughts and process them. Time and duty do not always allow this to happen as quickly as it should. Here is what my process looked like over the last three days.

Day 1: Two people that I admire and generally draw some guidelines from were missing in action. I decided to attempt to talk it out with someone outside the realm of my profession. This conversation did result in some ideas for me to think over, but this person only knew me personally and has limited understanding of what I do. The relationship is also too close for it to have the same effect. You need to have unbiased opinions and thoughts in order to assess some issues. You need input that comes from someone outside your personal circle who can add some balance.

Day 2: I drank two glasses of wine and ate chocolate.

Day 3: I changed my perspective. I deliberately woke up with a decision that I was not going to keep hold of the Me versus Them mentality. I decided I was going to be an observer for the day. I wiped the slate clean for people and projects. When I arrived at work I put some alternative music on, loaded up the most recent build of the product I was testing, and went for a road trip through it. I applied a lot of what I had learned during the Rapid Software Testing training to the product. I also applied it to people.

There are two things that I am grateful that I learned through the Rapid Software Testing training that I received about a year ago. (The company I work for was gracious enough to hire Michael Bolton to come on site to train us.) The first is that I can fit what I learned through the class into what my testing processes are. I can decide when and where it will benefit my test project. It is less a set of rules as it is a style of thinking with guidelines. The second thing I learned is that a lot of what I can use for testing from this training can also be applied to other areas of my life. It has helped me to develop better people skills as well.

[Okay, that was shameless promotion of my personal favorite testing style.]

By changing my perspective and simply observing the things and people around me, I was able to assess the situation and find the root of what was going on with Me. Once I dealt with what I needed to deal with in Me, I was able to deal productively with Them.

Documenting Head Knowledge

I test multiple products for multiple Lead Testers. I simply love it. I am never bored and my mind and eyes stay sharp because of it. The challenges are exciting, the pace is generally fast, and the people on my team are marvelous.

Our products have multiplied and our collective processes need to be looked at continuously in order to keep up with the demands on our team.

No matter how many products we accumulate, or what the schedule is like, people on the team still have lives outside of work and so they still need time to be with their families. This time off is usually referred to as a vacation.

Vacations can teach people a lot. This is especially true if more than one person is out at the same time. If you are one of the lucky ones to be left on site during this time, you may notice some things.

First you may notice that the person is not there. The role they usually play on the team will appear vacant. If you are going to notice, it will be by day two or three. An example would be if the one who is generally the team cheerleader is on vacation, you would notice overall enthusiasm has dropped a degree or two. Because you spend so much time in the trenches with them, you miss them.

The next thing you may notice is that there is missing Head Knowledge. In other words, some significant information about the product that has not yet been documented yet is not available for you. That can make you feel like you have instantly come in contact with a Black Hole. This condition is especially noticeable if someone in management asks you a question that you cannot answer because you have not been testing the application for a couple of weeks and there is no documentation available for you to draw the information from.

Most of us have Head Knowledge that really matters to the products we test. Some of it is a valid and valuable resource for documentation.

I am also a Test Lead of one of our products and found that I was missing the same information that I had needed from the Lead who was on vacation. (Yes, this is an actual experience and not a “what if” situation.) I immediately drafted a quick document with this info in it and put it in a place the rest of the team could access it.

One of the processes that I need to look into is defining the Head Knowledge that I have and deciding what I need to document. When I look into this I will need to make sure that the most junior team member would be able to survive on it if I go on vacation.

Bear in mind the type of documentation that I am referring to is not test plans and test cases, but rather the auxiliary information that is vital to the success of whatever product I am responsible for. Being responsible for it means that I need to care enough about it that I can leave it with a “babysitter” without worry. I would not want to leave the product or the rest of the team in a position that makes either of them suffer. If either of them suffered during my absence I would feel that I let them down. It is part of my job to see to it that the products and the people that I am involved with succeed.

Event Improvement

I find it extremely funny that if I am asked to look for a Process Improvement, I go blind. I come close to panic. I suddenly don’t even know what a Process is or if I even utilize any.

The quote from the previous blog that I wrote was from Alfred North Whitehead. He is credited with much of the modern views of Process Philosophy. Process Philosophy basically defines reality as the processes that occur, the events versus the starting and ending points.

I have read a bit about it, and I began to have a greater understanding of what a Process is. I decided to replace the word Process with Event. I felt it would not be as intimidating for me to look for an Event Improvement.

So how could I apply this new terminology to my software testing tasks?

I decided to begin at a very elemental level. I would map out every action that I did between the start and the finish of a task. That would be my Beginning and my End. These two things are not the Reality of what I do. In fact, they can be dismissed altogether if nothing occurs in between them.

Right now, the map looks like this:

BEGINNING -->END

Not a whole lot of information, so now I would begin to mechanically write out all the steps I take in between. It is advisable to do so without questioning what steps are being followed, just to note what they are.

Now, the map looks like this:

BEGINNING-->STEP 1-->STEP 2-->…..-->STEP13-->END

In order to look for possible improvements in the Event, I would now begin to question the Steps.

The map begins to branch out in several directions. I will count each Step I took as the “what”. I will add to each of these Steps the “how” and “why” questions. After evaluating the “how” and “why”, I then evaluate the whole map. Do I need to add or remove Steps? Do I do nothing at all?

If I have to add Steps, it may still be considered an Event Improvement. Adding Steps may increase coverage or provide some previously elusive information.

I may need to remove Steps. This generally cuts down on the time it takes to go through an Event.

Of course, there is also the possibility that no Steps can or need to be altered at this time. Having looked into the Event enables me to be accountable for it on a higher level than before. Now I can say “how” and “why” I do “what” I do.

Event Improvements, even on the lowest of level, can save a lot of time and energy that could be better spent in another Event.

***By the way, I know that grammatically Event and Process cannot be interchangeable. They are not synonyms. I am simply using the interchange as a word play exercise.

Change

Change is imperative in the career of a software tester. It is the one thing that is a constant. Everything else will not be the same in a year or two (or next week, or tomorrow).

If you test COTS, the operating systems and additional features or enhancements will cause you to create new test cases and eliminate test cases that are no longer necessary. In addition to the technical and technological aspects, you may have staff changes in the test team or in the development team.

Mostly, the number one thing that needs to continue to change in the career of a software tester is you.

You have to constantly keep your skills up to date. You have to constantly research new technologies that will affect the products that you test. You will have to constantly evaluate your processes and your test cases. You will have to keep your attitude positive to change. And you must be willing to believe that failure is an option (I am referring to the individual, not the product. I would not want this option in the software on an airplane I may be flying in.).

You will not be successful when navigating through the changes 100 percent of the time. Innovation requires risk, and risk may sometimes result in failure. It is my belief that failure rates can be reduced largely through others.

If you sit back and analyze where you are right now, you may notice several individuals in your organization that can help reduce your personal risk to failure quotient.

If you are a tester, you may have a Lead available who can assist you with assessing what areas you need improvement in and what areas you may want to add growth to. The Manager of the test team may be available for this as well, especially if you receive performance reviews. And most managers would love to have you ask “above and beyond” questions, after all your success reflects upon them.

Self-assessment is a good tool you can use to better understand your strengths and weaknesses. Here you can ask yourself questions about your skill level, attributes, knowledge, communications, etc. Keeping a journal can help identify the differences between where you think you are and where you really are. This tool requires self-discipline.

Other software testers around the globe are also available at your fingertips. There are blogs, forums, and clubs available. It is highly probable that if you have a question, someone will answer it. In fact, you may find a highly diverse set of answers and be able to select enough information to form a foundation for your own answer.

I leave you with this quote from Alfred North Whitehead, “Almost all new ideas have a certain aspect of foolishness when they are first produced.”

Why Share?

My father’s occupation was that of a weaver. He started out sweeping floors in the same mill his father was weaving in. The first material he wove on the loom was fabric. On the job training and strong observational skills brought his knowledge level quickly up to par with the other weavers. And then he surpassed them and took some chances with his career. He knew what he knew and he did not feel the least bit inhibited to take a chance at furthering his career. He called a “head-hunter”, who in turn found him a job weaving composite materials.

During the formative years of my life, I watched my father with great awe. For a few years, he was one of three men in the international community, who could weave some of the composite materials with near perfection. I watched my father go from the weave room to management, even ending up in at least one trade magazine. I was so proud of him. I knew he was an achiever.

Years later, I had the opportunity to work for and with my father. He was managing a weaving facility in the same town that I lived in. I was a fourth generation weaver for close to six years of my life. It felt somewhat like an honor to have that title. The problem was that my father did not share with me his knowledge of the trade. He taught me the basics of weaving, and I, being as much a perfectionist as he, was rather good at what I did. The problem was that I had no deeper knowledge of the processes and the mechanics of the job.

I shared this with him several times to no avail. I remember him saying, on multiple occasions, that people who consulted with him, “just want what is in my head”. Well, yeah. If they wanted what was in a book they would have bought it.

The trouble is that my father did not understand the concept of sharing knowledge. He thought that people wanted something that he had for free. He did not understand that when he shared knowledge, more knowledge would be made available to him. He did not understand that technology is constantly changing either. The same people, that wanted the knowledge that my father had, found it on their own. They no longer needed him. This crushed him. He felt as if he had been put out to pasture. In essence, he had been. He refused to share in the building up of the career that he had at one point been a huge presence in.

What does this have to do with software testing?

I see the same thing happening all around me in the field that I work in. There are so many people testing software and yet so few sharing any knowledge about what they have learned. The problem exists in the software testing community in general as well as within organizations that test software.

I have, through the last few years, seen one very valid truth in all of this. The most successful software testers of our generation are the ones that willingly share information. They have cast aside their fears, whatever they may be, and decided that the profession must come before the person.

I truly admire this. And I have learned lessons from it. One thing is sure, success depends on you taking chances.

Research and Reminiscing

One of the aspects of testing that I really enjoy is research. It inevitably invades almost every aspect of the job.

Researching may involve looking for answers to what the application is supposed to be doing (usually from “specs” actually being “speculations” versus “specifications”). It may involve learning about a new and improved operating system (okay not quite new and not so much improved), in order to assess how the program in test might perform. Researching what testing methods may apply to the test cycle. You may find that you have to research a competitor product. One way or another, you will be called upon to research something, at sometime, by someone.

I first fell in love with research back in High School when essay assignments were given out. I could hardly wait to begin. It never mattered what the assignment was about, just knowing I would be going to spend a bit of time in the library was good enough for me.
The first thing that hits me when I enter a library is the smell. I swear it is the smell of old knowledge mixed with the times it was written in. Then there is the magnificence of thousands upon thousands of books, neatly arranged according to the Dewey Decimal System upon hundreds of book shelves where reaching the top shelf requires a ladder. The noise is always interesting, too. People enter a library with the understanding that they must be quiet, and yet there is always some noise echoing through the place. Someone clears their throat or coughs, someone is wearing shoes that tap-tap-tap on the flooring, someone is opening the card catalogue, the librarian is stamping a book that someone wants to check out, and a mother is “hushing” her child. It is random noise, but somehow it brings life to the library.
My research projects do not take nearly as long as they used to. So much is available at the touch of a keyboard or the click of a mouse now that technology can enable us to access so much in so little time. There is still the need to sift through and siphon off what is valid and what is not, but sometimes I miss the library. Perhaps I will take a field trip to one very soon and rediscover it.

Thinking

I am a software tester who enjoys learning. One of my interests lies in learning about the process of learning. I ask a lot of questions, not only of others, but of myself. Why do I learn the way I do? What conclusions do I draw? Where do my thoughts come from when I apply them to an issue or a problem? How could I apply a different thought to the issue? Why do I think the way that I do?

By asking questions of myself, I allow myself to be critical of what I am thinking. This enables me to check my thinking and envision different answers; that in turn generates new questions. This may reveal points in the issue that I had not considered before.

Being critical of your own thinking does not come naturally. It is something that needs to be learned and applied. One of the simple tools that I use to remind myself to question my thinking process is a whiteboard. I will draw charts, maps, or words on the whiteboard that involve the process of thinking. For instance, I may just write the following words:

Observe-->Focus-->Interpret-->Assumptions-->Conclusions-->Action

While testing the software and questioning the program at hand, I will occasionally look to the whiteboard in order to question myself as well. I do not allow the whiteboard to become static, but change it every week or two in order to prevent my thought process from becoming static. This also enables me to defocus when I feel I have covered everything that I could think of in a program that I am testing.

I have always thought about thinking, but it was not until I stumbled into software testing that I began to have some understanding about the processes of it. It was in learning about the process of software testing that I found excellent teachers from various web sites, books, and in the “classroom”, who teach not only about the testing, but about the tester. The tester’s mind is where the most valuable tools for the trade lie. Studying the processes of thinking help to sharpen these.