How to challenge complexity: tricks by British Jedi tester Lloyd Roden

With more than thirty years in the software industry, Lloyd Roden has worked as a Developer, Test Analyst and Test Manager for a variety of different organizations. From 1999 to 2011 Lloyd worked as a consultant/partner within Grove Consultants. In 2011 he set up Lloyd Roden Consultancy, an independent training and consultancy company specializing in software testing. 

Lloyd`s passion is to enthuse, excite and inspire people in the area of software testing and he have enjoyed opportunities to speak at various conferences throughout the world including STAREast, STARWest, EuroSTAR, AsiaSTAR, Belgium Testing Days, Nordic Testing Days, HUSTEF, CzechTest and Better Software as well as Special Interest Groups in software testing in several countries.  Lloyd Roden was Programme Chair for both the tenth and eleventh EuroSTAR conferences and won the European Testing Excellence award in 2004.

a1qa: You worked as a developer. Why did you switch into testing?

Lloyd Roden: When I started my career over 30 years ago there were no “testers” just developers and I had studied computer science and development as part of my degree course. It was a natural step to join an organization as a developer/programmer. I spent 5 years as a developer, but I would have to admit I did not enjoy it. It was a great start point for me and I appreciated the fact that I specialized in development all those years ago and am now able to reflect back on those development days. However I soon realized that my passion was to break the code rather than build it.

I left the organization to join a company in QA outsourcing, which had both developers and testers and I decided to move into testing as a Senior Test Analyst because that was my passion. That was 29 years ago and I have never regretted that move. I love every aspect of testing and it provides such a variety of opportunities: system testing, developing automation scripts, exploratory testing, specializing in non-functional testing – such as security, performance and usability. The list is endless 🙂

a1qa: Lloyd, you say that QA engineers can`t Sprint all the time. Why is it important to have a slack in projects?

Lloyd Roden: I am noticing that companies are demanding more and more from the employees, working harder and longer than ever before. Statistics show that the working week has increased by up to 22% in some industries. With the real threat of outsourcing, insourcing and off shoring staff are becoming anxious and so work all those extra hours. I have also seen a trend within the Agile community in the teams going from “Sprint” to “Sprint” without any slack. The net result is that staff are burning out and taking more sick leave as a result, despite the fact that they enjoy working in an Agile project. Companies that have included a slack period have experienced an increase in productivity in their staff. This seems a bizarre reality – getting people to work less means that they are more productive. The problem lies with management in that they will not take the step to try this out. If only they would try this concept with their teams – they might be pleasantly surprised.

On a similar issue we should not get our staff to multi-task too much as this also reduces productivity. People are not “fungible” – money is “fungible” – if I have £100 and divide this into 3 banks; £50 in bank A, £20 in bank B and £30 in bank C, the net result is that I still have £100. However this is not true of people, if we say the person should work 50% on project A, 20% on Project B and 30% on project C the net result is a loss of up to 30% productivity through task switching. The problem is that we don’t work 70% – we work 130% – working late to write that report or respond to our emails on the train home!

a1qa: Let`s compare Scripted and Exploratory testing. Can you name the Pros and Cons?

Lloyd Roden: I am a firm believer in Exploratory Testing. I can only find 3 reasons to perform detailed scripted testing:

1. When you want someone else to run the tests
2. When you want to automate the tests
3. When you have a legal reason to provide a detailed audit of the tests

But even with some of these reasons – it is a weak argument. For instance – when you want someone else to run the tests, why are we restricting their ability to test the product – limiting their skills and expertise. Writing detailed scripts is time consuming, a maintenance nightmare and such a boring task – both to write and to execute.

Exploratory testing provides greater coverage, increased creativity and better bug detection when performed well. It needs to be managed and this can be done by providing session based exploratory testing. Even greater effectiveness can be achieved with paired exploratory testing sessions.

I have an easy formula – the more documentation we produce for testing, the less test execution we can perform and therefore less bug detection will take place. If we insist on producing detailed scripts then don’t be surprised if our experienced testers leave the organization.

a1qa: A Jedi Tester, who is this person?

Lloyd Roden: I am an avid fan of Star Wars 🙂 And this phrase came to mind some years ago. A Jedi will learn the ways of the force. A Jedi tester will learn and master the ways of testing:

• When and when not to use automation
• When to use the appropriate test design techniques
• Mastering the test design techniques and to use them effectively during exploratory testing sessions
• To work alongside other “Jedi” testers – to be trained in the skills of testing

When my father was alive – he was a carpenter by trade and was a skilled craftsman. He mastered the tools of the trade and learned how to use them and respected them. He also apprentice trained me. The problem with testing is that we do not learn from older professions which have apprenticeships. Instead we employ new testers and say “so go ahead and test then”. Adopting an apprenticeship programme which trains testers to be “Jedi” testers is a passion of mine.

a1qa: You`ve worked with a variety of industries. Where do you think it is most difficult to implement testing?

Lloyd Roden: This is a hard question to answer because every industry has its challenges whether we work in safety critical systems, or companies producing games devices. I think our expectations are increasing when it comes to quality systems. We were happy to live with a few bugs years ago – it was an accepted norm. But today we want perfection and that comes with a price tag. One of the other challenges we are facing today is the sheer increase in complexity of our systems that we are developing and testing. The problem is that complexity brings an increase in bugs and often this complexity is not needed. Testers should challenge complexity at every opportunity and perhaps a simple solution would be much better for the company.

Lloyd thank you for answering our questions and sharing your viewpoint. We hope to talk to you again.