SMART Requirements for Smart Testing

There are a lot of software application development models that have emerged in response to the need to reduce software delivery times to end customers. Some of the popular ones include Waterfall, Agile, Test-Driven Development (TDD), Behavior-Driven Development (BDD), Rapid Application Development (RAD), the Spiral Model, Feature-Driven Development (FDD), and Rational Unified Process. All of these models help in dampening the investment and making a faster profit.

One of the effects of developments in development models is the decline of traditionally-written specifications and their definition in a simplified form. In this context, it is imperative to have a new concept of the specification that fully saturates this need.

SMART Requirements are those sets of documentation, written in natural language, that can be automatically interpreted, tested and validated without any human intervention.

This way, the entire suite of processes – from writing specifications, defining tests, and automating to their execution – would be reduced to merely defining specifications via SMART Requirements, which ultimately translates into lowering the time required to deliver software to end users.


Why is there not a quasi-perfect development model that can be applied by all companies that develop software?


Because each company has implemented its own more or less standardized process tailored to its needs, and the implementation of a model that is adaptable in all situations for all types of software applications has proven empirically to be an unrealistic approach.

Companies that develop software, like any other company, have the ultimate goal of generating revenue for their investors. As this market segment proved to be profitable, investors naturally tend to “increase production” to speed up the delivery of products to increase profits.

To cope with the pressure of shortening delivery times, companies and software communities have begun to translate their approach models and develop new processes, methods, and means that meet the demands of efficiency and speed experienced by investors.

How did we get here?

In terms of software production, we have witnessed a direction focused on improving processes and adapting them to the profile of each company and the type of product they develop. These investments bring about better productivity, independent of the industries they are being applied to. Even if they prove to be good in the short term, they are also perfect in the medium and long term, demonstrating enough hotspot points.

Over the past two decades, in the world of software development we have witnessed an almost brutal conversion of development models, and the added value that investment in the development of new processes can still deliver is rather limited.

Productivity efficiency can still be achieved, but attention and effort should be directed to optimizing other components of the software product development cycle. Two of these – costly but indispensable to software development – are product specifications and quality assurance.

Paradigms such as ‘full specifications’ or ‘exhaustive testing’ have become taboo subjects. We often find situations in which the specifications in their classical approach are incomplete or ambiguous, thus interpretable to all actors involved in the development of the finished product. The heath of what the client wants, what the analyst understands, what is being implemented, and how or what is being tested has become a common problem. The later the discrepancies are observed, the more expensive they become.

Three or four elements? Interpretable. It depends on perspective.

Interpretative specifications generate interference in communication and introduce performance discordance across all actors involved in the development process.

The picture above is a plastic example of incomplete specifications.

A significant percentage of resources at the project level are allocated, on the one hand, to the definition of specifications at a generally accepted level to start development and, on the other hand, to testing and validating the application to be delivered to final customers.

An investment that is increasingly present and accepted by IT investors is the one in testing automation. If the ‘SMART Testing’ paradigm has been spoken of in the literature on software testing and validation, why not advance this ‘SMART’ concept and specifications and, moreover, adopt a connection in a direct relationship between specification definition and automated testing, i.e., SMART Requirements?

Arguments and Reasoning

A unique, automated interface used both to define and validate specifications and automate product testing that can automatically “understand,” test and validate sets of specifications that come directly from the customer (or requirement engineer, project owner, etc.) is one of the ways we can shorten delivery times. The specifications would still be written in a natural, non-technical language but would implement a set of clear rules that will be syntactically and logically validated at the automation interface. The same interface will generate automated test scripts, accurately reflecting the specification requirements and validating the software by executing tests on developed modules.

This flow, executed without the need for human intervention, would have a significant impact in reducing software production time. It would reduce the time required to write the specifications, and would, on the other hand, eliminate the discordance between those who define or modify specifications and the rest of the actors involved in the production process.

Define the Specifications with Keywords

A solution used in the design of automated tests using keywords is the model “Precondition – Action – Result” or “Given – When – Then” (GWT). This solution can be extended and applied directly to the specification phase, thus facilitating the creation of automated tests that will strictly reflect the requirements imposed by these specifications.

We consider the following as an example of the different approach to defining specifications:

  • Classic approach – When the user visits the application, the login page is displayed. Once authenticated, the user is directed to the home page.
  • GWT approach – via SMART Requirements
    • Given – the access app
    • When – the login page displayed and the login button clicked
    • Then – the home page displayed
    • Given, When, Then, And – logical operators used by the automation interface to define the specifications and automated tests derived from them

The access application, the login page, click the login button, the home page displayed – are the keywords being used, on one hand for writing the specifications, and on the other for defining the automated tests? These keywords match and implement the automated scripts necessary to create tests that will verify and validate the actions described in the specifications.

In this way, the specifications become test cases or vice versa.

The advantage of having correctly defined specifications and executable tests automatically derived from them is one that deserves an initial investment in an interface of this kind. And the fact that there are already communities and software packages that address these issues (e.g. Cucumber) makes the effort to implement this solution profitable and the return on the initial investment can be reached quickly.

Moreover, this interface could be used not only to implement functional and nonfunctional automated black-box tests but also to generate white box tests or to create complex test scenarios based on both product specifications and user experience with the product.

All actors involved in product testing, including user acceptance or beta-testing phases, can create their tests using the SMART Requirements model, thus adding value to the general regression suite of the final product.


Clear specifications and quality assurance are two artifacts that are part of the software development lifecycle where compromises should never be made.

In the classical approach, finalizing the specifications was a costly process that slowed development and extended the delivery time of the product to the end customers. Another expensive side of the classic approach are those inflection points generated by any change in specifications that required, as a direct consequence, the modification of related tests, whether automated or manual.

By introducing specific frameworks to implement SMART Requirements, we can re-generate test scripts so that they adequately reflect any changes to the specifications. Automatic. No additional costs. No compromises.

Spread the Word

If you liked what you read in this post, please help us spread the word about it via the Click to Tweet feature below or the social sharing icons at the bottom of the post.

Why use SMART requirements for Smart Testing? You'll deliver higher quality code to production more reliably and for cheaper. Read more in this blog post from Narcis Oancea. Click To Tweet

This post was originally published in the 64th edition of Today Software Magazine.

Narcis Oancea

Narcis Oancea

Technical Manager

Narcis Oancea is a Technical Manager in 3Pillar’s Timisoara office. He has over 4 years of quality assurance experience and specializes in Java, SQL, and agile methodologies. Prior to working at 3Pillar, Narcis was the Manager of Quality Engineering at ACI Worldwide. He has a Bachelors of Engineering from Universitatea Politehnica din Timișoara.

One Response to “SMART Requirements for Smart Testing”
  1. abcya on

    I read some articles on this site and I think your blog is really interesting and has great information. Thank you for your sharing.

Leave a Reply