A new hope…

Boy, that sounds like a pathetic title. But this is a personal story of being thankful, so yes, the title has a right to be pathetic.

When I joined QualityMinds last year I made the conscious decision to enter a consulting position. I knew that it’ll be part of my job to change projects from time to time, do different kinds of workshops, talk with potential clients, and so on.

Now it’s about time to change project for the first time. And I want to use that chance and look back at the last nine months, something I won’t probably do for the next changes, but my first assignment was in several ways special to me. And it’s is also a way to say “Thank you!” to the project team.

As some of you might know, I left a place last year that would not immediately come into mind when you would try to describe “a great place to work”. So you might get a feeling why that project was so special to me, even if others might say, where’s the big deal, that’s business as usual for me. Oh lucky you!

Early September 2016 I joined the team responsible for the content management system behind a large telecommunication company’s online platform. I was the first “professional” tester to join the team, before me usually interns and team newbies did most of the testing. I was the only full-time tester together with two part-time interns, who already started shifting towards developer positions, in a SCRUM team with 12 developers. Bad ratio? Not at all, not in that team.

“Everybody can test!” was one of the team’s mottos, and it still is. Two special moments are attached to that motto. The first one was when taking over a work package that was new for the whole team and that blocked nearly all my capacity in the beginning. I got immediate help from three developers until the backlog was down to near zero. I was astonished and impressed.
After about half a year I was worried that the team got a bit too dependent on me, as when the word “testing” was mentioned usually all eyes were on me. So when going on vacation for one and a half weeks, I was worried how the SCRUM board would look like after my return. Well, the board was pretty empty, except the tasks that were currently in development. All stories that were finished during my absence were tested. My stomach feeling was gladly totally wrong.

When I arrived the automation suite with only about a hundred simple test cases was based on Protractor, despite the fact that the portal was not an AngularJS application. The tests were written around the actual Protractor features to simply use the provided webdriver. It was a nightmare to use and debug. When I asked if it would be possible to replace “that thing” with something in Java, that would be better to debug, and written in a language the whole team understood, I was only asked to put all pros and cons in a story for the next estimation meeting. I was running against open doors. Once it was a bit quieter again, the story was up for implementation and I was the architect behind my second test automation framework, this time even seeing it to become reality. And the first time in years the UI automation suite status went to green.

And after nearly 14 years as a tester I made several experiences of automated tests finding regression bugs. I might be one of the bigger test automation skeptics, not against automation itself, but being careful to not trust automation too much. But this test framework and the test suite and the tools I wrote found several issues and prevented some nasty bugs from going to production. That is a new sight on test automation for me.

The project itself has a very technical nature. So for the first time in my career I was not testing business processes. I was testing technical features. And that was a new experience for me, as I not only needed to know as much as possible about the whole system and how it worked together, but more often than not, I was looking into Java code, checking what had been done, trying to understand the impact and evolving risks right there from the code base. This also helped me to regain some basic Java knowledge.

There was also a rather boring part of my job, checking design changes that came in via merge request. It was not the most challenging work I have done in my IT-life, but it hugely influenced the way of looking at the web portal. Issues that were not even worth entering into the bug tracking system in my old company, were being fixed usually within a few days or faster. And we are talking mostly about aesthetic changes. That is something people care for here.

The Product Owner is doing a really good job as well. Never before did I have a product owner who stood for a clean line in the product. And hell, does she know that system. When I thought I tested nearly everything that a story could impact, she would find two or three more scenarios I never even have heard of. And still I was able to test with such a good quality, that she trusted my opinion as she did with the whole team.

Blaming or finger pointing is non-existent inside this team. Even my usual self-blame for bugs that are found during PO acceptance or in production were always generalized; nobody else working on the ticket found them, too, so let’s fix it and learn from it.

This team is great, doing a really good job. They have team spirit, always helping each other, encouraging to learn, and open for sharing. They have reached a SCRUM maturity level that impressed me from the day I was interviewed for the team. All things I haven’t experienced first-hand before in my rather silo-ed endeavors.

I brought my part to the table to help this team, but I also got a big amount back in the past 9 months. I learned a whole heap from this team. I learned stuff and experienced something, that 10 months ago I thought to be strange stories, fiction, special situations, or whatever reason you might find to not believe something’s existence.

Soon it’s time for a new challenge and finding out how I can help there.
Team CMS, thank you!

Advertisement