Testing Strategy and Test Planning - My mindmap

I do not subscribe to any testing related blog feeds. Instead, I pay close attention to Joris Meets' twitter feed and check Ministry of Testing feed. Both of them do a great job of consolidating important testing related blogs/articles. While browsing through James post on Test Jumper, I liked what he wrote. It matched with my preferred style of working - help people identify traps, test with them and create an environment conducive to learning and improving testing skills.

There have been instances in my previous and the current organization where I am called upon to help a project which is going nowhere. Most of the times, they face one of the situations:

• Important bugs being identified late
• Testers on unplanned leave
• Unstable product or need for better coverage
• Inexperienced project team
• Important project

I like such challenges. They seem to get the best out of me. I visualize this video and feel good at the additional responsibility given to me.

I started thinking of what gives me the confidence of taking up the role of a Test Jumper. Can I pass any checklist for someone to use and build on it? I launched XMind and here is the output. 

My Project Preparation

This is again a heuristic and not a final plan. It depends on the project, answers to the different questions and other factors like project, team, stakeholders, risks and deadline :) 

Leia Mais…

Testing Timeline: What is your %

Do you test software? Do you test every day? Do you get paid for it?
If you answered yes to any of the two questions, I have one more question for you :)

What percentage of office time do you actually test (interact with the software)?

The answer to 'Testing includes...' might differ from one person to another. I don't want to get into that discussion right now. I am more concerned when people spend very little time interacting with the product and complain of bugs being found by the customer. Consider the following three scenarios:

Scenario 1:
A feature has been revamped and will be released to market soon. A tester who has never worked on the feature is called to test the revamp. The tester could:

• Understand the existing feature
• Understand the revamp
• Analyze the XYZ specification
• Write test cases
• Test the feature and file bugs
• Test the system

Scenario 2:

Your team reaches office at 9am and is available till 6pm.

The total time spent testing the product on an average is 3 hrs. Rest of the time is spent on the following:

• Attending meetings
• Updating KnowledgeBase pages
• Plan for next release
• Taking interviews
• Document the learning

Scenario 3:

Here is a tester who refuses to follow the rules. She never attends any meeting unless her inputs are a must-have. If she wants to learn anything, she knows the right person who can help her. She is very good at networking and has lots of friends in the whole company. She has one bad habit though, as her colleagues mention. No - not the one about rules, when she is given a feature to test, she spends most of the time interacting with the feature. Her activities can be summed up as follows: 

• Understand the mission quickly
• Highlight the traps and risks
• Test the feature, system
• Use information from different sources as a heuristic
• Get help from those who can help her

What is your take on 'How much should you INTERACT with the feature/product/system?'

If you are smart enough, I would expect your answer to start with

.

.

.

.

.

.

.

.

.

'It Depends...' and continue the discussion. At the same time, I am open for new answers.

Leia Mais…