In my last post on micro-frameworks, I got into the organizing principles of my Tapestry solution, by which the framework provides or supports a mechanism for the encapslation of and delegation to logic. Here I’m going to continue on that theme but with a focus on showing how the framework calls into the tests, rather than the reverse, and why I think this is a good design approach.
Author: Jeff Nyman
Anything I put here is an approximation of the truth. You're getting a particular view of myself ... and it's the view I'm choosing to present to you. If you've never met me before in person, please realize I'm not the same in person as I am in writing. That's because I can only put part of myself down into words.
If you have met me before in person then I'd ask you to consider that the view you've formed that way and the view you come to by reading what I say here may, in fact, both be true. I'd advise that you not automatically discard either viewpoint when they conflict or accept either as truth when they agree.
Organizing Principles for Micro-Frameworks
This is a continuation of my exploration into providing insight into micro-framework creation for automation, using my own Tapestry tool by way of example. The first post set the context and the second post focused on exposing an API. Here we’ll dig into exposing the organizing principle.
The API of a Micro-Framework
Here I’ll continue on with the introduction of my Tapestry micro-framework that I started in the first post. This time I’ll focus on a bit on how you want to create an API interface for your micro-framework.
Writing Automation Micro-Frameworks
Here I want to talk a little about test automation framework construction. Or, rather, micro-framework construction. I will use my own tool, called Tapestry, for this purpose. Tapestry is written in Ruby but what I talk about is potentially transferrable to your language of choice.
Testing and Machine Learning, Part 2
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.
Testing and Machine Learning, Part 1
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.
About Testing
Earlier I talked about describing my own role. I think what I said there is almost interesting. Interesting, for me that is. But I often find testers struggling to frame their value beyond “I find bugs” or “I help mitigate risk.” So let’s dig into this a little bit.
Technical Test Interviews are Broken
Here I’m not speaking to the people who are interviewing for roles in automation. I’m speaking to the people hiring them. The interview process is entirely broken in so many places. According to Eric Elliot, code-based interviews have always been broken. And he’s probably right. Sahat Yalkabov said something similar. He’s probably right too. But here I’m focusing on the companies and hiring managers that are exacerbating the technocrat problem. So let’s talk about this.
Testing vs Checking – A Flawed Argument?
Lately I’ve been seeing that the whole “testing” vs “checking” debate is now more used as a punchline than it is for any serious discussion around testing as an activity and tests as an artifact. Regardless of my perception, which may not be indicative, I believe that this distinction has not been very helpful. But let’s talk about it. Maybe someone will convince me I’m wrong.
When Do You Stop Testing?
The question of this blog title comes up often. The worst answer that can be given is: “When there are no more bugs.” It’s the worst answer because the inevitable follow up is: “But how do you know?” On the other hand, some people, upon answering this, begin providing a very convoluted answer. Here’s my take.
Testing Fundamentalism?
I phrase the title of this article as a question. This will be a short article. I don’t have solutions. I’m not even sure I have a problem. But I think I do. I think I’m sensing a problem based on observations. But maybe not. Let’s see if you agree or disagree.
Uncomplicate TDD and BDD
Similar to reframing agile, I encounter a (perhaps surprising) number of experienced developers who outright deny that approaches like TDD or BDD have any value and it seems like we need a reframing here. But, in fact, I’ve found it’s more a case of getting people to uncomplicate the ideas.
Reframing Agile
Lots of people seem to focus on whether agile has failed. Or whether it’s dead. Or whether it’s a methodology. Or a process. What you end up with is something akin to Edmund Burke’s denunciation of political factionalism: “tessellated pavement without cement.” In the testing world this is even more so the case given the oft-used phrase “agile tester”, which any test specialist should be against. So let’s talk about this.
The Danger of the Muddy Thinker
I talked before about tradition and dogma and not too long ago, on LinkedIn, I saw someone post yet another one of those bits of dogma in our industry without considering the context. The discussion that ensued showcased exactly the problem with simply regurgitating the “received wisdom” of others. So let’s talk about this.
Pacumen – Exploring Search Algorithms
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.
Testing Algorithmic Searching, Part 2
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.
Testing Algorithmic Searching, Part 1
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.
Testing Learning Systems
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.
Pacumen – Exploring Testing and AI
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.
Testing and AI
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.