Head & Tail of IT solution development

We all know that, during the past 30 years, the software engineering sector has witnessed a lot of disrupting innovations: programming languages, virtual environments, architectures, IDE, databases engines, automated testing tools, etc.

Moreover, the all those advantages have been hugely amplified by the widespread availability of powerful processing power and cheap RAM, so that every PC is now a fully-featured workstation as we, young programmers and software architects of the '80s and '90s, could never afford.

Eventually, the pervasive sharing of knowledge and artifacts allowed by enabling technologies like the Internet and its services have determined a much more distributed yet integrated development environment, where the result is greater than the sum of the individual values.

Parallel to those innovations, the software development process itself was revolutionized: UML, Agile, TDD, DevOps, just to name a few of them, have greatly improved the efficiency of the process and the quality potentially delivered to the customer.

What was an art, "The Art of Computer Programming" [Donald E. Knuth, 1968], is now a pretty structured and industrial process of clever reuse of building blocks and glue logic, that lead to more sophisticated results in much lesser time.

But if the software building process is now much more robust, supported, guided and straightforward, there are still two fundamental stages of the development which retains the "art" characteristic: the head (Requirement Engineering, RE) and the tail (Test and Acceptance, T&A), as they are still very depending on the human factor.

Both RE as T&A are still, after more than half a century, the critical phases that determine if, irrespective of how much effort was injected in a project, the development will deliver a unexpected (bad requirement engineering) or weak (superficial or incomplete testing) result to the customer.

Requirements engineering is the process of gathering and defining specifications of what the services should be provided by the system, convert those specifications into a standard description useful for the subsequent validation by the customer and for the following analysis phase.

This process includes the documentation of the expected behavior of the system in all its components and by every possible user's and external system's view. It benefits from the availability of best practices, industrial standards (such as UML) and Upper CASE tools.

Even if there is now such amount of support, Requirements Engineering still relies a lot of the human capability of capturing the essential features required by the business, drill down to greater details without losing the main focus and documenting everything in such a way that it is complete, coherent, non-ambiguous, non-confusing, clear enough to be shared with and validated by the customer without misunderstandings. In this sense, RE is essentially still an Art.

Test & Acceptance is a much more industrialized process than RE, but there is also here a good percentage of human factor on which the final result will depend. This is due to the correct and complete identification of the Test Scenarios and relevant Test Cases, which will in turn translated into formal Test Scripts, and whose execution will assess if and how much the system is (a) working in the different input conditions and (b) implementing a correct behavior.

A Test Management platform is mandatory to support the design and the later execution of tests.

Too often the process of preparation of the User Acceptance Tests, to be executed during T&A, starts at a later time during the project life-cycle, when there is no more room to design high-quality Scenarios and Tests. A poor T&A design will result in a defective Quality Control process, with high risks to either releasing a buggy or non-conformant system or to delay the system start-up.

How can this risk mitigated or even removed from the project? The answer is in anticipating the UAT design process, which should ideally start as soon as the final requirements are validated. If the project is divided into different developments, each with a set of requirements, the UAT process can follow the same breakdown structure and start as soon as each RE phase is completed.

How can be reduced the risk of poor Test Scenario identification? Only on behalf of a rigorous RE process. If, for example, UML is the preferred way of documenting the system requirements, than the collection of User Scenarios shall be a good baseline to develop Test Scenarios and produce high quality Test Scripts which, thanks to the available time, will be well documented.

For a deeper view of a possible structured UAT design model, please take a look to my UAT Toolkit slides [in Italian].