Planning and execution problem solved

I like doings my testing tasks really well. In fact, I prefer not starting a task to doing it in a sloppy way. Now, this created a problem whenever I was working on a project. There were many tasks to perform every day. In the past, it used to take a lot out of me in taking the actions related to my task. First, I used to understand the task and then estimate its priority (to schedule it accordingly). Then, I planned the approach to perform my task and identified each sub-task that required to be done. I performed each sub-task and tracked my progress frequently. After completing each sub-task, I reviewed it. Then, I reviewed the entire original task first with respect to each sub-task and then with respect to the original objectives. Finally, I communicated my task completion to the relevant people.

Why did I end up expending a huge mental and physical effort in performing each task? Other than my desire to really shine at the task, I found that I repeated a lot of planning that I had done in the past on similar tasks. Attempting to excel at my task is welcome. It gives me the satisfaction that I am not doing the task mechanically. However, re-thinking everything is definitely overkill. Not required in a majority of tasks. Definitely not desirable in every iteration of the task.

I needed to solve this problem. That is, I had to balance my wish to do really well with my need for speedy execution. Here is how I created my solution to this problem. First, I identified a couple of non-trivial tasks that I had to repeat. In my case, I selected 1) Review of test cases and 2) Creation of the monthly test results. Later on, I realized that this solution can be applied to any other repeated non-trivial tasks such as 1) Design test cases, 2) Execute test cases and 3) Log bug reports. Second, I made available to myself an ample time slot when I would work on nothing else but this selected task. Third, I started working on the task. But there was an important difference to the prior executions this time. I documented my approach making notes as I went along the task. For example, starting the test cases review, I listed each item that I had to plan e.g.Whether to do a high-level or detailed review or a hybrid review, Sequence in which to review the test cases, Level of detail in my review comments. While actually performing the reviews, I listed each sub-task as I remembered it e.g. Check if each requirement in scope of the test case is covered, Check if each design is covered in the test case, Check if there is an incompleteness in steps or expected results or test data, Check for duplicity within a test case or among two or more test cases.

Finally, I ended up with a nice long list of sub-tasks (with comments) that I needed to perform to do justice to my original task. Some sub-tasks were linked to the understanding of the task, some to the planning, several to the execution and the others to the own review. Now, every time I faced this task, I did not go about it in my earlier way. I got my list out, looked at the list of sub-tasks and started executing them. Whenever I remembered a missing sub-task, I just inserted it in the appropriate place in the list. This practical list was really my own task execution procedure.

How does this help you? If you are like me and want to perform due diligence on your important tasks, your own procedure will help you do just that. You will no longer need to rely on your memory alone. The second benefit is that it will reduce the planning effort required. You will just look at each sub-task in your procedure, decide if it is relevant to the current situation and if so, perform it. The third benefit is that your procedure will keep you focused and on track. If you enhance your procedure with every iteration of your task, you get the fourth benefit, which is improving execution ability. You will get the fifth benefit when you share your procedure with your team members. Your team members will improve their execution ability by benefitting from your procedure. In turn, they are likely to give you feedback that will help you enhance your procedure even more. Your procedure will also be a good means to transfer execution knowledge to new team members.

If you are excited about creating your own procedures in order to excel at tasks, you should take a few pre-cautions:

1. Do not get over-ambitious and try to create procedures for every task that you perform. If you do, your work will slow down to a crawl and you may be overwhelmed quickly.

2. Choose to write the procedures for only regular AND non-trivial tasks. Do not spend hours writing a procedure for a task that you will perform once in six months (and the project situation may be quite different at that time). Do not write a procedure with obvious steps e.g. you know that you have to fill up each relevant field in the bug report form before you submit a bug report.

3. Once you have a procedure ready, do not delete a sub-task even if you find that it is not required in the current task iteration. This sub-task may very well turn out to be important in a subsequent iteration.

If you work with a process-oriented organization, you will find that documented procedures are available for only the major software testing tasks. In other organizations, you will find that you only have high-level industry guidelines and standards to follow. In both cases, you will find your own procedures very helpful. How else do you think high performers are able to produce substantial results in half the time that you take?

Why you shouldn't be too nice?

Let us say that you are starting out in a project. You know that "people like to work with nice people". Therefore, you decide to be nice with everyone in the project team. You get these benefits:

a. The team members share their knowledge with you.

b. They help you understand the software application and the process they use.

c. They introduce you to the people related to the project.

d. They invite you to project meetings.

e. They explain and share their project work with you.

So far, so good. But what happens when you have decided to be so "nice" that you have forgotten how to say no?

1. You are given responsibilities loosely related to your role that nobody else wants to take because they are "busy". Examples could be completing some old documentation, preparing the conference room for the team meeting and arranging the team lunch.

2. When you approach someone, you are advised to fix up a meeting but you are constantly interrupted yourself. The team members feel free to walk up to you or call you and discuss whatever it is they want to discuss.

3. Your schedule is modified constantly. Here you were working on a task but suddenly something else has come up and you need to attend to the new task. While you were busy completing the new task, your old task has been cancelled or re-assigned to someone else so now you need to discard your work.

4. You always work based on someone else's estimates. Examples could be that you may estimate a task taking you 8 hours but your manager wants you to do it in less than 4 hours. Or, you may want to prepare for a task and then do it but your teammate suggests that you do it directly.

Do you think that being "too nice" will affect your performance on the job? You bet it is. Just consider the four effects above:

1. You are spending your precious time on busy work that just about anyone could perform. Worse, this work may not be required at all.

2. Your concentration is being broken repeatedly. Coupled with the loss of your productive time, you end up work superficially.

3. You cannot plan ahead of time because your schedule keeps changing. You may not get good ideas immediately when faced with an urgent task.

4. You are tired or confused because you are working according to someone else' work style or speed.

The sad thing is that you may be thinking that you are working well trying to please everyone in your team even when in reality you are putting up a mediocre performance. Worse, you are positioning yourself as a "nice" person in the eyes of your team members more and more with the passage of time.

I can say these things from personal experience. Because, I too have been the prey to my "be a nice guy" approach from time to time.

The question is what should we do? Should we suddenly stiffen up and become very demanding from others? No, we should continue to behave cordially with our team members. However, we can ask ourselves the following questions:

a. What is my role in the project?

b. What actions do I need to take to fulfill my role best?

c. What actions do I need to refuse to fulfill my role best?

d. How do I guard my own productive time best (and still be respectful of others' time)?

e. How can I create or at least influence the approaches and estimates for my own work?

The only thing left for us to do is to make the changes according to our responses.

Good job performance requires confidence in our actions. This is especially true of software testing. After all, software testing is about generating confidence.

Test Strategy - How to define and implement it?

On this October 14, I attended a web talk by Alan Page along with several others. The topic of Alan's session was Test Strategy. I would like to list the points that I saw and heard Alan make before making my own observations:

1. Consider the context before creating your test strategy. It is useful to consider your own situation in terms of your team's composition, their current skills, their desired skills and other goals. For example, it may be okay communicating the test strategy verbally within a small team of say up to 20 people. However, when you have a large team, it becomes useful to document the test strategy and distribute it so that everyone is on the same page.
2. After considering your context, the next step in the process is your fact-finding and assessment. This helps you answer questions like how is testing at present, how would it be different in the future, would other parameters change and how could the team change to meet the future requirements.
3. A useful way of clarifying your thoughts is to map your facts to goals. What is your current state (fact) and what is your desired state (goal)?
4. The journey from your Current state to Desired state may not be a straight jump but a series of steps. However, each step should aid the transition away from the Current state and towards the Desired state.
5. Once the strategy is in place, just take the desired actions. Track and review the progress and adjust course if required.

It was a clear and thought-out presentation. You can view the talk here. It should take you about 30 minutes to listen to it. Now my questions and comments.

1. Each action (even the tiniest one) taken in an organization should contribute to the organization's objectives positively. How does the test strategist ensure that each step outlined in the test strategy maps to the organization's objectives and ultimately to its vision? A test strategist should be keenly aware of their organization's business objectives. Further, the test strategist should be aware of other factors such as the current customer experience, competition and the direction the industry is moving.
2. Implementing a test strategy in a sizeable team is no mean task. Other than piloting actions and showing supporting data to other team members, what are the ways to smoothen the implementation of a test strategy? It may require sessions to explain the test strategy to each team member, arranging and executing any training they may need and providing the supporting processes and tools to the team help take action to move to the Desired state. Explaining what is in it for them, recognition of good performers and championing the test strategy may also help attain buy-in from the team members.
3. How does the test strategist know that they have arrived and it is time for the next strategy? By ascertaining if the desired state is institutionalized (data consistently points to the desired state, team members discuss about the Desired state as the Current state and team members have become a little complacent).