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.
In the previous post in this series we implemented a neural network from top to bottom, essentially allowing you to see how everything works from the start of inputting data to getting results. In this post, we’ll start to create a very similar neural network but I’ll take a bit more time to explain some of the specifics. Fair warning: this is probably going to be the longest post in this series so far because there’s a lot to dig into.
In the previous posts in this series, we got a lot of terminology placed in context, we investigated our data set, we took a dive into some math, and we talked about the life cycle of a neural network. In this post, you’re going to get a rapid-fire tour of creating a neural network from start to finish. The goal won’t be to understand every aspect, but rather just to get functionality working that I can expand on for you.