The title of this article is actually a little too simplistic. It’s more about asking: “Will AI Truly Perform Testing?” Or perhaps; “Will AI Perform Actual Testing?”
I’m asking here: do testers understand testing? By which I mean: do testers truly understand testing? By which I mean … okay, you know what, let’s just dig in to the basis of testing for a moment.
In a previous post I talked about why I’ve stayed in testing. Here I want to be a little more concise around the idea of how you might frame testing beyond how it is normally described, particularly if you want to get someone excited about testing as a career choice.
I’ve focused on the danger of the technocracy before, which is where we turn testing into a programming problem. This has, in many cases, infused the interview process for test specialists as well. And yet automation is important! There’s no doubt that automation is a scaling factor and a way to leverage humans better. So that does bring up an interesting dynamic when you interview test specialists but where you hope to have some sort of programmatic focus.
We all know the situation, right? We find an “issue” but in many cases it comes down to determining whether our issue is something for the developers to fix or if it’s something for product to clarify. It’s often a question framed as “Is this a bug?” Hidden within that question is dealing with the protean nature of a “bug” in current software development.
This post will continue on directly from the first post, where I introduced you to the concepts as well as an application that can serve as a guide to some of the ideas. I highly recommend reading that first post for the context if you haven’t already.
In this two-part post, I want to cover the distinctions between integration testing and integrated testing as well as the distinction between edge-to-edge and end-to-end testing. I also want to show how this thinking should be leading testers to think more in terms of contract testing. And, finally, so all of this isn’t entirely theoretical, I’ll provide a React-based code example. That’s a lot to cover so let’s get to it.
I see a lot of companies who have trouble getting started with quality assurance and test positions. They do a lot of interviewing but make a lot of mistakes when bringing in those crucial first people that will let them scale for the future. These companies look for things like “ability to write test cases” or “knowledge of automation.” They don’t look for people who have specialized in testing. But what does that even mean?
I was recently asked my thoughts about questions scrum masters could be asked during an interview process, particularly in regards to their thoughts around testing and quality. This allowed me to think about the role of being a scrum master. Which in turn allowed me to think about how I would do as a scrum master.
I still see many testers talking about the number of bugs found as some sort of barometer of success in terms of effective testing. But lately I’ve seen this framed around the “quality” of bugs found, rather than just their quantity. Still, you have to be a bit careful here. Let’s talk about this.
You’ll often see questions about the practice of software testing that essentially boil down to this: “Which is better: manual testing or automated testing?” This is how many engineering managers do view the world and while they may throw in more words, what they are asking is that question. And the answer they generally come down to is: “Automated testing is better.” How do testers combat that? And should they?
I previously talked about some heuristics for hiring test specialists. There was an assumption in that post that you do, in fact, want to hire specialist testers. But, of course, that is just an assumption. Perhaps you don’t. And before you say “But of course we do!”, let’s talk about this a little bit.
I’ve talked quite a bit about the interview process for testers. Here I’ll try to distill some of that material around my experiences with hiring test specialists. By this term, I mean exactly what it sounds like: people who have chosen to specialize in the discipline of testing.
In the last post, we defined our neural network by providing it some specific hidden layers that will provide the basis for how the neural network model actually works. We were also able to dig in a bit to what’s happening behind the scenes. In this post, we’ll actually execute the neural network by feeding it the data and evaluating what gets produced as output.