I was in a podcast. Somehow.
First, I want to thank Ruslan Akhmetzianov from QAMeta for inviting me over. If you have not heard of QAMeta, you’ve most likely heard of Allure, as I talk about it quite a bit.
Feel free to listen to the podcast and share your opinions with me. Did I make a fool out of myself? Did I say enough? Not enough?
Well, either way, this is one big step in a good direction for the testing industry and QA, as well as for myself. We are witnessing the birth of next-gen testing. The days of just manual testing are nearly done. The days of just knowing enough Selenium or Playwright are nearly done. As software gets larger and more complex, so does the need for QA testing. The testing needs to scale, go faster, and be more stable.
For all the companies I’ve worked for, it’s always been a rare sight to see reporting fully done and fully working, or even a functional process. Automation frameworks usually are an afterthought. There are rarely companies that are willing to implement frameworks from scratch that can scale. However, Allure TestOps has been a big step in the right direction where every person involved, from CTO to QA to PM, can all agree it’s a good tool to have.
This new paradigm brings a question, a large question:
As a QA engineer, can you fully architect an automation framework?
For me, it was not until recently that I could answer this as a yes.
A few months ago, I still had no idea how to do correct load testing and the actual difference between performance vs. load vs. stress.
If you answered ‘no’ to that question. I highly suggest you learn everything you can. As in the podcast, we also spoke about AI tools and how those will eventually make their way into testing (some already have). So you can easily see that manual testing will perhaps no longer be 100% manual. Even if you don’t code, you will be required to know some basic universal industry-wide skills, such as Bash, Shell, and Git, just to start testing around modern software.
With new tools such as post-SQL DBs, where you can make table changes on the fly, a lot of these stable QA/UAT environments that manual testers depend on to validate could very likely become fully ephemeral. This will require everyone on the team to understand basics like branching or running a script. And TestOps, or something similar, will be the reporting tool for such new testing teams.