Why Quality Enigneer Perspectives Still Matter

I love dusting off old peices of writing I have done. It give me a chance to reflect and evolve my thoughts; to be retrospective and forward thinking. This post is exactly that. A look at how I thought about testing earlier in my career compared to how I think about it now. The tools have changed. The systems have changed. The expectations have definitely changed. But a lot of the fundamentals are still there.

You can view the full orginal post here on LinkedIn.

Where I Was (orignial blog)

Working for Quilmont, I have learned and developed new solutions for everyday testing practices. My old role as a manual tester was incredibly valuable, don't get me wrong, but in working with TCM (our patented test case managment tool), I truly believe through object-oriented scripting we could eliminate redundancy and speed up the process of getting a product to market. Manual testing and Beta testing are necessary, I am not saying let's have SkyNet run all of our test cases for us, and eliminate the need for manual testing; my goal is to say "let's look at the power of scripting tools and how they can improve your software process."

Particularly in mobile regression testing, Quilmont has aligned themselves with partners that make processes more productive. Take for instance Keynote Systems. Keynote's product Device Anywhere has a data center of hundreds of phones and tablets that allow you to execute test in a real time environment. Testers run though requirements, creating verification points along the way, giving the test a pass/fail criteria. Once the test case is created you can run the whole test with the click of a button (actions executed, fields populated, etc.) If you want a different variable, different parameters to be populated in your fields, in your parameters dialog you can create a database of different information to be brought in. In the test case you can select the parameter you wish to test with.

Anyone who has been in my role knows being handed an excel spreadsheet of 200+ requirements and test cases to test against a mobile application can be a daunting task. To put that in prospective, if you have one test case that uses 100 zip codes on a map application and verify that when you do put the zip in it takes you to the correct location. Instead of having to input and verify all zips and location, we can run one script that adds the parameters, and through objects, validate if the correct location was selected. This project's speed just increased tenfold! Now let's say you tested it on an iPhone 6 but you want to see your application on an Android. If a test is not device specific we can run it on ANY OS in the data center.

Through TCM we have the ability to better organize, run, and analyze test cases in multiple programming languages. With the ability to export results, bug reports, logs, and files to whichever central management tool your firm uses, Quilmont has a complete automated testing solution unique to your circumstances.

Where we are today with AI and whole-team quality ownership

A lot has changed since then, but in some ways, that core idea still holds: remove friction, reduce repetition, and make testing part of how you build—not something you do at the end.

The biggest shift is ownership.

Quality is no longer something that gets handed off to a QA team at the end of a sprint. It’s shared. Product, engineering, and quality all have a role in building something that works and keeps working.

The testing pyramid still makes sense. Unit tests at the base, integration tests in the middle, end-to-end tests at the top. That structure hasn’t gone away.

What has changed is what we’re testing.

We’re not just validating UI flows or API responses anymore. We’re testing data pipelines, orchestration layers, and in many cases, AI-driven systems. That introduces a different kind of problem.

You can’t always rely on deterministic outputs. You have to think about things like:

• how models behave over time
• how data is retrieved and used
• what happens when inputs change slightly
• how consistent your outputs really are

In systems that use retrieval or AI models, testing includes validating the data flow itself. Are you getting the right context? Is the response grounded in that data? Does it stay consistent under different conditions?

So yes, the pyramid still applies. But now there’s another layer on top of it:

• validating prompts
• checking model outputs
• putting guardrails around behavior
• making sure the system doesn’t drift in ways you didn’t expect

It’s not a replacement for traditional testing. It’s an extension of it.

Conclusion

Looking back, I still agree with a lot of what I wrote years ago. The tools were different, but the intent was the same: make testing more efficient, more repeatable, and more valuable to the team.

I did laugh a bit at my Skynet reference. That part didn’t age too badly.

What has changed is the scope. Testing today goes beyond application behavior. It includes models, data, and the way systems are stitched together.

What hasn’t changed is the discipline.

If you write clean code, test early, review your work, and keep your systems understandable, you’re doing the right things. That was true then, and it’s still true now.

The difference is that today, more people are responsible for it.

Quality engineering isn’t a phase or job position anymore. It’s part of the job... for everyone. Whether you are a Solution Owner using AI to write user stories with Rovo or an Accoutnant using co-pilot to build spreadsheets, congrats! You are a tester with human automony to say if a function or peice of work is complete and ready for others feedback to start the whole loop over again!