Breaking Testing Mindsets

testingmindset
For photo credit click here. This article was first published in June 2011 in Testing Circus. I have revised my original article for this posting.

Most testers have experienced the problem of needing to break testing mindsets to develop new testing ideas. Mindsets are basically traps we fall into such as testing the same keystrokes and solving problems using the same strategy. Making bad assumptions is another trap that can stop the tester from asking more questions or approaching the problem differently. Such as assuming something is not important to the client because it is a small feature. Over time, mindsets can become roadblocks to testing as we find less bugs believing the product is becoming more stable when in reality there are still bugs but we are not finding them. It is important for all testers to challenge how they approach testing.

We should learn from every mistake or lost testing opportunity by reflecting upon what we could have done differently in order to identify personalized learning buckets. Use this information to find new ways of testing in order to break those testing mindsets. Develop relationships with stakeholders to dive more deeply into the testing assignment to ask more questions and identify different ways to test. Continue to think outside the box by identifying what constrains or limits testing. Most importantly, always keep learning; challenge your skills; and never become complacent as a tester.

Identify Learning Buckets
Learn from missed bugs or new features not tested correctly to develop lessons learned to understand how the feature could have been tested and how that information might have been identified during testing. It is helpful to segment this information into personalized learning buckets. For example: training on the company’s product; knowledge on how the customer uses the product; deeper relationships with stakeholders; and problem-solving skills. Also identify the type of assumptions being made during testing. Through these learning buckets, identify strategies to improve testing skills in order to start removing testing roadblocks.

Product Training
It may not be possible to learn everything about the product; therefore, identify the subject-matter experts that can review the testing strategy to determine if anything is missing. Prior to meeting with the subject-matter expert, gather and review any requirement documents, training material, or other documentation provided to outline testing ideas and questions. This can help bridge both product and customer knowledge which can be brought into testing.

Challenge Assumptions
Identify the assumptions being made and then challenge those assumptions to determine if the testing approach changes. Do the assumptions have a pattern? For example, assuming a feature is not important because no one indicated its importance. Assumptions can become dangerous traps and over time may be filed away and not addressed during testing. For example, not having the test data to perform specific tests may have been acceptable in the past but as the feature evolves that assumption may no longer be correct. Identify old assumptions that no longer apply because the product or customer needs have changed. Whenever making an assumption, stop to identify the facts to determine if additional information or communication is required. When in doubt have a conversation with someone (ie., subject-matter expert, a test lead, developer) to review concerns and questions.

Think Outside the Testing Box
Identify what prevents or limits testing ideas and strategies. For example, a requirement document can be helpful in understanding intended functionality; however, how does it limit testing? Is this document being used as a checklist to perform testing within the box or is it being used to foster conversations with subject-matter experts on intended functionality to generate testing ideas that go beyond the written documentation. When reviewing the learning buckets, is one of them: “I did not test that because it was not in the requirement document.” If the answer is yes, then the requirement document is becoming a roadblock in generating testing ideas.

Is the testing based upon test cases that are providing diminishing-returns? If test cases are required, how can they be changed to become more fluid to avoid retesting the same key strokes, parameters, or test data? Consider rewriting test cases into testing ideas providing guidelines but not specific steps to test a feature.

Problem Solving Skills
Play games that require identifying different approaches to solve a problem. If you can, play them with friends to share and compare strategies to identify other ways of thinking through a problem. Identify your typical thinking patterns and understand how others are addressing the same problem differently. What can be learned from these differences to start removing testing barriers?

Now it is your turn! What are your experiences, thoughts, or observations?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: