Well begun is half done – The need for a well-planned test design

Introduction: 

Think not as a software professional – What comes to your mind as soon as you hear the word – Design? If your answer is Fashion, the key is cutting the piece of cloth right to be sewed together later.

If your answer is Interior, the key is measuring and analyzing the place that requires the facelift.

If your answer is Circuit, the key is understanding your end product and making sure you have the necessary components.

The cutting, measuring, analyzing, understanding and making sure, is what we are talking for a software product too. This in a nutshell explains all that should go into a strong test design.

The phase called Design: 

Though there seems to be emerging processes that claim documentation is not it all, the industry may not be entirely ready to take this route.

When it comes to test design, this can be broadly classified into a high level test plan and a low level test case.

That being a known fact, are we documenting enough? The bitter truth, especially when it comes to a test plan is that, this phase / document is taken for granted.

After a few releases, this becomes more a template and a formality. But a passionate tester would agree that this is the most creative document one can write and a good test plan should have it all.

Similarly when it comes to test cases, there is a tendency to call it time consuming, so keep it short.

With the need for quick turnaround, this may seem like the only solution. But what is the impact? The impact could be huge.

When things go right there may not arise a need to revisit but when there is a chaos, “short” may not be considered wise then.

So it is best not to compromise on time. The end user may not see the value in the time spent on designing a test case but this should strictly be made part of a project plan giving it its due respect.

Tips and tricks for a better design: 

It is an accepted fact that a test case is the smallest unit of test material and one must not be able to break it down further.

But where does one start when writing a test case? Here are a few tips that will come in handy.

Going back to the aspects discussed earlier that should go into a strong test design, here are the five phases to build on.

Each phase feeds into the next strengthening the confidence in the targeted test design.

Cutting:

What we call “cutting” here is, defining the scope of testing clearly in your test plan. Don’t stop with broad classifications such as UI, Functionality, etc. will be tested. Jot out what kind of UI aspects that will be covered.

For example: 1. Alignment of controls on the screen 2. Font, size and color. One thing is defining what is in the scope of testing but the other most important aspect is defining what is not in the scope of testing.

List it all out. Conduct reviews to be sure that everyone in the team – from the development to the stakeholders are made aware and convinced.

Measuring:

Estimation and sizing may be a phase by itself where care should be taken to allot enough time for planning.

Measure the product well before beginning. There are always chances of hidden layers and interacting interphases.

Even if there is experience in similar applications, start fresh every time. No two applications are the same.

There might be just a teeny difference but that may be the most important to consider.

Keep asking the question what the scope of testing is. The number of test cases may be the same but the complexity and time taken to design and execute them may vary based on the suite it falls under.

Analyzing:

What is the nature of the test to be written? Is it feature or regression? Is it a new functionality or a change request? These questions are very important before one starts penning down the test cases.

Remember, if it is a regression test case the scope itself changes. Leave behind the notion that once a new feature is live, the test cases written for this gets into the regression suite.

It simply does not work that way. Imagine the long set of test cases you will end up with at the end or releasing about ten features each with about two hundred cases written for the cause.

A long regression suite does not mean good coverage. Also consider the time you will have to run the suite every time. When it is a feature test case, the story is entirely different.

Even the smallest of the small should be covered. The key here is, do not combine validation of different functionality or controls however similar they may be.

The classic example of a login page may come up in any application’s discussion. Just because this is common, it does not mean it is working right for this current application under test.

So to stress here, test cases should be written for every field on even the most common functionality.

Understanding:

This is crucial. Assumptions are not to be encouraged. Do not hold back any question. Something that might be trivial to one may have the largest impact on the end user.

Several reviews should be conducted in the design phase to improve communication and to help work as a team towards the same expected goal.

Making sure:

Gather all possible information to make sure that there are no missing pieces. Do not leave any component unattended. Every detail should be made part of the pre-requisite.

A login credential may be the smallest piece of data but there are always chances of forgetting to ask for one.

You may have the application at hand to create several logins and roles, but do you have the super admin credential to login to create these roles? Go module by module thinking of the basics and ensure you have all that you need.

Practicing the above can help improve quality by increasing the test coverage, ensuring higher defect detection which boils down to saving cost on claims and damages.

Conclusion: 

There is no end to improvising. But is your base strong enough to handle the desired, improved output? The foundation has to be laid right to achieve this.

This statement is true not only for the various innovative discoveries but also for our various testing artifacts. Therefore to conclude, by starting off on the right note, you can be a sure hit!