Read our latest article, "Lessons Learned From 20 Years Of Software Testing,” written by @adystokes. The article covers Ady’s journey through two decades in the software testing field, sharing all the practical lessons and experiences gained along the way.
Learn about the importance of context in testing, why continuous learning is key, how to think critically while being empathetic, and the benefits of engaging with the testing community. Whether you’re new to the field or have years of experience, there’s something in it for everyone.
After reading, we’d love to hear from you: What are the key lessons you have learned in your software testing career? Are Ady’s lessons true for you? Let us know your thoughts and experiences!
That, I do NOT have any unique skills in the team, I’m just the person on the team who is on lookout duty and I will need everyone else help to do that job right and keep my eyes open at all times, but for the right things. And never raise false alerts. I’m not special, I’m not the gatekeeper, I’m just tuned to a particular task. I must develop my ability to look and to listen. And as such I need to never think my job is any more than to detect and correctly describe those incoming missiles, it is not my job to stop them.
Sometimes there might be distractions, times the team is struggling with a compiler or toolchain issue, or just a huge security issue. But my job will always be to help verify that we can have that “all clear” with confidence to release because I did do all of the checks we agree upon.
I wrote this blog when I turned 45, which has loads of lessons to live by.
This one always stands out to me:
Enjoy your ISTQB, don’t let anyone devalue you for taking it. I really enjoyed mine, the instructor used to test glass for aeroplane canopies by firing things through a cannon at them.
I had loads of fun doing it, then as I got deeper into the testing scene lots of horrible things were said about it. I know (and count myself in) plenty of testers who struggled before doing it, then went from strength to strength afterwards. For me, that its so popular reflects the lack of guidance and assistance in the industry for new testers. We need many more organisations like MoT to shift the model.
That “best practices” don’t exist, no matter how much easier life would be if I could point to a set of practices and say “If I always do this anything that goes wrong isn’t my fault”.
That the whole team is in it together to produce the best software we can with the constraints we have.
That bugs are usually a function of how complex the codebase is, how many edges the software has, and how effective the requirements gathering was at clearly stating what the customer needs. High complexity plus lots of edges plus confused/confusing requirements = lots of bugs. (Edges being places where modules interact or where there are software/hardware or software/software interactions)
That estimation is a joke too many people take seriously. I learned to take a rough guess how long something will take based on similar-ish projects I’ve worked on in the past, add up to 50% to cover confusion, chaos, buggy software and such, and then double the result because I will have invariably missed something big. (I’ve never worked on simple software - it’s always been massively complicated)
That I don’t know what constraints are imposed on the C-suite, so I can expect software that really shouldn’t see the light of day to be released as limited beta to meet contractual requirements I know nothing about.
That not all organizations want to improve and expand their successful software. Some are happy to sit on the residuals until the company owner is ready to retire.
In software QA, the biggest lesson is that there’s no one lesson, skill, experience, etc - it’s all about the constant process you go through in your career
I learned that the time you invest in building your test infrastructure today, pays off in the long run. As software ages, it tends to get more complex and with time the environment changes too. For example, you have upgrades in compilers or you need to support different platforms with different Operating Systems. If you have a solid automated test infrastructure, your software can survive those changes and testing contributes to its longevity. It helps minimize technical debt so developers don’t feel like they are constantly having to patch code. They could work on new development. It keeps the software healthy in the long run.
It doesn’t matter. Your company, your manager , your coworkers and your environment might make it appear that this is the most important thing ever, but the stakes are much lower. You won’t even remember what “this” was 3 years from now. So take your time, think, relax and enjoy the ride.
(This might not apply to you if you work on the system that touches people health, life or money - then it actually does matter, a lot)
Let them learn. Experience is the best teacher. If you see someone heading for a failure, definitely warn them, but don’t push it too much. Let them fail and learn the lesson the hard way, if they prefer it so. And if they don’t learn, then there was nothing you could have said that would change their mind - so you just saved some time and bad blood.
Don’t waste your time with bad people. Your mental health and family should never suffer. If you end up around toxic people, leave immediately. The future you will wonder what took you so long.
Sometimes you have to risk. When I applied for my current job, I was sure I’m unqualified and they will reject me. They did not. When I wanted to move to another country, I was ready to leave my dream job behind - turned out there was remote position open, and I ended up with a promotion and salary rise. You can’t win big if you always play it safe.
Look outside of your field. The most important book on software testing I have ever read is titled “The Methodology of Sciences” and does not mention software testing, or software, a single time. I’m not sure if it even mentions computers.
I’ve learned a lot since I started my career in 2012.
Here are a few that come to mind:
People’s expectations on testing/testers can differ, it can be good to check you are talking about the same thing.
It helps to stay relevant in your career. Also good to know that what you actually need to know at work can differ from what employers ask for (they don’t always know what they should be looking for).
When bringing in change (and new ideas), your success in doing so isn’t just dependent on how good your idea is, but your credibility.
It depends. Every project has its own unique mix of people, processes, tools, and challenges.
You need to ask people what they want to know about quality - and then provide helpful information for them
You need to learn about tools and technologies every day.
There are no “loved” or “hated” programming languages for me. It’s all a matter of the task.
Talk to people in their language. Talk to businesses about money and risks. Talk to developers about vulnerabilities and performance or scalability issues.
Fancy languages and technologies come and go. Fundamental knowledge is always with you.
@adystokes I thoroughly enjoyed the entire article, it was simple yet elegantly written.
I found myself connecting with every aspect discussed in it. @sarah1
