Sunday, October 24, 2010

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.

Sunday, October 17, 2010

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).

Friday, October 15, 2010

Why software testing should be like good journalism?

Don't you just love news? News is an important part of our lives. It keeps us informed about the happenings in the world around us. Further, news helps us update our mental model of the world so that our understanding matures from that time onwards. Now, news are gathered and communicated to us by journalists. Let us see what can we apply from the world of journalism to software testing?
Similarities between journalists and software testers
A journalist has a network of sources to inform her of interesting events.A tester has a bunch of tests to inform her of interesting facts about the system under test.
In order to stay on top of events, the journalist stays in constant touch with her contacts.In order to stay updated about the current quality of the system, a tester executes her tests regularly.
The journalist seeks to strengthen her network by adding new contacts or replacing her contacts with better ones.The tester seeks to strengthen her test suite by adding new tests or enhancing her existing tests.
As soon as the journalist comes to know about an interesting event, she starts working to gather all possible information on it.As soon as the tester comes to know about an interesting bug, she starts working to gather all information about it and isolate it.
A busy journalist has more than one story to work upon at a time. She follows all of them as they develop but focuses her attention on the ones most critical to her readers/ viewers.A busy tester has more than one bug to work upon at a time. She follows each of her bugs but focuses her attention on the ones most critical to the system's stakeholders.
A journalist does not work alone but seeks help from others to create the best possible news story.A tester also relies on her team to provide her insights into areas requiring more testing, re-usable tests and better testing techniques.
Now let us see what we can learn from not-so-good news stories.
A late new story: Nobody likes stale news. Stale news makes us miss opportunities and disappoints us.Our tests should be freshly executed. Our bug reports should be promptly reported giving timely information to our stakeholders to understand, digest and decide actions based on our bug reports.
A poorly labeled news story: We decide to read/ view a news story based on its headline. It wastes time if the headline is not a true representation of the news story and we stop reading/ viewing the news mid-way.Each of our bug reports should contain a true summary of the bug. This would enable our stakeholder effectively decide whether they want to read it it or not.
An incomplete news story: We don't feel good when we have a number of open questions after reading/ viewing a news story. It requires additional effort on our part to seek missing information from elsewhere or follow the story further.Our bug reports should contain each required information item e.g. the steps to reproduce the problem, the actual result, the expected result, the test data used and the test environment in which the bug was discovered.
A repetitious news story: We don't want to waste our time on reading/ viewing details that we already know about.Each of our bug reports should contain unique information and not duplicate information that is already known via other bug reports.
I am confident that the next time you read or watch news, you would think about the things that you could apply or avoid in your own software testing. Let me know if you find other lessons for us to learn from good journalism.

Sunday, October 3, 2010

How fast would you progress in your software testing career?

If you are a software testing professional and wonder about your career growth, take the short quiz below. Select just one answer, A or B, for each question. Add up the number of As and Bs in your answers.

1. What is the most rewarding effect of your software testing career?
A. Money
B. Job satisfaction

2. How do you plan your testing tasks?
A. You prefer your tasks to be planned by someone else and told to you.
B. You analyze your tasks, prioritize them and try to provide the most value in each task.

3. What is your driving thought when you test software?
A. Finish the tests that you have been assigned and go home
B. Test carefully to not miss any problem

4. What do you worry about the most before submitting a bug report?
A. That it is not an invalid or duplicate bug report
B. That it contains enough information to help identify a real problem

5. How do you handle free time (say, between projects or assignments) at work?
A. Socialize/ catch up on personal tasks/ take it easy
B. Analyze own performance and prepare to deliver increased contributions

6. Do you think about software testing in your personal time?
A. Never, what is the need?
B. Of course, it is an important part of my life

What kind of progress should you expect for yourself?
Excellent: 0 As and 6 Bs
Good: 1 or 2 As and 4 or 5 Bs
Average: 3 As and 3 Bs
Below average: 4 or more As, 2 or less Bs

Notes: 1. Money can only motivate you to a limited extent; the intrinsic job satisfaction is what drives you in your career constantly.
2. In order to contribute the most, you need to identify your most important tasks and perform them to the best of your abilities.
3. Each test that you perform is an opportunity for you to excel. Do not squander such opportunities.
4. Always focus on the positives. Instead of worrying too much about making mistakes, focus on your real responsibility.
5. You should always be planning and working towards progress in your career.
6. If software testing is a part of your personality, you cannot help thinking about it from time to time.