Why Test Engineers Should Be Certified

Why Test Engineers should be certified: whether a question or a statement – it seems a reasonable point to ask? Many years ago, a very good friend of mine suffered a catastrophic mental breakdown that would have seen the greater majority of us defeated; me included. However, after some stunning and experimental treatment, she learned many techniques to manage her condition and live an active life. Indeed, her recovery was nothing short of a miracle, and as such was awarded a ‘certificate of sanity’. Just how many people do you know who can say they are sane and have a certificate to prove it? I certainly don’t – even though it might have been useful to have shown the many who may have questioned my sanity in the past and will, no doubt, do so in the future. Now, I’m not saying that a certificate of sanity won’t appear odd notion to some, nor am I suggesting that it is something that myself or any reader should strive to achieve. It does, though, make the point that certification can be applied to all walks of life and serve as demonstration of proof to anyone who asks for it, regardless of the circumstances by which it becomes either necessary or desirable.Looking at Test Engineers, I’ve yet to meet one who I didn’t consider sane, and that’s a fact! It might be fair to say, though, that they have a way of thinking that can frequently set them apart from the peers and colleagues in IT and the Business. Does that make them wrong? Clearly not, as they offer the different thinking required to bring together systems development managers and business sponsors. Indeed, we no longer need to ask ‘What is Software Testing’ as we know that Test Engineers have something rather special that can significantly increase the chances of project success. Indeed, what they do in all forms and guises of test engineering is now recognised by:

• Business, who want a return on their substantial investment in IT systems, and see testing and the certified tester as a way of getting it;
• CIO’s as the discipline that keeps the development team honest and on track with the required solution;
• HR as a career path up the ladder (and about time, too).

It’s all well being recognised as a decent and certifiable skill and career path, but you might ask, what makes a good test engineer? Among the myriad answers we might consider are:

• An analytical mind;
• The ability to see things independently and from all points of view;
• To be able to talk the different languages spoken by IT and the Business, and to understand where each is coming from;
• One who has proven their skills to a certifiable standard;
• To be the glue that make projects and sprints function efficiently and with a return.

Clearly, Test Engineers are diplomats who can sit comfortably in between projects and the business, each of whom frequently fail to communicate correctly and disagree – despite them being on the same side! But that’s not enough, is it? There are many diplomats in life who are good at brokering agreements and diffusing difficult situations, but how many career diplomats know about IT or would fit the skill set of the winning test engineer. No, test engineers need something beyond the all-important diplomacy skills. They need that extra something in their minds that allows to see beyond see the end-goal (typically a new system); but to also see:

• How to get there and the pitfalls along the way;
• If what the Business is asking for is sensible and will underpin day-to-day operations;
• If the business analyst has completely translated what the Business needs into something that IT can build, deliver and be usable (that is: is it testable, and if it isn’t then it won’t be usable;
• How to plan testing at each phase of the life cycle so that acceptance criteria are met with the minimum of spend;
• When things are going pear-shaped.

See the point? The tester is the conduit who makes it happen, by operating as the all-seeing independent witness and finding problems with analysis, specification and design – long before we’ve wasted money coding flawed solutions. Ok, great, but what’s the value proposition you might ask? Again, another reasonable question, so let’s take a look at 4-key imperatives your typical test manager and his or her team will strive to ask, manage and achieve:

• Are we building the right thing? This might seem a bit of a funny question, but it is one that is decided right at the beginning of the life cycle – well before a line of code has been developed. After all, what is the point in coding something that is wrong when we will clearly have spent time and money in analysis, specification, design and build in traditional environments of sprints in Agile, only to find it is wrong? Just how much have we spent, and do we spend getting it wrong such that our time to get is right is seriously compromised. With a little foresight and engagement of professional testers we could have got it right from the outset?

 

• Are we building the thing right? Yep, this looks very similar to the previous question, but it is one with a clearly different intent and outcome. So, what might the tester mean by this? If we consider that more money is spent on maintaining systems than the original cost of development, we can see that it makes good sense for the tester to be engaged throughout, as they will be the ones looking at the solution, comparing it against the original requirements and validating that it will meets needs on implementation and thereafter to be maintainable.

 

• Does it do it right (is it testable)? Too many systems are build that either don’t do what the business needs or do it in such a manner that makes them difficult to use. In any case, we want something that is simple to use and which meet needs and works as planned on implementation. Your Test Team will build in quality initiatives throughout to secure sensible outcomes that offer the much sought-after return on investment and acceptance of the solution by the business.

 

• Do I have the right skills at the right time? The right skills begin with the internationally accepted certificated programme, which starts with the ISTQB Foundation in Software Testing as the forerunner to the advanced certificates.

These are four key imperatives that the Test Engineer will consider as a system goes from inception to implementation to maintenance and finally decommissioning. You might say it all seems common sense, and I agree – it does. But when IT projects are going wrong, as many do to a greater or lesser degree, the common denominator is the omission of a good test team – or one that has been isolated or ignored as an overhead. Test Engineering isn’t an added expense, but something that will return value and, assuming it is done correctly, offer continual and growing confidence as your systems development transitions through the life cycle. And if you don’t believe me, then simply look at the major systems integration companies, each of which has or is building its own Test Engineering practice.Ok, so you need a bit more convincing. Right, it is a recognised fact in the IT Industry that those companies who invest in good testing and provide decent career progression suffer fewer IT programme and project failures. And the tangible upside is the ROI achieved by getting systems developed more rapidly that meet the needs of their business and, importantly, have a reduced attrition rate when compared to the average. In my experience, most companies not investing in testing and building skills will spend 150% of their budget getting 80% of what they wanted in the first place as a result of having to rework flawed systems that the tester will identify pre-coding – if engaged. Not good, and not something we would want to be associated with?Clearly, the skills of the Test Engineering Manager and his or her team are quite extraordinary when put to effective use. These skills can be developed or bought, but learning curve is the same if you want the best outcome.If we invest in getting our Test Engineers Team educated correctly to an industry-recognised standard, such as the International Software Testing Qualification Board (ISTQB) or the International Software Quality Institute (iSQI) you’ll find that your team:

• Talk a common language;
• Understand and use the correct and effective processes;
• Know what and how to plan and run testing that proves your system is fit for purpose; or if not then the risks and workarounds for going live;
• Have identified the risk and impact of failure, and how to both prioritise and mitigate both;
• Put the right controls in place to ensure that things start and remain on track;
• Understand how to measure and provide confidence to stakeholders, be they from the Business or IT;
• How to engage and drive everyone to the right result – with the three key imperatives at the fore;
• Provides information that informs cogent decision-making.

Systems development is clearly a very expensive business that is manned by expensive teams to deliver solutions for business that will keep it ahead of the competition. The responsibility of the test engineer is both wide-reaching and key to success. Like professionals in other careers, such as Civil Engineering, Medicine and countless others we consider business critical, you would expect them to come with the right qualifications, right? That is, certified by their governing body to have reached a standard that you can rely on. Why, when one considers IT spend on systems development and the cost of failure to business, would you risk have uncertified people overseeing your business-critical programmes?So, like my friend who has been certified sane, it makes a good deal of sense to invest in certifying a Test Engineering Team. Testing is common sense, so investing in it and the people you rely on to do it is also common sense. Look to get your team certified to help them grow their maturity and knowledge through basic levels, through to intermediate and advanced levels in traditional, agile or DevOps environments. There is a certification for each skill, and it makes sense to have it – invest in your team and they’ll get a certificate stating their level of competence; and that is something you can rely on! Certification? It’s common sense!See also ‘The Long Term Test Engineer Development Programme’.