Wholesale Banks, Agile & Quality

Wholesale Banks, Agile & Quality

In banking technology, many teams are using ‘Agile’ to get releases out to business quickly. Most Agile projects start small scale but, as experience & confidence are gained, (successful experiences in more online sides of the bank) it becomes the more mainstream mechanism.

Business sponsors engage iterative delivery & release far better from the project definition, throughout implementation to ongoing BAU. A downside is that it’s hard to say “no” to ad hoc changes and enhancements mid-Sprint as they come to mind of the business sponsors. This can cause re-prioritisation or the build-up of technical debt.

Has it always worked? No, but no project is guaranteed success, not to mention that definitions of success can be ambiguous! Including Test Automaton as a key part of ‘definition of done’ adds a lot of clarity in decisions on platform risk and ‘go live’ (as well as confidence building with each sprint).

Are robust project Agile controls always seen? Less so I’d say. ‘Heroes’ still save the day working overnight in the financial districts. Programmes with robust checks do really mitigate that situation.

The move to Agile delivery is not always synonymous with ‘baking-in’ quality from Sprint planning onwards. Again, culture change needs to evolve here.

The ultimate value of test automation derived from BDD is still in its infancy. It can be deemed as ‘not possible for us’ by those unaware of how BDD translates into test assets, and how under the UI technical testing gives a solid base for speedy delivery. Without across the board buy-in this can get tricky to deliver.

Many banks remain embedded with overly expensive, less Agile-aligned test automation tools that critically are not used by developers themselves. So, the ability to integrate development and test automation is at odds from the start.

The move to open source test automation tools has grown significantly, mostly due to the major license cost savings and highly mature capabilities on offer now. Just putting that first automated test into the CI is a key step that seems to get the ball rolling.

Certainly the move towards CI with predictable quality (and speedy business delivery) is reliant on technical testers and developers having interchangeable skills, using the aligned tools and fully respecting each other’s technical value.

The holy grail of ‘one team delivery’ is an evolution of experiences that raises the bar collectively. All that is required is an open mind.

QAWorks TeamWholesale Banks, Agile & Quality
read more
The Digital Government Revolution

The Digital Government Revolution

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?

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
Raising the profile of performance!

Raising the profile of performance!

Performance testing – typically the job of the Non Functional Test (NFT) team – should always be completed against a stable build of the system, in an environment that resembles the final production setting as closely as possible. Extensive functional testing is usually carried out beforehand, along with various other essential actions.

On paper the above looks fine and as expected, but by the time the system reaches the NFT team the underlying code has passed through various developers over many iterations. New code gets added to existing code and existing code is refactored, as different team members work their magic to create the system.

With the code receiving so much attention in the build up to performance testing, the NFT team has a hard time determining where any code-related performance issues originate.

The solution

If the above quandary is to be solved, projects must avoid vehemently segmenting each phase of a project. To reduce any wasted time in the performance testing phase, ‘performance profiling’ tests can be run during the functional test phase. Their purpose is to quickly identify any code-related performance issues. With performance profiling, a small number of virtual users is sufficient – say five or ten concurrent. These profiling tests should be run every time code is checked-in, making performance testing an essential part of the daily build process.

The key is to ensure these lightweight performance tests are run on a consistent and stable environment. Whilst this environment won’t resemble the final production architecture, it will quickly highlight any degradation in performance. Each test will be executed against the code in its most recent form, making it possible to highlight the root of the problem quickly. Once diagnosed, issues can be fixed and re-tested before the code is released to the NFT team for formal and extensive load testing.

A ten-step guide to performance profiling

The above form of lightweight performance testing can have a positive impact on the speed at which you can get a product to market. And by following the ten-step guide below, adopting such an approach doesn’t have to be difficult or costly.

  1. Source an environmentThis doesn’t necessarily have to be the production environment; it could even be the test environment, as long as it’s not being used when the profiling is conducted. It might be possible, for example, to complete the process out of normal office hours. Be sure to log the specification of the machine used, so that it forms part of your baseline setup.
  2. Choose a toolIdeally, this would be the same tool that’s used for full-scale performance testing (during the NFT phase) as the same scripts can be used but for much lower load, obviously. Otherwise, open source tools like JMeter and WebPageTest are excellent for both profiling and full-scale testing.
  3. Start earlyBehaviour-driven development and agile vertical slice development make it pretty easy to create some client-facing functionality relatively quickly. Once at this stage, it’s time to start writing the profile test – even if it’s just calling a simple GET against a web page. Simply put, the earlier you test, the earlier you find bugs.
  4. Run a base lineWith the script in place, you are ready to run a base line. Make sure you discuss the results with the team and business to ensure everything fits in with what was initially expected.
  5. Schedule your testsFor this, you can use a Continuous Integration (CI) server, or even a cron job. If you’re using Jenkins/JMeter, it’s worth using the JMeter plugin – this will not only run the tests but also report back some useful graphs. It makes sense to schedule these for every time new code is checked in.
  6. Monitor your resultsHooking your tests up to the CI can help with this – just be sure to implement some kind of threshold pass and failure conditions. This way, you can sound the alarm if the performance profile build goes ‘RED’.
  7. Learn from the improvementsIf it’s clear that the application is starting to perform better, determine the reasons for this and see if those improvements can be implemented elsewhere in the code. Negative changes should also be picked up on and investigated promptly.
  8. Maintain the testsWhenever more functionality is completed, adjust the tests accordingly. It’s also important to retire tests if they become obsolete. This should be treated like any other testing or development task.
  9. Monitor your systemMonitoring should be installed around all parts of the system, including the database, the webserver, CPU and memory usage. New Relic may come in handy here, or there are a number of open source tools on the market as well.
  10. Don’t forget the full load testThe goal of performance profiling is to make the process easier and more watertight – it’s not designed to replace full load testing. You should still stress/soak/load your application as normal.

Why introduce performance profiling?

When performance profiling is used as part of the daily build process, it becomes easier to instantly highlight any small performance issues early on in the process – long before it even reaches the NFT team. In turn, this means that developers are able to optimize and fine-tune the code as they go, ensuring the best possible results. It can be used to lighten the load on the NFT team, who will benefit from being able to focus on serious load, performance and stress tests to identify bottlenecks that aren’t necessarily code-related.

Performance profiling is definitely not a replacement for traditional load and performance testing, but its benefits as a complementary tactic are too significant to ignore. Implemented in the correct way, it will significantly cut overall costs, and help transform your releases into NFT from functionally good to operationally great.

QAWorks TeamRaising the profile of performance!
read more