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
Wholesale Banks, Agile & Quality

Wholesale Banks, Agile & Quality

No comments

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
Effective Communication in Agile

Effective Communication in Agile

No comments

One of the principles behind Agile work methods is that ‘business people and developers must work together daily throughout the project.’ Even with agile methods in place this is not always as straightforward as it seems. This article looks at some of the key areas for improvement when it comes to communication between highly technical people and stakeholders.

There is no doubt that technical people are the ones that turn ideas into reality. Whether you’re an artisan programmer, an innovative DevOps engineer or an automation testing genius, we all make it happen.

But we also have project managers to answer to. They’re the ones who keep us on track and are keenly interested in making sure we build the right thing on time and on budget. While you may be technically proficient, many applicants have been denied a job offer because they lack the ability to communicate effectively to their managers and other stakeholders.

The reality is that when you’re in a large-scale project, silo working is not only unlikely but undesirable as it can lead to ivory towers being built which later on incurs rework costs.

So how can we communicate effectively to stakeholders and instil confidence in them?

From my own experience here’s some things I’ve picked up.

Listen

One of the major benefits of Agile methodologies is to encourage synergy between team members which is impossible without good listening skills. This seems like a really obvious thing to do but you’d be surprised how little people work on this skill and how often a question is misinterpreted.

A manager can ask a question like “how many web pages have been completed so far?” The developer then responds by talking about content issues, javascript bugs, browser compatibility etc.

While those issues are important, it doesn’t answer the question. The purpose of the question was to ascertain how many web pages have been completed. That answer can either be a number or an honest “I don’t know”. Once the question has been answered, then you can provide your justification. This allows your manager to get a clear and concise update and leave open the opportunity for clarification.

Listening to the question can also save you time and expended effort. Typing up a well-worded email that doesn’t answer the question wastes everybody’s time. And delivering work that nobody wants can demoralise a team.

If you need clarification, don’t be afraid to ask. Seeking clarification first is much better than delivering unwanted work later.

In a job interview, listening to a question is vital. This is your opportunity to show that a company can confidently put you in front of a client. It frustrates interviewers to see someone who is technically proficient but a poor communicator.

When asked a technical question like “What is Polymorphism?”, I like to answer it by stating what it is and then providing an example.

“Polymorphism is the ability to process objects differently based on their data type or class. It is also the ability to re-implement the methods of a derived class….

An example of this is a Dog class that can have its ‘Bark’ method overridden by the Sub class “German Shepherd” to have a different kind of ‘Bark’ message.”

In this example, I have given a theoretical definition of polymorphism and then shown how it can be practically applied. This shows that not only do I understand the concept abstractly but I can also show how it is useful.

Listening to your team members is vital whether it be in a daily stand-up or scrum. More often than not there will be a cross over in workflows and people in your team may be working on a feature that affects your work. Listening to your team members can also give you the opportunity to help them if you can.

“We have two ears and one mouth so that we can listen twice as much as we speak.” Epictetus

Communicate Progress and Blockers

When on a project, you should never work in isolation, even if you are the only one working on a task. To give your team lead confidence that a project is on schedule, provide regular and concise progress reports.

‘Regular’ is relative to the scope and urgency of the project but it should be often enough to report significant progress. This will also give you the opportunity to communicate issues that you may be facing early on so that it can be dealt with as soon as possible.

The people you report to may be able to help you by pointing you to subject matter experts who can help you or tools that can solve your problem.

Regular reporting also can show your project leads if you are on the right track and if the right tasks have been prioritised. In so doing, leads can reprioritise your tasks or discuss your course of action if they feel it goes in the wrong direction.

The cost of rework can be unacceptably higher if a solution is developed in isolation.  It may be delivered on time but often fails to meets requirements.

The following example shows a status report that concisely defines subtasks, the ETA, status, duration and comments:

This table is easy to update as opposed to writing a paragraph every time status is required. The table can also be used by your leads to easily provide status to other stakeholders.

Copy the right people into your email so that everyone can be updated at once, avoiding the need to make duplicate communications.

If you’re working with agile planning and tracking tools like QABook and Jira then regularly updating your tickets is just as important as your team can get up to date information without having to come to you directly. Team leads can then rely on your updates to produce accurate burn down charts and other useful metrics.

Know Your Audience

There are some people who are technical and there are some that aren’t. There are some who are details orientated and some that are more headline orientated. In any case, know your audience. As you get to know your colleagues you’ll soon find out what information they are trying to get when asking you a question and what information they consider important when they are communicating with you. Try to tailor your communications accordingly so that they can better understand you and you can better understand them.

Talking to a non-technical manager about thread safety issues when all they are really interested in is an ETA on a feature is not going to get you very far.

Knowing your audience can lead to more efficient communications and allow you to tailor your conversations so that your concerns can be clearly communicated to the people you answer to and resolve issues quickly.

For example, if there is a bug in your code that is causing a problem, rather than explaining the details of the bug, it might be better to explain the impact the bug has on the deliverable.

Another instance might be when you feel prioritisation of tasks have been incorrectly set, then expressing your opinion on the impact of that with respect to the project timelines. This might better than talking about the technical impact.

When dealing with a more technical audience, it might be more appropriate to discuss design decisions when performing a task and why it is better to use one approach over another.

Be Concise

Nobody likes to read a page long email in order to get an answer to a simple question. As you are probably busy getting your own work done, I’m sure you want to spend as little time as possible writing emails or giving status reports.

Less is more. Answer the question, provide context if needed and provide any necessary references.

A picture says 1000 words. If you can show a screenshot to describe a situation, do so. Rather than pasting in the entire stack trace, copy in an extract and attach the entire stack trace as a file for reference. If you are talking about a list of things that need to be done it might be good to use a bullet pointed list rather than writing it all in one line.

When updating a kanban board, being concise is ideal as you can avoid having a bloated ticket that team leads find difficult to read.

Being concise is also important in a sprint retrospective. Feedback needs to be given accurately and specifically to make sure than the next sprint runs better than the previous. When in a retrospective, talk about things that can actually be acted upon and ideally be measured for future improvement monitoring.

Spelling, Grammar and Confidence

I’ve learned the hard way how embarrassing it can look to communicate to senior staff with spelling mistakes and bad grammar in an email. It can impact your own reputation regardless of your technical proficiency and it can even cause clarification emails to be sent back to you wasting further time.

Proofread your emails and don’t rely on spell checkers as the sole form of QA. Get your peers to read important emails if need be. Speak confidently and clearly with verbal communications and minimise slang when giving formal presentations. In a globalised economy, you are likely to talk to key influencers from around the world who may not understand your culturally specific colloquialisms.

In conclusion, your communications should be tools to get good quality work completed efficiently. They are a window for people to see how skilled you are and how valuable of an asset you are to their business. Communication should be a platform to success not a hinderance.

“The single biggest problem in communication is the illusion that it has taken place.”- George Bernard Shaw

Chris GungalooEffective Communication in Agile
read more
Raising the profile of performance!

Raising the profile of performance!

No comments

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