Saturday, March 15, 2014

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

Monday, March 10, 2014

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.