With close to 15 years of experience in IT and testing, you can’t help but wonder… what actually changed over the past 15 years, when it comes to testing? And what does the future hold...

Let’s start off with a short introduction. My name is Ramona de Wit-van Ark and at this moment I work for Albert Heijn IT Online as a Test Lead for our Mobile-apps teams and Logistics teams. Since I have close to 15 years of experience with testing, you would think that I have a proper understanding of what is changed in the world of testing.

Let’s go back in time!

Well, let’s go back to my first assignment as a junior tester. I was 21 years old, a real rookie, I had just finished two studies in Information Engineering and 3D Production, and had one month of training in TMap & ISTQB. I was hired by a company named Elegant. Back then everybody worked with the waterfall method, so you could probably guess how that played out.

An idea, impact analyses, functional design, technical design, building, testing and then GO, Release!

Before any testing was done, a test plan had to be created first, explaining what your strategy and approach would be, what kind of test techniques you will use and how long it will take to do your complete test run, including regression testing. 

Test scripts were based on the functional and technical designs and you worked from test analysis to logical test cases to physical test cases. Then, of course, you would do your preparations, verify if the test environment was ready for testing and you would create your own test data. The reason the tester, rather than a developer, was responsible for the creation of test data was that I had been told at that time and I quote: "You can't trust a developer...". 

When all your preparation work as a tester was done, you were literally waiting for the developers to finish their work. 

This is what the waterfall method essentially entailed. As a tester, you were all the way at the end. All this created a lot of pressure. You prayed and prayed, that the developers would be on time, in order for you to do your job properly. And most often, everything got delayed, which by the way already started with getting the functional design approved. The tester should be more flexible and pragmatic and was expected to narrow down a month’s worth of work into one week. Most testing would have to be done manually, and of course, a "go" or "no-go" would have to be given by the tester. It was expected that mistakes would not happen, and if they did the tester was blamed for this. This would result in the good old blame-game: “You didn’t test this properly.”

All I could say to this was: “Ouch...”

Of course, the release wasn’t bug-free, which no one thought of when planning the project. The tester had to give her test report back to the developers and project manager, and everyone was unhappy and stressed because the deadline wasn’t met and the project manager had to give the bad news that his team didn’t perform as expected. And all everybody could say to the tester is: “please stop finding bugs, it’s not funny anymore, we need to release”.

These were the old days. However, I must add a small note to this story; at that time, I was already too stubborn and curious to follow this process and I’ve learned a great deal at Elegant. I was very spoiled as a rookie and had three mentors: Evelien Jelinek (Business consultant), Stephen Cannan (Database architect & developed the SQL standard) & Marc Gofferjé (Director/Program manager), which I can still after all these years ask for help or mentoring, and are still a leading example for me.

Let’s go back to the present!

Now let’s go back to the present! As mentioned in my small introduction, today I’m a Test Lead at AH IT Online and working in an Agile environment. We work in sprints of 2 weeks and we strive to deliver at the end of every sprint a releasable product and that’s a challenge!

The first thing we need to have or create as a scrum team is trust, trust in each other and trust in the quality of our product. Therefore we need to discuss quality & test strategy and -approach as a team and capture this in the Definition of Ready and Definition of Done. Because we have to deliver every 2 weeks, we need to know what the quality of our product is at any time of the day and for that, we need to have insights & metrics. In order to make sure the idea or user story is something that’s well thought of and will add value for the customer, we need to look at the big picture and ask all the questions that no one dares to ask or think of.

When we start our sprint, we start with the sprint planning. Another very important aspect is highlighted, namely: test automation, because we don’t really have a lot of time to do long manually regression tests, checking and validating if everything works as previously designed and implemented. To implement test automation correctly we try to implement this according to the test automation pyramid. However, a mistake which is often made is that we think that if we automate everything, it will be some “holy solution” to all! Testers are not necessary anymore and we don’t have to manually test anything anymore. Well… I hate to burst your bubble, but all you're doing with test automation is checking if everything works as you expected it to work. And checking is not testing, at least not in the present day we live in. When considering test automation, always focus primarily on risk and value - by focusing on these two points, your automatic test should always remain highly relevant. That’s just a small tip! ;) In order to implement test automation, the tester will need to pair with developers and try to make the whole team aware that testing is a team effort, that should no more result in finger pointing because we are all responsible for the quality of our product. 

After test automation, we explore if the new feature is really working and nothing is broken, this is known as exploratory testing and is essentially a bug hunt! And no, this is not just clicking random things. You need to have a goal, questions, a mission, and again, don’t forget pairing or even ‘mobbing’. Don’t underestimate the need for manual testing. In order to become a better tester, I suggest to every tester to follow the training Rapid Software Testing training, you will learn a trick or two! The thing that is the most important to have as a tester is a correct mindset! I’ve had many testers who just didn’t fit our profile and with this everything collapsed. Sad but true. The tester nowadays needs to have a big bag of soft skills! We need to give feedback during the whole process, starting at the inception of an idea and refine and actually never stop with giving feedback, not even when the product is already live. We need to convince and coach the scrum team that testing is a team effort. We talk to the product owner and stakeholders and give advice and constant feedback if necessary based on our metrics, feedback, and insights we've received from the end users.

If we go back to the past, we wouldn’t be talking about a tester, but it would be a mixture of an analyst, developer, tester, consultant and coach. Where one tester is more analytical and the other is more technical. So, in the present day, as you can imagine, it's pretty difficult to find a tester with all these qualities and fit the profile. However, not to brag, I must say that we have a great test team and I’m proud of all the testers we have and that they are part of my team! 

Let’s go back to the future!

And finally, let’s look to the future. What will happen in the future… let me think. Especially with machine learning and artificial intelligence, you can’t help but wonder if testers or even anyone in the IT is still necessary? Will robots or machines be creating software and hardware at that point? And what will be our role in this as a tester if so? Well, to be honest, I believe that the tester will always have a necessary role in the world even in the future. If only to avoid that we don’t end up in a ‘terminator’ world or in ‘the matrix’. But, will the role be exactly the same as it is now, I highly doubt it. It will depend on the way of working in the future, but also the products which will come our way. All I can hope for is that when the time comes that we have to change and help each other finding our new role and we will adjust and change together as a team. 

My conclusion..

So, what actually changed in the world of testers?

One of the things that didn’t change and will never change is that we are very flexible and pragmatic and that we feel very responsible for the quality of our product! However, a lot has changed though... but if somehow you are still stuck in the past, please buy a DeLorean and at least come back to the present… ;)