SMART is often the buzz word in setting objectives and goals for an individual and an organization. The goals need to be Specific, Measurable, Achievable, Relevant and Time-based. While this holds good for any goal in general, what test case designers can adapt is that architecting test cases is an important goal in a test project and here is how we could derive from SMART tactic for test case design, to make the tasks following it to be simpler.

Specific:
While different levels of testing are done at various stages of SDLC, writing test cases that are generic as well as specific would help. Few tools like HP ALM has Parameters can replace only those specifics and avoid redundancy. For instance when the same test is being performed for different environment like Web and Mobile, having Parameterization for environment would save us time rather than repeating the steps for web as well as mobile separately. Most of the projects also suffer from redundant testing. This causes few areas to go untested at the end. Primary reason being that test cases are not modularized. Easier example would be the pre-requisites which are being redundantly performed for many functionalities.

Measurable:
In most of the projects, test coverage mapping the test cases with requirements is incomplete. Test managers are left in a maze when asked to derive a quantitative metric on the coverage for the test cases. The tests need to achieve complete traceability. Preparing a matrix serves the dual purpose of not only seeing that tests are run for the requirements, but also to verify that the tests are not repeated by having multiple test scenarios that have the same set of steps. Mapping the requirements would ease the task of checking the tasks in hand quantitatively.

Achievable:
Testability is often underestimated. For example having performance related test cases, which is easier to execute during system testing phase could have crept into integration test cases. Though these could be executed during integration testing phase, they do not really help in the quality improvement. Mapping the test strategy with the test case needs to be a ongoing activity.

Relevant:
The world is working towards getting rid of the excessive fat both in the human body and in the project documentation. Both of the reductions require planned shed out. Lean test cases are the need of the hour.
While we would work on the coverage of all the functionalities, one might tend to add on more to the test cases than what is relevant to the work packet. This not only burdens the test case designer in adding more documentation to the artifact, but also the tester while executing in knowing which to prioritize.
Refactoring of test cases need to be done quite often as much as code is being refactored by development team. Taking out the irrelevant steps and test cases should be part of the scheduling activity in the test plan. Mindmaps could be a great way to achieve the relevancy.

Time bound:
Almost all the projects, irrespective of the SDLC model they work on, are time bound. Since agile projects are sprint based with each lasting for a couple of weeks, the test documentation which includes writing of test cases take in majority of the time. Having schedules so as to not swell up the activity pile and monitoring the progress needs to be planned in advance. Having an estimated time for execution and recording the time taken during actual execution will help in quantifying the time required for execution.
Combining these, a SMART test case design could look like this.

Phase 1: Scenario Mapping
Create a mapping scenario to each of the functionality specified in the requirement documentation. These functionalities could be user stories in case of agile environment.
Smart_Test_Case_MithunSR

As seen in the above example, let not the detailing of test cases come in the initial phase. Devote this step to come up with scenarios to be tested with. Also prioritize the test scenarios from a tester’s perspective.

Phase 2: Review and reprioritization

It is much easier to review such a document that could be viewed in a page than the one which runs into a book. Involve the stake holders, both internal and external, which includes but not limited to testers, developers, requirement analyst/Product owner, customers, test manager, architects, etc. Walkthroughs seems to be an effective option than having an offline review since the views could be easily exchanged and the author can accept or reject suggested changes immediately while the entire team is aware of the end goal. Reprioritization of tests could happen based on feedback from stakeholders.

Phase 3: Elaborate and Parameterize
Elaborate the test procedures and parameterize for any redundant specifics like environment, devices to run, etc. Since the review of scenarios is already complete, a quick 4 eye review would suffice for baselining the test cases.

Phase 4: Refactoring
Trim those unessential and obsolete from the test cases more often. Having this as an ongoing activity will keep the test cases fresh and lean. Also refactoring based on the priority of test cases and adding new tests based on defects would help devise a plan for regression test and help in avoiding tests being different from what is being executed.

The world is moving towards SMART. How SMART are your test cases?

https://i0.wp.com/www.testingcircus.com/wp-content/uploads/Smart_test_case_design.jpg?fit=473%2C337&ssl=1https://i0.wp.com/www.testingcircus.com/wp-content/uploads/Smart_test_case_design.jpg?resize=150%2C150&ssl=1Mithun Kumar S RArticlesTest Case DesignSMART is often the buzz word in setting objectives and goals for an individual and an organization. The goals need to be Specific, Measurable, Achievable, Relevant and Time-based. While this holds good for any goal in general, what test case designers can adapt is that architecting test cases is...