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.
If you are going to have an AI that “does testing” — as opposed to some other activity like analysis or pattern recognition — you are going to have to move from a focus solely on perception and add the dimension of actions. I’m finding a lot of folks promising “AI-based testing tools” or those eagerly hoping for them are very much confusing this distinction. So let’s talk about it and, as we do, let’s create an illustrative example.
I recently talked about a focus on being able to test an AI before you trust an AI to test for you. Here I want to provide a bit more focus on how worth it this idea might be. But my goal here is not to dampen the spirits of those who want to build such tools; rather I want to suggest some of the challenges and provide a bit of the vocabulary. I want to give you a way to frame the current situation with AI and its value as a test-supporting technology.
A lot of testers are talking about how to use artificial intelligence (AI) or machine learning (ML) to be the next biggest thing in the test tooling industry. Many are in what seem to be a lemming-like hurry to abdicate their responsibilities to algorithms that will do their thinking for them. Those same testers, however, often have absolutely no idea how to actually test such systems in the first place. So let’s dive into this a bit.
This is the last of a four part series (see parts 1, 2 and 3). The goal has been investigating whether specialist testers have a role in machine learning environments uniquely distinct from development roles in those same environments. These posts have been getting you up to speed on what that might look like. Here we finish off that journey.
This post continues on directly from the first and second parts. I covered a lot of material in those posts so I can’t easily recap it here so definitely read those before reading this one. Here we’ll dig more into how a tester actually tests in this context but also look at testing as a framing activity.
This post continues on directly from the first one in the series. We’ll take the CartPole example we started with and continue our journey into how testing — particularly that done by a specialist tester — intersects with the domains of data science and machine learning.
As a tester are you ready to work in environments that are based in or around data science and machine learning? What will you actually do in these environments? How will you interact with developers? How technical do you have to be? Is it all just automated testing? Or do we still have room for a human in there somewhere? Let’s dig into this a little bit by going through a scenario.
This post continues on from the first part where I went over the high-level details of a tester getting involved in a machine learning context. I left off just at the point of introducing the algorithm and letting us get to work. So here, in this post, we’re going to dig right in.
I’ve talked before about the intersection of testing and AI as well as provided a series of posts, using a Pac-Man clone to further introduce testers into algorithmic searching. Here I’ll consider a really simple example of engaging with a machine learning example. I’ll focus on reinforcement learning, which often isn’t talked about as much.
For this post I’m going to be giving you all the commands you need to run algorithms through Pacumen. But I will note that the readme file of the Pacumen project does provide some context for you should you choose to play around with the project. You can also reference my exploring testing and AI post for more details on how to use Pacumen.
This post follows on from the first part. That post, and this one, are building up your understanding of the algorithms that you have to consider when you are a tester in a machine learning or AI environment, particularly when dealing with search problems.
The next two posts are follow-ons from the previous. The goal here is to get you set up thinking as a tester in a machine learning environment and specifically in the context of search problems. This post, and the next, will focus on making sure you have the basics of the algorithms.
Let’s continue the from the last post where you saw a working implementation of a learning environment called Pacumen. Here I want to provide you more details of the basis for this kind of work and use that as a springboard for thinking about how testers fit in these situations.
In this post I want to set the stage for some future posts regarding thinking about how you might work, as a specialist tester, within the context of an environment that is using machine learning and various artificial intelligence techniques. This is an area that I’m finding many testers are not ready for. To that end, I’m going to show you how to get my Pacumen code repository up and working. Then I’ll take you through a few exercises to put it through its paces.
What’s been interesting in the testing world — at least the part of it that I hang out in — is the application of different AI-based learning algorithms to the act of exploring an application and seeing what (if anything) that tells us regarding the algorithmic and non-algorithmic parts of the testing discipline. Let’s talk about this because I think is fertile ground for testers to be exploring.