Bringing Testability into Focus

Anand Kumar Keshavan ( Founder/Partner- SwanSpeed Consulting)

 Amongst the many "non-functional" attributes of software - scalability, availability, extensibility and so on- testability remains the one that is most difficult to grasp. Scalability can be tested by using appropriate tools. Availability can be measured by plotting downtime statistics. How does one "test" for testability?

Intuitively, testability of a piece of code or a large software system defines its ability to be tested in some kind of repeatable way by a group of humans or by other programs within a reasonable/ predictable period of time.

While testability may be vague and hard to define, lack of testability throws up a lot of symptoms. Here are few of them:


  • Release cycles are unpredictable- from the time a set of features have been declared to be "done" by developers to the time such features are deployed. This "last mile" problem has existed for non-trivial software, irrespective of the tools used or processes followed, since the earliest systems came into being.
  • Fixing of one set of defects ( or modifying the behaviour of a feature) resulting in hitherto unknown defects showing up in other parts of the software.
  • Frustration shown by the business stakeholders at the amount of time and cost required to add, what appear to be, trivial features or modifications
  • Developers and project managers blaming testers of not being able to find bugs that are subsequently found by users in production. (In general terms, it is the developers who are responsible for every error in the software-- blaming testers for not finding bugs is just plain silly. As Djikstra said "Testing shows the presence, not the absence, of bugs". That is one of the foundational principles of computer science. But that is a topic for another day.)
  • Too much time to add a new programmer to the team. Steep learning curves, build failures- the usual stuff
The reasons for poor testability are be many:


  • Not enough time spent in defining the architecture. In the recent years, even very complex systems are being built using the "build and refactor" model without laying an adequate foundation. Such models usually end up accumulating a lot of technical debt as feature addition takes precedence over everything else. "Techincal debt", like any other debt, grows at a compounding rate!
  • Choice of programming languages and technology stacks- dynamically typed languages can produce systems that can quickly deteriorate into a practically untestable nightmarish situation, if best practices are not defined and followed maniacally by every member of the team.
  • Dissonance between the complexity of software in terms and the level of abstraction used to define and build it. For example, if custom behaviour is implemented using hard coded conditions ( instead of behavioural abstractions), then one is doomed! ( My earlier article, Building a Software Platform, touches upon this.
  • Concurrency ( this is my personal favourite- poorly conceived concurrency almost always results in poor testability)- with many micro services based systems acquiring the characteristics of concurrent systems this problem is becoming more mainstream.
The bad news is the once you build a system ( any non-trivial software with many moving parts-- not your regular apps and websites) without built-in "testability" , it is a hard , if not impossible, to bring it in later. In theory, it is possible to do so by successive refactoring over a period of time. In practice, I have not seen a single instance where this has been done. As more features get added, more and more parts of the system become "untestable" and the refactoring effort always lags behind. ( This is similar to adding test automation very late in the lifecycle of a project-- the automation suite always lags behind the software feature set!)

Poor testability also has a cascading impact on other "abilities"- "reliability" and "extensibility". ( and may be availability- if run-time errors result in crashes)

So what is the solution? Alas, there is no simple one. The solution, if any, lies in bringing in a level of rigour into all aspects of your software development-- choice of technologies, solution architectures, coding conventions ( not stylistic -- but conventions based on which patterns to use, which ones to avoid) and so on.

(The author is a programmer and a founder/partner in SwanSpeed Consulting and a Director in Codewalla .

SwanSpeed Consulting  can help you in architecting robust software for a high degree of testability, scalability and maintainability.

Codewalla is a boutique software development company that specialises in building SAAS software products.)



Comments

Post a Comment

Popular posts from this blog

Model correctly and write less code, using Akka Streams

Image
One of my most productive days was throwing away 1000 lines of code. -- Ken Thompson More than two decades of writing software programs to earn some humble money and to keep the home hearth warm, has taught me that writing simple, elegant and readable programs result in much more maintainable and extensible software. Importantly, stakeholders prefer to have maintainable code. One way to ensure that  these properties exist in the code, is to write fewer lines of code , wherever possible. Generations of greats in the world of computer science and programming have been reminding us about this little yet undeniable truth. Yet, it is surprising how often we tend to ignore this, knowingly and to projects’ detriment. If we have to write programs that are simple to understand, we have to understand the problem well, before anything else. If the problem is redefined in simpler and more fundamental terms, then it becomes easier to model the problem in the programming terms. The so
Read more

Your Microservices are asynchronous. Your approach to testing has to change!

Image
Conceptually, the idea of an application being composed of a number of MicroServices is quite self-evident and therefore, quite appealing. A complex solution, which is broken into a number of self-sufficient modules, each running on its own, each capable of responding to messages, each amenable of upgradation/replacement without letting any other know about: sounds too good to be true! The icing on the cake of course, is that each such service can run on its own containers! No wonder then, that senior stakeholders of software projects or initiatives, love to insist that the application be modelled as a bunch of MicroServices. The technology team responds favourably, of course, because everyone wants to be seen among the pack, if not ahead of the pack! Jumping in sounds exciting, even though the swimming may not be, but we don’t really care, do we? The proverbial devil is in the details. In my experience so far, the term Microservice is thrown about without much thought. T
Read more

Building a "Platform"?

Image
Anand Kumar Keshavan  ( Founder/Partner- SwanSpeed Consulting ) In recent times, many of our clients have expressed interest in building platforms. But what is a “platform” exactly? How is it different from your regular business applications? What are the challenges that one is likely to face when one attempts to build platforms? We note that this wish to build platforms often overlooks the challenges and possibilities of business success. We have to recognise these challenges to be mentally prepared to take up such an endeavour. So, for most of us, our common day to day experience conditions us to develop applications, and this deflects our attention aways from the crucial aspects in building a successful platform. Before answering these questions let us look at software in general. One may tend to view all software as similar. What is there after all? Write some code, test it, and roll out , right? In reality “software” comes in vastly varying classes of behaviours. For
Read more