Agilejourney

AGILE – MY JOURNEY AND INSIGHTS

My Agile Journey

Agile got me. Long long time ago, in a Gringo client far far away. It got me from the back and without any warning.

Well, not so long ago. Actually, it was a little bit more than a year ago. But it has been a huge experience.

Before that, to me agile was a weirdo way of creating software. A way that seemed ridiculous because with the fast paced sprints, it did not leave a chance to do the load tests that I was used to. In general agile was total nonsense to me.

Before that, I had been only on a few environments that tried to embrace agile. But, for most of them, I was not involved given the nature of my waterfall specialty.

I had to observe agile from a distance. Whenever I was involved, I still was requested to follow the waterfall practices (so ridiculous) and waited for a big time deliverable to script it and do a full performance load test.

On top of this, most of the agile teams that delivered to me were awful. Not organized at all. And now that I know agile better, they were just wannabes. All of them thinking they were agile but in reality they were just doing mini waterfalls.

BEFORE AGILE, WATERFALL

Before agile I only had eyes and beliefs for what I did all of my life as a performance tester. I was following the steps that I have been writing so far on this blog. Most of them – waterfall.

The thing about a full load test is that you depend completely on the product being almost completed and finalized. It needs to be totally frozen.

You need a long time learning about the solution. Then, you need time to reverse engineer it. The developers are long gone and encrypted all the code.

If everything went well, you would have a bunch of automated scripts. Most of them (fr)agile and very dependent on no changes on the system. This gives you a one shot opportunity window. If you miss it and something changes, you may have to start all over again.

This meant that on a best case scenario, it would take up to 3 weeks to pull off a full performance load test. In a best case scenario.

Sadly, this way of doing things was longer than a traditional agile sprint. But, let me say this isn’t wrong. It is impossible to be done “effectively” within a two week sprint. Better said: it could not be done in the way I used to think as “the right way”.

That is the reason why agile seemed preposterous to me. Not doable due to so many changes happening without time to adapt your scripts.

On top of that most of waterfall teams were unorganized. There were lots of silos and unbelievable communication problems.

And the cherry on the top… There were several companies that were trying agile. They lacked so many things. They had no idea. Not culturally, neither technologically.

EVERYTHING CHANGED. WELCOME TO AGILE

As I have mentioned earlier, I got to an agile project a little over a year ago. I had little to no agile experience or formal knowledge. I had been pretty much thrown at the fire.

The experience was interesting. To say the least.

Agile has some characteristics that work inherently against the traditional way of doing load tests. But at the same time, has some characteristics that enable many interesting things in terms of performance testing.

I will not dwell much in a deep description of agile. But I promise a post about it in the near future.

But agile’s main component that makes it hard to adapt for a traditional load test is that it is constantly changing. In the time that a scripter has finished to script an automation, it has already changed. Thus, breaking the script(s).

Second, the solution keeps growing. It doesn’t just change often, but it keeps growing and growing (load and features). This makes the labor of creating and maintaining scripts to grow almost exponentially.

IT IS NOT JUST LOAD TEST ANYMORE

Was it ever?

Yeah, a full load test becomes increasingly difficult if you just keep doing things as usual. The maintenance of the automated scripts requires time. That time adds up after all the constant changes. You would hold everyone. That gives them a hard time for both scripting and executing.

That goes totally against the agile credo. Not very practical even for a hardening sprint. So the question goes: HOW DO WE ASSURE GOOD PERFORMANCE? (Later we can worry about the load)

You may notice the word assure in bold text. It is not anymore just about testing. Not anymore just about load testing. It is about assuring that the system performs well. It is performance assurance.

To be able to assure that a system performs and that you know exactly where it doesn’t, you need to change the mindset on how you proceed about it.

Things have changed with agile and so has performance testing assurance. The answer is not automating as much and fast as possible. We need to be smarter about it. Just to stop thinking about the big ass load test we used to do right at the end of the project. Now we have multiple and constant ends on the project. So many moving pieces.

It is not about the silver bullet automation tool that will magically enable you to script as fast as needed. Or not to scrip at all. That is not possible. Whoever tells you that a tool just by itself will enable you to do agile, might require follow up questions on those fantastic claims. It definitely is not about tools. They may help a bit, but the true answer is elsewhere.

Beware! The changes are coming!

CONCLUSION

Agile brings several challenges to the old art of performance or load testing. Especially because of the fast pace on everything. It keeps growing and that would make the maintenance of a growing pool of automated scripts, impossible.

To assure good performance the course of action needs to be changed. The old ways will just not work. Stop trying to automate as much as possible and as fast as possible. It is not about a tool. It is about mindsets, culture and cooperation.

I have found several ideas that have helped me to assure performance on agile teams. I will write about them and open a can of worms that will be fun to talk about. But mostly I hope will be helpful and give material for thought. This story will keep going… In two week sprints.

Besos <3

-Señor Performo