Yoda’s Software Testing Principles for Thriving in an Agile Environment

Did you know there’s more than just one force? Yes, there’s the one that has to do with the connection of all living beings, but there is also one within software known as quality. An old friend of mine, Yoda, recently visited me at a place in a galaxy far, far away called Uruguay and attended the conference, TestingUY. After attending the session, “The Agile Death of the Tester,” that I gave with agile consultant, Gabriel Montero, he wanted to spread our message to all of the testers across the tech-iverse who are entering into the agile galaxy.

Here Yoda wrote the principles that he gleaned from it for testers to survive agile which he gave to me to share with you today.  

Introduction

Impossible to see, the future is, but after all of my years of living, I, Jedi Master Yoda, can foresee the longevity and ubiquity of agile. Agile is an approach to software delivery that focuses on incremental improvements and quick adaptation to change which is sweeping through the “tech-iverse.”

According to the World Quality Report 2015-2016, which surveyed over 1500 testers, 54% said they had adopted agile. But, without its challenges, it hasn’t come. The most reported challenges were: difficulties in identifying the right areas on which testing should focus (33%), lack of appropriate test data and environment (31%), and a lack of professional test expertise in agile teams (31%).

So why do these challenges arise? Well, young Jedi tester, the traditional paradigm of a tester is not that of an agile team member.

At what agile means, let’s take a look. Being agile means you commit to these values which form the Agile Testing Manifesto:

• People and interactions over processes and tools
• Working software over extensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Herein, the dilemma lies. In the traditional paradigm of testing, testing is not agile because testers:

• Form an independent team that is part of a process or phase in development (usually left for the end)
• Write test cases based on requirement specifications
• Write test cases based on the customer contract
• Create test plans and maintain those tests

So, you testers seem to work counter to agile, but… fear have you not! There are ways that you can keep up with the changes so the software world doesn’t desert you like those in my world deserted poor planet Tython. It is time to unlearn the way you used to think about testing. Instead of seeing yourselves opposed to developers as the light side is opposed to that of the dark, the force of software quality should bring you together to create software that customers and end users love.

Here’s how you can navigate the agile galaxy, a place where you can rise up to the occasion to be a Jedi tester. Like the Jedi warrior who protects peace and justice in my universe, the Jedi tester is one who defends and protects software quality, enhancing the overall software development process, instead of being involved only at the end.

The Way of the Jedi Tester

Principles, here are, of the way of the Jedi tester in the agile galaxy of the tech-iverse. In mind, keeping, I am talking about agile in general and apply to any tester, these can. Keeping also in mind that agile doesn’t necessarily mean rapid development, but adaptive development, responsive to change as requirements tend to change.

I will go over how the Jedi tester adds value during three main activities of agile: planning, doing (development), and analysis for improvement (review).

Planning Activities

Principle 1: In the whole process of releasing a new feature or version, from day 0, participate you will.

Normally, in the beginning, stakeholders specify and “close” the requirements document, sign a contract, and then plan how to do these requirements. In agile, the requirements are not closed, so there is not so much documentation because it is always kept in mind that the requirements will change making it futile to spend time documenting them. 

So, what can the Jedi tester do? Help with these planning activities of agile teams, he or she can:

• Estimation, considering the testing activities to be conducted
• Prioritization of functionalities, as he/she has a wider view and can see the big picture
• Defining acceptance criteria. Yes, after understanding what the customer wants, the tester helps to define the product!
• Creating a test strategy. How will the team go about testing? For example, by implementing TDD (test-driven development), the entire development mindset will change, shifting the focus to testing (Next principle, see the).

Principle 2: Over the detection of bugs, focus on the prevention.

According to Cem Kaner, testing is a technical and empirical investigation done to provide stakeholders with information about the quality of a product or service. In his definition, he is mentioning detecting and reporting errors, but a Jedi tester should be able to also prevent them.

To do so, it is important for testers to ask as many questions as possible before diving into development. This way, both the developers and the customers will imagine a clearer, more thorough image of what they want to make and will have to tackle issues before they arise that you, the tester, have already thought about. For example: Will we need to make multiple versions for different browsers? Will the end user favor design simplicity or performance?

From the initial planning activities, testers should be advocates for changing the traditional paradigm of testing from the one that views it as a later stage in development focused on the detection of bugs to one that views it as an activity carried out in parallel with development to prevent bugs.

Software Development Activities

Principle 3: Using exploratory testing and other activities throughout development, be you concerned with delivering quality products.

Now you don’t have the input, or all of the normal things that testers are used to working with like contracts, requirements specification documents, use cases or anything that tells you how the system is supposed to behave and so, it’s not that easy to write test cases. Test cases helped you to know how to test, with what data, in what context, pre- and post conditions, expected results, etc. How are you to ensure quality without the things you have always held so near and dear? Don’t worry, you already know and have everything you need. Have you the skills to survive, but use them differently you must.

Not so well suited for agile are test cases in the first place because they require a lot of maintenance and do not quickly adapt to change. So, the Jedi tester must seek out lighter alternatives without diminishing the quality of testing or control.  Instead of basing everything on test cases, the Jedi tester must change the strategy, aiming to minimize the time dedicated to maintaining documentation and increasing the time taken to add value.

To do so, today’s agile testers are phasing out test cases like last millennium’s lightsabers, relying more heavily upon activities like mind-mapping, writing checklists, and doing exploratory testing.

Exploratory testing, above all of those activities, is one of the best ways can add value during agile development the Jedi tester.

Exploratory software testing is a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the value of her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project. Lisa Crispin and Janet Gregory, in their book, “Agile Testing: A Practical Guide for Testers and Agile Teams” state that, “Testing an application with a plan to learn about it as you go, and letting that information guide your testing, is in line with valuing working software and responding to change,” therefore it’s inherently agile!

So, whenever you do exploratory testing, you can be agile, even if the Jedi tester is not working on an agile project. And, as the Jedi tester constantly changes his or her testing, he or she can constantly optimize the value of their work instead of following the same procedures again and again that don’t provide the most value nor allow for creativity.

Principle 4: Becoming everyone’s responsibility, QA is. Forming one unified team, work alongside developers.

Traveling to the agile galaxy, one hears much discussion of test automation. Test automation can occur along all stages of development from unit testing to testing on the UI level. Highly effective it is to automate as many tests at the unit level, which also makes QA the developer’s concern. In this way, developers and testers both bare the responsibility of tending to the force of software quality, further uniting them as members of the same team.

To make this principle work, the Jedi tester must foment collaboration as much as possible, substituting the “I” in testing for the “we” in the creation of high-quality software.

Adopt a new paradigm of testing, one in which you harness the force (no, not my force, your force, the one that is software quality) by working in unison with your fellow developer.

Review Activities

Principle 5: The last scrum stages: inspection and adaptation, participate in you will.

Validating product growth and giving and receiving feedback, the team does in this phase. What can the Jedi tester do? Due to your exploratory nature, you have a more comprehensive understanding of product features so, during the product review, you can:

• Guide demos
• Facilitate communication
• Be an advisor to the customer and developers

It is also important to review the team’s processes as a part of the retrospective. A Jedi tester takes advantage of these moments to give testing a voice and a chance for the opinions of testers to be heard not just amongst themselves. Maybe the rest of the team didn’t realize that some issues could have been solved with the help of testing.

Principle 6: By studying, participating in the testing community, seek professional growth continue to, you will.

And, a good Jedi warrior never fails to improve over time strengthening his or her power to wield the force, even after formal training is complete. So, a good Jedi tester is one who continually learns about new methods and tools, participates in the intergalactic testing community, etc. Furthermore, makes an ultimate Jedi tester, helping with the training of the next generation of Jedi testers.

Closing

No matter what galaxy you live in (agile or waterfall) may the force be with you, meaning may quality be in everything you touch. May you choose the light side of the force to produce software that makes the world a better place instead of using it for evil. Oh yes, be you can, agents of change within your organization and the entire tech-iverse!

I hope you liked this post! I’d like to acknowledge Kalei White for helping me to write this post, as she is the one who is a fan of Star Wars who helped me out with the more creative aspects. – Federico

For Jedi Testers, More Recommended Texts

White Paper: 10 Mistakes Companies Make When Outsourcing Software Testing
Best Testing Practices For Agile Teams: The Automation Pyramid