Recently, I was asked if I’d like to present at the Dev-Test Conference North to be held in Leeds in September. I was both humbled and surprised, but as I like to challenge myself I immediately accepted the offer. Immediately, I panicked. I had committed to present a keynote speech to a room full of industry experts at a DevOps conference, without knowing anything about DevOps! However, it didn’t take long for me to realise that this moment of panic had presented me with the perfect material.

When attending these events in the past I’ve always viewed the speakers with admiration, as people at the top of their game. These were big shoes to fill and I don’t see myself that way. It occurred to me that many of the people I’ve spoken to at these events don’t see themselves that way either, and often leave the event impressed but not necessarily knowing how to implement these new ideas.

I’ve worked in testing for 15 years and during this time I’ve made numerous mistakes. But there is no better teacher than failure and I learned there are underlying principles which, if followed, will aid in success when starting a new team or taking on a significant change in a process or system.

Principle 1. Know your organisation.

Know your requirements before you start to make decisions that lock you into a solution. Like any project, starting a team or changing a process requires you to know what your end goal is and to keep it in focus throughout your delivery.  So choose the processes and functions that will add benefit to your company with a view to meeting your goals, regardless of what the industry is telling you to do.

Principle 2: Know the risk you are trying to mitigate and know your goals.

Testing is essentially mitigating risk. If you start to build a testing team without first thinking about the risk you are trying to mitigate then you will likely implement a lot of testing that doesn’t necessarily protect you from the failures that can cost you both in revenue and reputation. Think about your customer and industry and the failures that would impact you the most. What ‘good’ looks like is very important. But from a testing perspective, we really need to get to grips with what ‘bad’ looks like. What constitutes failure? If we don’t understand that how can we ever mitigate the risk of failure?

Principle 3: Build a strong foundation – only expand when necessary

Once you’ve completed the risk analysis, focus initially on building a foundation of testing that ensures durability in key, high-risk areas. Clarify the requirements in as much detail as you possibly can. Remember: vague now equals waste later! Build simple practices that cover your core risk paths. Expand in layers when it’s practical and only when the foundation is solid and delivering results. Remember there are many types of testing you can implement, but they will not all be relevant to your application or risks. Prioritise the things that add value to your organisation.

Principle 4: Know your Budget – Get buy-in from stakeholders and influencers

In the past, I’ve found myself fighting for priority over other project requirements and losing out because competing projects had a tangible and documented monetary gain. I learned that garnering support has to be a tactic from the start. You need to establish clear and simple reporting illustrating the value of your endeavours. Ultimately, the goal of most organisations is to be profitable! So you should always be visibly demonstrating the financial benefit of what you are proposing.

Principle 5: Plan realistically, not idealistically

When you set up a new team or process it’s very easy to allow enthusiasm to take over and try to deliver the panacea for all testing challenges. I once wrote a test strategy that was so big and complicated it was never reviewed or signed off and was ultimately thrown out! On reflection, I realised the plan was simply too big, and quite frankly unrealistic. So set stretch objectives, strive for improvement, but don’t try to deliver the universe in a single project. Regularly review your targets and don’t be afraid to scrap things that don’t work.

Principle 6: Get the right team balance

This is a tough challenge, especially if you are starting from nothing. When recruiting for teams, you need to consider what skills you need in order to deliver your strategy and priorities. You need to find staff with complimentary skills and personalities. So consider this when recruiting; look for superstars and then add a supporting cast. Have a succession plan for key roles and development paths so you don’t lose your capability when the superstars move on, as they are inclined to do. Churn will happen so manage it like you would any other risk.

Principle 7: Be open-minded and agnostic wherever possible

When it comes to tools, delivery methodologies hardware or skills, the only “correct solution” is the option that delivers your requirements overcoming your limitations. Don’t just follow market trends. In the end, if you are delivering the results then nobody can ever tell you that it’s wrong. Consider all options, do the research but choose what works for you and your organisation.

I’ll leave you with an honest and personal admission. There have been times when I’ve looked at the cutting edge companies in our industry and felt like I was trapped outside the DevOps fairground looking in at a world that’s simply out of reach. But then I’ve looked back at my own achievements and realised that they are no less impressive simply because I work for a company that doesn’t do DevOps. I and my teams have innovated to overcome a multitude of challenges and adversity. We may be using older or simply different technology and methodologies but we’ve met all of the challenges put in front of us, and I’m proud of that.

Written by Mark Bland, Senior Global Test Manager at Premier Farnell.