code

Manchester-based digital agency Intechnica were involved in the highly successful Hack Manchester event at the Museum of Science and Industry this past weekend. As sponsors, Intechnica provided a challenge plus prizes to those taking part, with Technical Director Andy Still judging and handing out brand new Raspberry Pi computers to the winners.

As well as proudly sponsoring the event, Intechnica fielded a team to bravely stay up through the night and hack together a working product in 24 hours.

The finished, working product was a word search generator game using an SMS API, where players could text in words to be hidden in the grid before opponents text the hidden words back to solve the puzzle.

Hopefully Hack Manchester will become an annual event, continuing to showcase the talent of all the great teams taking part. The dedication of the organisers, volunteers and teams taking part was fantastic.

See you at the next Hack Manchester!

It is often thought that Testing/Quality Assurance is just about finding defects – or as some people think – playing with the software and seeing what works and what doesn’t. As usual the reality is a lot more involved. The finding of defects is only one aspect of what QA does. When preparing a test approach you need to ask some fundamental questions that appear to have obvious answers, but when you think about them a bit more – you are not so sure.

How much testing needs to be carried out before the application is ready to deploy?
What quantity of defects found in a test phase demonstrates that the application meets customers’ acceptance criteria?
What business activities need to be evaluated to prove that the application will be able to carry out business tasks as required?

The third question is actually the key. Any project will have a set of opportunities or a capability that a business needs. They will measure the benefits of employing people to create code and time to deliver the project by the value benefits these capabilities add to the profits of the company. This could be from consolidating a number of accounting systems, being able to sell via an electronic market place a new service or being able to manage more effectively the routes that delivery drivers take to deliver stock. All add value to the bottom line. To achieve this the project has to be very clear about what new software or changes to existing applications in a language which there can be no ambiguity. Working with the developers, Quality Assurance exercise the software and measure whether the code meets these needs. And this is done through looking at the behaviour of the application rather than trying to take apart all the constituent parts. Because specification-by-example builds testing into the development process – the lower level code modules will be tested and validated with the requirements. So low level noise (syntax errors, validation errors etc.) shouldn’t be present. So the QA focus when using the application will look at validating the user-stories and from that examining the requirements. So how many defects found in a test phase mean that the software is acceptable for use? The key measure used by QA is to look at the spread of defects by functional area. Traditionally these areas will have been mapped in the early part of the project via a traceability document. This document measures the business criticality and complexity of the requirements and relates that to use stories on how the new functionality will be used. The challenge is going to be that in an Agile context, making it lightweight enough so that enough information is provided but it doesn’t take a long time to produce. The drivers behind the Agile methodology emphasise only doing those tasks that are necessary – to drive the release forward and understanding what tasks need to be done on the critical path to deliver a release. Traditionally the readiness of an application for service was proved by the level of defects seen in each functional area. Traditional QA activities come from a waterfall past where specific quality gates must be achieved and everything moves in slow sequence. In the new methodology it is necessary to only do the minimum amount of testing that proves that project requirements can be met and that the application will perform provide a reliable and effective level of service. Without the old techniques of testing all parts of the application the focus moves to testing those areas that are critical to the purpose of the change and support the business capability being delivered. So it is possible to use the old technique but it is necessary to put it in a new context making the process lighter and more flexible. This is just the start of some big changes in software development methodologies. When defects are seen they will have much higher impact and could have slipped unnoticed through a regression change or integration point where two modules have been brought together for the first time. The new processes will need to give this information context so that critical issues are fixed quickly without impacting overall delivery times. Testing will focus more on end-to-end process flows (business stories) and less on small components such as data validation and software branch variation. This will not mean that the testing won’t be done, but it will be done at an earlier point. This is only one area where “Specification by Example” will make subtle – but fundamental changes to application delivery. Important Agile behaviours such as “fix-first-time” – “active collaboration” will need to be enforced to drive through quality. But old measures such as defect latency, burn rate on feature delivery and making decisions on what will be a realistic time for launch of the application are going to be equally important. These are going to be exciting times for project methodologies and it will be interesting to see where we are in 6 months time.