SOGETI UK BLOG

DetectiveTesters are detectives. Often I spend a lot of time investigating how a certain software programme that needs adaptation can be tested. Some issues are:

– The system is not documented well and people don’t seem to be sure how the system is built-up and where the changes are needed exactly.

– The system is a giant black box of which the output does not always tell us much about whether the internal behaviour is as required.

– The software interacts with other systems, but it is a mystery whether that interaction can happen in the same way in the test environment or what is needed for it to work, theoretically.

In those cases, test execution often turns out to be hard, error-prone, and slow – even for small programme changes.

In any project approach you take, testability of the software that is being created or amended is a decisive factor in the time and cost of testing. When the required effort is deemed too much and management decides to drop (part of) testing it brings risk and a potential loss of quality/ a lack of confidence in the product.

However, testing is not a one-time activity as software is a living thing that constantly needs to catch up with its users’ demands. Therefore testing is something that needs to be done throughout the life span of the software whenever changes are made to it – and I promise you there will be changes.

Investing in the testability of a system gives return over its entire life span and TMap® recognises this value; it lists testability as a quality characteristic of a software system, alongside all-time classics like functionality, security, and performance.

There are a number of measures that can be taken to improve the testability of a system:

Improve transparency about what the system does and what it is supposed to do:

  • Keep updated system documentation
  • Write readable, well-structured code
  • Have a solid test basis (clear software requirements)

Use technologies and write code by which parts of the system can be tested in isolation:

  • Maintain a proper separation of concerns
  • Allow interim results of the system to be made visible, assessed, and even manipulated

Set up a full-fledged test environment:

  • Find the right balance between representativeness and flexibility (e.g. adjustable system date for purposes of time travel)
  • Opt for technologies in which tests can easily be automated

These measures may not be the first thing on the mind of any project manager, but they sure make the work of both developers and testers a lot easier and more effective; especially in the longer term – enabling to build in better quality while generally reducing the software’s total cost of ownership at the same time.

To read the original post and add comments, please visit the SogetiLabs blog: TESTABILITY MATTERS

Related Posts:

  1. Is it a good idea solving test environment problems “later”?
  2. Playing the blame game
  3. Create a safety net, not a hammock!
  4. Use Scrum and halve the test department!

 

 

AUTHOR:
Wannes Lauwers has been working with Sogeti since 2012 as a versatile software testing professional who manages to bridge the gap between business and IT in a variety of industries thanks to his broad interests and educational background in business administration. With his process mindset, Wannes is committed to deliver long term solutions well aligned with business needs, thus guiding companies’ convergence of business and IT into true business technology.

Posted in: A testers viewpoint, Developers, Managed Testing Services, Opinion, Requirements, Software testing, Test Environment Management, TMap, Usability Testing, Working in software testing      
Comments: 0
Tags: , , , , , , , , , , , ,

 

Faced with stories of new technologies and innovations, companies often make one of these two mistakes, either:

– Organisations feel they don’t need to know more about the technolgy or innovation andare convinced and determined to start implementing a radically new way of working immediately. Perhaps overly ambitious, they want to jump but forget that they risk falling.

– Organisations (the majorityof them) applaud the innovator but, as far as their own firm is concerned, think that the advantages that can be seen from implementing the innovation don’t apply to them and they anticipate too much trouble implementing them. They keep doing business as they used to. They stand still.

It is hard to say which is worse; the truth is that both attitudes can kill your business.

Even though innovation may sound like something sudden and disruptive, and is often marketed as such, the best implementation strategy is a gradual one. What distinguishes sustainable, truly innovative companies is that they manage to cycle through that gradualness at a very fast pace, without jumping from one innovation to the other. (There may have been some unsustainable companies like the latter though.)

As is common in life, you have to find the middle ground. You may feel uncomfortable jumping, but you really don’t want to be standing still. So it is important that you continually find ways to move ahead, step by step. So feel inspired by stories of innovation and look for steps to take in your organisation. They don’t necessarily need to “change the game” or “cause a sudden turnaround” overnight; they just need to keep the company moving forward.

Much of finding that middle groundcan be achieved through self-reflection. Ask yourself not only: Which innovations could be of the most advantageous for my firm in the short and long term? But also: At which maturity level are we now? What are the right steps right now and what are the right next steps for tomorrow?

To answer these questions, it helps to discuss your thoughts with co-workers, friends from other firms, people from Sogeti. Once you begin this exercise, you are already setting things in motion to bring about innovation in your firm. Because innovation is often exactly that: rethinking known ways to apply in different contexts. So, whenever you hear the great story about innovation, or you are reading an inspiring blog post, think what it could mean for you and how it could improve your business, step by step.

AUTHOR:
Wannes Lauwers has been working with Sogeti since 2012 as a versatile software testing professional who manages to bridge the gap between business and IT in a variety of industries thanks to his broad interests and educational background in business administration. With his process mindset, Wannes is committed to deliver long term solutions well aligned with business needs, thus guiding companies’ convergence of business and IT into true business technology.

Posted in: Collaboration, communication, Digital strategy, Innovation, SogetiLabs      
Comments: 0
Tags: , , , , , , , , , , ,

 

GreenFieldA quick look over this planet will tell you that people like making things. We like to conceive and create new things. Yes, preferably new things. In this overpopulated world with a lot of occupied space and established knowledge, there are often old things standing in the way of creating something new. That can be frustrating because don’t we all think it’s more fun to set the first steps in an untouched white carpet of snow rather than see if we can make something nice out of someone else’s junk?

Although recycling finally has become daily business in many industries, with its relatively new technologies, IT professionals have had the privilege of being creators-only for quite a while. And like most creators, they usually prefer working on greenfield projects over working on brownfield projects.

That’s how sometimes a case is made to replace (part of) a system, instead of upgrading it: the analyst is of the opinion that it would be better to rewrite the whole program to make it fit today’s functional and technical requirements.

There can be a mismatch between personal beliefs or preferences and the company’s economic best interests here. The old system’s business case probably also once promised a long-term solution, providing added value over the entire length of its life, but when a trusted technical expert says that it would be more economical to replace the system, the business manager is inclined to accept a sunk cost.

It is important to note that the technical expert is not using their expertise in bad faith:

– ICT is still developing rapidly, so software can quickly be labeled “outdated” from a technical point of view.

– It can be hard to predict the effort that will be needed to completely understand the system and the effect of any changes on it, especially when software is badly documented, or not entirely standardized.

IT projects are often built as greenfield, from-scratch projects. Developers build solutions that fill the need at the moment, but the technological and functional factors in the environment may change, which in turn changes the requirements. When requirements keep changing (and they usually do), computer applications seem to do a bad job “changing” in the long term.  What appear to be small changes often require a lot of work throughout the software. This is in contrast with the fact that it is “soft” ware. It is again important to note that this is not the developer’s fault. Even if s/he anticipates certain changes or builds in options for extensions/features – contrary to modern principles like the Minimum Viable Product and You Ain’t Gonna Need It – systems would gain complexity as they are changed until upgrading is no longer justified and a new from-scratch project is started.

So, there is a real problem with software evolvability. And it is a challenge for IT professionals today to work on a solution for it. In my opinion, much of the solution to this problem needs to be achieved in software design. What is needed is a structural solution which does not put pressure on other resources and therefore ought to be independent of the developer herself. Programmers today still make a lot of decisions themselves about the structuring of code. But maybe they shouldn’t. If you rely on developers to implement the right structure, you are putting pressure on a scarce resource: not all companies will be able to attract the finest developers who are at the same time code monkeys, business analysts, quality managers, and architects. Because, yes, we do expect our modern developers to be all that. Following an implemented standard, however, works well for all-round developers, as in developers who are not great architects but prove their value in other aspects. It should even be possible to industrialize and automate parts of the coding process (cf. model driven architecture for example). Another advantage of adhering to a well-documented standard is that code is more likely to be self-explanatory, so less specific documentation needs to be produced.

The very large amount of modules only adds relative complexity since all modules have a standardized format. The software design standard we are looking for should probably show a high degree of service orientation, i.e. consisting of self-contained, loosely coupled units of functionality. Its structure should be sufficiently modular, granular even, to guarantee a proper separation of concerns. The final goal is to arrive at a situation where 1 change in requirements is equal to 1 change in software – whereas we see today that 1 change in some module requires a lot of changes elsewhere.

There are design methods around which are focused on achieving exactly that and which are already more tangible than being mere theories. For example, Sogeti Belgium is involved in an R&D project with the University of Antwerp to put the theory behind normalized systems into practice, and it is getting some promising results. Hopefully, I might be able to write some more about it in a future blog post.

There is a big downside, however, to software design being the solution to the problem of software evolvability: it is so the core of the software that implementing it implies that most of the system would probably need to be rebuilt from scratch. On the other hand, the point of this post was that your software will arrive at that point anyway due to its increasing complexity.

Before implementing a new software design, a necessary first step might be for businesses to reconsider their mindset about software development. Taking “service orientation” to a higher level, businesses should consider moving away from having software delivered as a product, but instead think of the IT department as continuously delivering services which are consistently in line with business needs. This means stop differentiating between a build phase and a maintenance phase for software, but instead come up with KPIs assessing the delivered services throughout the software’s life span, from the moment you start building it.

As a final note: ideally, the solution to the problem of software evolvability does not take away the human pleasure of creating but focuses on taking away the annoying tasks of scanning and refactoring code. Let’s make developing software a process of continuous creation. Impossible? I don’t think so. And what do you think?

AUTHOR:
Wannes Lauwers has been working with Sogeti since 2012 as a versatile software testing professional who manages to bridge the gap between business and IT in a variety of industries thanks to his broad interests and educational background in business administration. With his process mindset, Wannes is committed to deliver long term solutions well aligned with business needs, thus guiding companies’ convergence of business and IT into true business technology.

Posted in: Research, Software Development, SogetiLabs, Technology Outlook      
Comments: 0
Tags: , , , , , , , , , , , , , , , , , , , ,