How to create reusable test materials

Reusable test suites should only be created under the appropriate circumstances, cautions expert Karen N. Johnson. She explains how to work with the client's unique needs when creating reusable tests.

I am a test lead working in a reputable organization in India. My manager has an idea to create reusable test suites to test different applications related to different clients pertaining to one domain, say banking or insurance. I wanted to know the feasibility of this using manual testing. Can you suggest ideas or throw more light on achieving this task?

The most important part of your work is to fulfill the client's needs. This is an opinion, (well, I suppose this entire response is an opinion) but unless you address a client's specific needs, you're not serving your client. Testing is not a repeatable clerical task so be careful trying to lump all clients (even in the same vertical space) in the same bucket.

I do think it is possible to create some reusable test materials in your situation as I understand it. I will outline tactics on how this might be accomplished.

Two words: commonality and exceptions. Let me explain. If you look at a vertical market such as e-commerce, you could map out a set of common functionality with an eye towards reuse.

I might break the process into the following steps:

    1. Identify the vertical markets that your company services -- wherever there is more than one client. Examples include banking and e-commerce.

    1. Brainstorm on a common set of functional and other issues as relevant to the vertical market. At this point, you're collecting ideas of your own, your teams, perhaps other people on the team, etc. Here is an example using the e-commerce environment. You might identify functional test areas such as shopping cart, pricing, taxes, shipping, secure pages, login, order history and so forth.

    1. Build a vertical market list of ideas. From the brainstorming and collecting process, I would either create a laundry list of ideas (stay at the high-level category -- not down to individual test cases) or I would build a mind map of the areas. Use whatever format you feel would be most effective.

    1. Build a client-specific list of ideas. Review the clients in the specific vertical market to find additional ideas. You might find by reviewing each client individually that you add more items to your list or map, or change how you think about each area after thinking about specific clients. For instance, you might find that for all e-commerce clients testing product pricing regardless of the type of products sold is a necessary functional test area. Or you might discover that some functionality is too unique to try to create standardized tests.

    1. Refine a list of test ideas for each vertical market. For example, the login for customer accounts might include a check of active and inactive accounts for all e-commerce clients.

  1. Refine a list of test ideas for each client. I would return to each client and build for exceptions. Clients are not the same. Even e-commerce sites hold differences that must be recognized and then tested for accordingly. Again, let me use examples so as not to be vague. One e-commerce site might ship products and taxes and shipping could be a relevant area to test. Another site might provide immediate access to information and taxes and shipping do not apply. In this second example, the e-commerce customer might have additional tests such as their own credit card with specific card tests that need to be executed.

I would add one more step for my team if I were in similar circumstances. I would host team debriefs where client folklore was captured. I would look to building a list -- perhaps even a defect list that identifies the areas each client has issues with. This is one more way you could capture knowledge and not lose sight of the unique needs of your client. Before testing another release for the client, I would review the collected knowledge so that despite a potentially rotating staff, the team has the specific client needs in mind.

Approach: I would advocate to management to allocate at least some amount of testing time to be addressed with exploratory testing. Or perhaps all of the testing to be covered by exploratory testing, building charters by using the lists as outlined above -- you and your team will have many ideas. By using exploratory testing, you can use the creative and intellectual skills of your testers.

Software testing resources:
How to design test cases

Modular test case design consolidates tests

The value of documenting test case results

Educate: I believe it is important as a test lead to educate management about testing, in addition to encouraging and inspiring the education of your team. Educate management about testing as you work through the process. If you lump all your clients in the same bucket and try to offer cookie-cutter services, I would suspect that clients won't be pleased. Work with management to educate them about testing; help them to value testing and not just focus on economizing. If the clients are displeased, reuse means nothing.

Best wishes.

Dig Deeper on Topics Archive