Iterative and Incremental Testing — Vol I
Travels to the deep of Agile Testing
Session 1: Methodologies
Introduction
Hi everyone, I’ve started my professional life in 2009.
The first client I was working with is one of the biggest gaming publishers company (yes, you are right), I was anxious and excited even with the technical interview, which was completely different than others. I was (and continue being) a Gamer, so I was very nervous about it, and I had to nail it, because, for me, it was a one time only chance.
Spoiler alert, I passed the interview, then I worked for that gaming publisher company for around 5 years, always as a Game Tester, or Quality Control, etc.
After that, I worked for e-Learning, Publishing, Marketing, and since 5 years ago in the Finance / Bank areas.
Always with a focus on Testing and Agile areas, with leadership skills, teaching, coaching and more that you can find on my LinkedIn since this is not an article about me -I think-.
A lot of things changed in those 12 years I’ve been working, the companies, the cultures, the teams, but one thing I noticed in common on the different engagements was that we have been working with Agile, or trying to be a bit more Agile than we are.
I know that is something very common now, but 5 years ago or more, it was something totally different.
The software life-cycle is different while having an Agile mindset (in future volumes we will cover the difference between Mindset vs Tools or Practices).
Why? Because it consists, over all, of having continuous improvements -about the product, the service, the process, the flow, everything), while having a repetitive process (on Scrum called iterations, for example) that add something, known as working software at the end of each process. And then you add more functions and value one repetition at a time. But no worries, I will explain it better below.
That’s why this is called Iterative and Incremental Testing.
And my goal is to talk about this way of working, organize tasks, focus and time, and how it affects the way testing works as well with other roles.
We will have an overview of the development cycle while using Agile, and some changes that affect the way software development has been working.
Also, in future volumes I will cover how the Tester’s role has been affected by XP, Scrum, Kanban, then cover some key aspects of the testing role in agile environments, what are those skill that a testers needs or should have, and probably which techniques or tools you can have near that will save you a lot of time and avoid frustration.
So, let’s get started because we have a long road ahead.
The Agile Manifesto and the impact on Software Development projects
Before starting to go deeper on how the Tester role has been affected by the Agile SDLC (Software Development Life Cycle), let’s talk a bit about the history and values of the Agile Manifesto.
You can find all this information on https://agilemanifesto.org/
In 2001, after evaluating how companies and teams are developing software, and how to improve that way, 17 software practitioners wrote and signed what is called the Agile Manifesto.
This is an agreement with 4 values and 12 principles where the bases of Agile are written.
I’m not going to detail each of them here, but I want to summarize the goal behind it, which was to have something over the different methods and frameworks that already existed. It can vary how it is implemented, but they share the core, values, and principles.
They were looking to increase the human interactions on their teams, to adapt and evolve new ideas, to focus on what it’s important, the value delivered to the client, and what the client wants and needs.
So the teams, the different roles, areas, need to collaborate between them, to share their knowledge and increase the value offered, to collaborate with the customers and generate a shared value.
That was the first priority, satisfy the customer, show value in a constant way. Then to embrace changes, because it is highly probable that what the customer thought he wants and what he was expecting when he receives the product, can vary, or the needs have been adapted from time to time, and the product needs to be with that change. This does not mean that we will do what the customer wants, like a child, instead it means to be involved in the product, on the business, while inspecting and analyzing the impact and generating agreements with the users to have a transparent and clear knowledge of what is expected.
So, we need to take care of our clients, to show them valuable stuff, that we can change things and receive feedback from it, and that, of course, every time we add something, everything needs to continue working (as expected, at least).
For that, business, methodology and development areas need to work very close, they need to have a clear path of communication to transform the ideas of the client, to what will be built, and how we are going to do it.
Everyone needs to understand where they are, and what needs to be done.
For that, you can have meetings, tools, boards, whatever you want to have while you understand how the progress will be.
This was a very highly resume about what the Agile Manifesto brings, and how the table was flipped if you want to compare it with Traditional ways to work on Software. If you want more information, you can enter on the Agile Manifesto site, or look for Agile Alliance for example.
From silos to a multidisciplinary team
Developers on a side, testers on the other, business people on another floor, designers on another building, and so on, with low or null communication between them.
Something that has been changing with Agile, was to have teams with different skills, working in a collaborative way, with the participation of all the areas involved in developing the best product possible.
With that, it is not that the Testing team has to wait until the product reaches a stage to start testing and then goodbye and we never see the product again.
Testing members, with Agile, are involved in creating the strategy and the plan to improve quality on all the aspects (yes, there is quality on our relations, communications, code, product, flow, etc. And everything can be improved) with and within the team.
We can see more cooperation, teamwork, improved communication, and collaboration, having a shared knowledge between the members, instead of having one person knowing all about it.
That happens while having emerging practices, that the team creates while they are working together, understanding each other, the business, the product, the methodology and when / how to ask or offer things.
With that, also, everyone is responsible for what the product will be, and the quality during the whole process.
So Developers and Testers do not need to be enemies, they need to be supported and working closely together to have the highest quality possible on the product, and within all the levels of testing.
For example, they should work together to create effective test suites, and for that, the communication needs to be very fluid, the understanding of what is expected, how is expected, and when, too.
There is no need to have a formal meeting to sync, they should work side by side to discuss how the work is progressing.
Those are a few things that the teams can do to ensure and achieve quality on the products developed iteration by iteration.
Better sooner, than later
I commonly said a phrase is “feedback is my fuel”.
Why? Because I need the feedback from others to understand what I need to change, to do, to stop to be a better professional, a better teammate, a better leader, a better person.
This also applies to agile development teams, and it is vital (as it is for me).
It is the way to ensure that what the team is doing is in the correct direction, and having as many moments as you can to obtain frequent feedback and on the earlier stages as possible.
Because if we wait, it will be worse. The cost of one change increases over time.
Cost, not only money related, the time needed, the people involved, the resources and, the impact, increases if we wait to receive feedback, to apply changes, that can be solved earlier as possible.
That is something Agility brings, to have frequent, iterative moments to validate the work you have to do.
You will have risk and changes, for sure, but at least it was for some weeks, not months or years of work. Because the activities and needs have been broken into small activities, so the risk has been broken as well, and is more manageable
In addition, you know that you will have risks, so you are prepared for them, and you will provide transparency and propose changes in a short period of time.
Each increment the team developed, is validated, receives feedback, and when is added to the final product the value is the maximum possible.
With feedback, comes modifications, changes, and things to adjust to increasing the business value and what the client is expected.
These graphics show perfectly how agile changes risk management.
We are going to have risks, always, so at least, it is better a smaller risk than something that could collapse the whole operation
With frequent feedback, and increments being delivered constantly, we are continuously improving, inspecting, adapting not only the product but also, how we work together on the team.
This also implies that we will improve how we test, create scenarios, and develop the strategies one iteration at a time.
Thanks for your time, and see you on the next dive in to talk about Extreme Programming (XP), Scrum, Kanban, and how affected the way Testing has been made.
Tom
