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.
In the previous post in this series we were able to dive in a bit and get coding. That was a nice balance with the first post which put more emphasis on theory. In this post we’ll deal with some of what’s going on between the coding and the theory. This is where some of the practice comes in.
Here we’ll pick up from the first post and get to work with our machine learning, specifically focusing on getting a data set, exploring it a bit, and then doing some processing on the data to get it into a format that would be usable for a neural network algorithm.
This series will be part of my ongoing topic around machine learning. In these posts my goal is to allow you to deep dive into a common example for those first starting out in the subject. By the end of these posts you will have written and tested a neural network to solve a classification and prediction problem and come away with some understanding of a fast-growing trend in the industry.
