Contingency

Contingency

No comments

As we become more comfortable with technology it is easy to forget how reliant we are on the systems that we use until something goes wrong. Before it’s too late we need to take a step back and analyse how important our data is to us and the likelihood of it disappearing off the face of the earth!

Recently I was in a car and drove past someone with two sat-navs. At first I thought it was over the top but then thought about the time that my sat-nav froze, nearly sending me completely past where I needed to go! This scenario shows the difference between myself making a short trip to the shop as opposed to the other driver with two sat-navs that potentially had a lot more riding on his trip. Contingency is about mitigating the impact or probability of an event by using what we know to prepare. Perhaps this is exactly what the other driver was doing.

There are many pains when working with systems, e.g. data becoming irretrievable once lost. However there are various methods that we can follow to reduce the chances of this happening.

We can begin with identifying the known issues and understand the probability and impact attached to them. The following example lists a few risks associated with the development of software using our best estimates about the probability and impact if the events were to occur.

Risk Description Probability Impact
Network loss Low Medium
Hard drive failure Low High
Late changes to requirements Significant Significant

 

This list should help us analyse and prioritise the most serious risks. To help us understand when we need to take action and reduce the risks we can use the below matrix:

Depending on which tile the risk lands on we need to take a different course of action.

If the risk lands on a ‘monitor’ tile then we need only observe the issue over time to ensure that the risk does not become of a higher importance. Risks landing on a ‘mitigation’ tile need to be dealt with based on their urgency by reducing the probability and/or impact to move the risk to a ‘monitor’ tile.

Looking at our above risks we can see that the ‘network loss’ risk lands in the ‘monitor’ zone. We can look back on this issue at the start of each sprint checking that the probability and/or impact has not increased. If the network has become more unreliable since the last check then we may have to look at alternative methods of connection such as a mobile dongle. As for the ‘hard drive failure’ risk we have landed on a ‘mitigation’ tile. Rather than monitoring this risk we need to look at ways to mitigate it. One way of doing this would be to backup any important files to reduce the impact or invest in a more reliable storage medium to reduce the probability. The same goes for ‘late changes to requirements’, we should look at incrementally developing the software so that we can monitor, plan and test more effectively.

The above matrix is aimed at changing your thinking towards risks so that you can plan ample contingency and ensure that known risks do not come to affect your work. It is not set in stone and can be adapted to fit your needs better. You may find that an ordered list of risks proves more useful. The important aspect here is keeping track of your risks and monitoring for change.

Example Mitigation Techniques

Below I have listed some common risks and their possible mitigation techniques, which you may encounter on a daily basis. These are not definitive answers but may highlight an area that you have not experienced issues with yet (let’s keep it that way!).

Risk Mitigation
Loss of source code Commit early and often using source control tools e.g. Git or SVN.
Loss of online form data Chrome plugin ‘Lazarus: Form Recovery’, useful when your browser freezes during an online application.
Loss of documents – e.g. text files containing credentials, useful data or notes Use one of the many file/password storage tools e.g. Dropbox, Google Drive, LastPass, Trello, Evernote
Absence of team member Knowledge share more often, cross train, daily updates, shared information stored on tools such as Trello or Google Docs
Unable to travel to work Ensure that you have access to your data from home e.g. whitelisting of home IP address, devices available to work on and methods to communicate with the team.
Unwell Ensure that another team member has access to your work and knowledge about your day to day tasks so that they can continue whilst you are away. It is also important to commit or share your work before you finish for the day.
Theft of device Ensure no credentials are stored on your device and check that your laptop is password protected, locking after 5 minutes of inactivity.

 

The list is far from exhaustive but hopefully sparks ideas for some of the risks that you come across.

It is important to ensure that what we do is reliable as it is not always possible to plan for all risks that may occur. However, we can prepare for the ones that we know about and by being more contingent in our actions, such as using two sat-navs, however stupid it may seem to others.

Sam HendriksenContingency
read more
The Digital Government Revolution

The Digital Government Revolution

No comments

Congratulations to the gov.uk Digital Marketplace for a world-leading transformation to modern, digital government with the publication of the latest version of G-Cloud.  Over 500 new suppliers have made themselves available to Government entities who can now work with 1852 of the best, most specialised organisations in the UK, helping them to get the right service to market more quickly and with outstanding quality.  Historically this was accessible only through a long, drawn-out tendering process.  Now, specialist suppliers (like us!) can demonstrate their unique ability to quickly provide innovative solutions, leading to more useful products and new features for the public.

We are pleased that the UK Government is going digital, bringing a range of services to mobile phones and tablets – saving us all from endless queues and paperwork!

One of our Agile Test Architects sent us the following email about gov.uk:

Hey Guys,

Check this out:

Go to: https://www.gov.uk/calculate-vehicle-tax-rates -> you’ll see a normal web page.

Now add the word ‘info’ before ‘calculate-vehicle-tax.rates’, i.e. https://www.gov.uk/info/calculate-vehicle-tax-rates – You’ll see the analytics for the page!

But, most importantly, they’ve turned the user story they’ve created for this web page into live documentation and associated it with the page.

The user need for this page:

As a vehicle owner

I need to find out how much it costs to tax my vehicle

So that I pay the right amount of vehicle tax

The next time they update the feature, the user story for this page will automatically change as well.

Quite cool isn’t it? 🙂

Clearly, gov.uk is already utilising Agile methods, seemingly Lean principles, and possibly the Behaviour Driven Development (BDD) process.

We have helped other organisations do the same and transform their development processes – dramatically increasing productivity and quality, whilst decreasing time to market.  We specialise in making our clients’ testing capabilities more lean and productive through the use of leading-edge tools and processes.

QAWorks is now on G-Cloud – check us out here

QAWorks TeamThe Digital Government Revolution
read more
Are Bugs in Production a Testers Fault?

Are Bugs in Production a Testers Fault?

No comments

Back in the day there was plenty of opportunity for a blame culture to exist in software development projects. Traditional methodologies encouraged rigid process, something along the lines of: develop, build and then finally, test. Inevitably, when following this process, milestones (in the lengthy project plan) were rarely met, meaning ‘slippage’ occurred at various stages, and activities, planned for the later phases of the project, were squeezed for time. This usually meant ‘testing’, so one of two outcomes would occur. Either the testers would have insufficient time to do a comprehensive job, or the go-live date would be delayed.

Typically this created an “us and them” culture between developers and testers, with each blaming problems on the other. In most cases, if bugs were found in production, the first question asked: ‘Was the testing effort sufficient?’. Crazy, we know, and crazier still is that these ‘traditional’ methods are still favoured by a large number of organisations!

An agile revolution

The agile development ecosystem sees developers, testers and the wider business work alongside one another as a single team, with common goals. Furthermore, the democratic approach of agile working sees the team come together to determine the acceptance criteria between them. This means everyone settles on achievable goals and timescales before the work begins. In short, developers know what to develop and testers are aware of what’s awaiting them. The benefit here is typically a vast reduction in defects.

To enshrine this acceptance criteria, the whole thing is written using common domain language and driven by user behaviours, so easily understood by all. Each development ‘task’ is only signed off as ‘done’ when the tester issues a pass.

And when test automation enters the agile process, a great many more tests can be executed. A fully automated regression test pack checks that nothing is broken in the new build, resulting in a much lower risk of new releases hitting the market with bugs present.

How to create an agile ‘Team Heaven’

All of the above may sound like something of a utopia to those still using traditional development methods; as realistically achievable as walking to the moon. By following the below guide, however, the concept of ‘Team Heaven’ could indeed become a reality.

  1. Let the code document itself storing requirements in multiple different systems promotes disparity. Why use a myriad of spreadsheets, logs, databases, feature files and notes, when the process can be made much smoother if everybody had access to a single repository. Move all relevant documentation into the code and serve it at a universal point wherever possible.
  2. Limit long meetingsEducation professionals have long maintained that we switch off much earlier than we sometimes expect. As such, any meetings that need to be undertaken should be done so around a desk, not in a closed meeting room, with strict agendas so only pressing matters regarding agile ceremonies and major design or development decisions are addressed. Communication is essential but anything more than this is unnecessary.
  3. Use the retrospective to improve your processDespite the above limitations, it’s worth ensuring that meetings leave all parties confident about progress and certain of where they stand. Make sure your team attend ‘retrospective’ sessions at the end of each phase of work. Everyone should feel comfortable and confident enough to have their say on matters. Understanding and collaboration should bring with it a clear view of what should be done to keep the process improving.
  4. Promote visibility and reviewsIn order to achieve the agile utopia, code visibility, code reviews, testing reviews and process reviews are essential and should be encouraged. This means people, from all across the project, need to take an interest in the disciplines and actions of their peers in different functions. A fresh pair of eyes may identify any issues before they arise.
  5. Encourage collaborationAgile working is a much more collaborative, sociable affair. The lines of communication between teams should always be open. Whether this is via wikis or Skype chat (as just two examples), all parties need to get visibility on the whole project. Create an environment where pair programming is possible. Allow one developer to code while the other observes, thinking up new ideas and pre-empting any potential future issues.
  6. Detect bugs earlier with Continuous IntegrationContinuous Integration (CI) is where team members regularly integrate their work, usually on a daily basis. With each integration automated tests are executed to verify the build. If an issue is detected, it’s obvious where to find it, as we know which part of the system was just changed. And the better the test automation, the easier and quicker it is to find the issue.
  7. Its really good to talkConverse the old fashioned way – in person! In today’s offices it’s easy to hear little more than the click-clack of keyboards as co-workers speak to one another online. In an agile environment, though, there’s much to be said for simply heading over to a colleague and talking about an issue or suggestion. This also enables those nearby to hear what’s going on and add their own thoughts or opinions. The last thing you want is for your office to sound more like a library!
  8. Make decisions as a teamNot all decisions need to go through every single person and fewer still will affect everyone. Despite this, it’s still worth ensuring visibility across all parties so, once again, nobody feels out of the loop. For example, your developers may wish to change one of their tools, or a process, for another that will enable them to work more effectively. There’s the argument that the wider team may not need to know this, but to leave them out of the loop may only cause problems later on. Instead, get everybody involved so that, if nothing else, there’s complete visibility.
  9. Don’t be afraid to start againHaving invested time, effort, money and a great deal of care into a project, ripping it up and starting again can feel like a wrench. Leaving a project too long before scrapping, however, can result in more wasted time, effort and money. Instead, use the opportunity for starting again to learn and improve. If things go wrong, it’s perfectly acceptable to head back to the drawing board to come up with something that will eventually be decidedly better than its first iteration.
  10. The team decides when a feature is completeEither the whole team determines when a feature can officially be deemed ‘complete’, or a coalition of representatives from the team (as long as the business, a developer and a tester is present). Each person on the project is given a right to reply before any decisions are made, providing an opportunity for everyone to review each others code, ensuring that the feature is bug free and we have all built the right thing.

So are bugs in production a tester’s fault?

As noted at the beginning, it’s safe to say that finding bugs in production was never a tester’s fault, even though traditional working setups allowed such beliefs to seep through. This was even the case when efforts were restricted, so any issues or concerns hadn’t been given the optimal time or consideration.

Now, in an agile environment, labeling bugs in production as being the fault of testers simply isn’t possible. First and foremost, agile working should result in much fewer bugs being found on production. In the case of such concerns or complaints, though, collaborative working means the whole team shares responsibility. This does mean, of course, that in the case of projects being a resounding success, the entire team can also share the plaudits.

Team Heaven indeed. If you’re transitioning to an agile methodology or have achieved team heaven, we’d love to hear your story!

QAWorks TeamAre Bugs in Production a Testers Fault?
read more