Here I’ll talk about the difference between the terms integration and integrated when applied to testing. You may read that and say “Um, there is no difference, is there?” Well, let’s talk about it.
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.
What Can Particle Physics Teach Us About Testing?
Awhile back I talked about being cross-discipline associative. I did something similar to this approach when I asked what time travel could teach us about testing. Let’s see how this works with another domain entirely.
Continue reading What Can Particle Physics Teach Us About Testing?
Modern Testing and the Lucid Approach
Here I’ll cap off my current round of “modern testing” posts by discussing a bit about the lucid approach that I’ve brought up along the way.
Modern Testing and the Artifact Crutch
I’ve gone through a lot of posts on modern testing and I’m nearing the conclusion of my thoughts on this. (Or so we can hope, right?) Here I’ll recap a bit and then push forward.
Modern Testing and Unpacking Truths
In my previous post on modern testing and resilience, I indicated that testing and quality assurance spend a lot of their time, as disciplines, being in danger from their own practitioners. This is most often a problem when the disciplines are under pressure to change. Here I’ll focus on that a bit, with the understanding that these are obviously purely my opinions, even if they seem stated as fact.
Using Serenity with Cucumber, Part 3
Using Serenity with Cucumber, Part 2
In the first post of this series, I got us set up with a Serenity repository using Maven as our build tool. I also started us on the path of applying Cucumber-JVM by putting a feature file in place. In this post we’ll start tying Cucumber into Serenity’s runtime operations.
Using Serenity with Cucumber, Part 1
I’ve talked a bit about Serenity in previous posts as well as Cucumber-JVM. Here I’ll combine the two and talk about how to set up a simple Cucumber-style project. Along with this focus, I’ll be concentrating a bit more on the Serenity reporting as part of this.
Modern Testing and Resilient Strategy
In two previous posts (on design pressure and sources of truth) I talked about the context that a modern test team is often fitting in with. Here I’ll get more specific, particularly in regards to some strategic elements.
Screenplay Pattern with Java, Part 3
Screenplay Pattern with Java, Part 2
This post is following on the from the first post in this series. Here I’m going to dig a little further into the screenplay pattern, finishing up the execution of the test started in the first post. I’m focusing on the screenplay pattern itself here. That pattern can be applied in any programming language. I happen to be using Java, and I’m using a tool (Serenity) that already encapsulates this pattern.
Screenplay Pattern with Java, Part 1
In this tutorial post, I’ll begin covering how to apply the screenplay pattern with the Serenity framework. This is a “roll-up your sleeves and code” post. Here I will take a measured approach to demonstrating the screenplay pattern in the context of a working example.
Screenplays and Journeys, Not Page Objects
I wrote about Serenity with Java in a previous post. There I covered just the basics to get you up and running. Here I want to talk about what I think is the primary value-add of Serenity, which is its focus on the screenplay pattern. I think it’s beyond debate that automation engineers should know of this pattern and use it. It’s up for debate whether Serenity’s implementation is a good way to go about it. I leave answering that latter question to the reader. Here I just want to explore the idea as it is implemented.
Modern Testing and Sources of Truth
In a previous post, on testing and design pressure, I closed by saying that certain elements of decisions need to be encoded as artifacts, but that putting appropriate pressure on design meant minimizing those artifacts. Here I’ll talk a bit about that and what this means for test teams.
Java Automation with Serenity
Serenity is a Java-based library for test automation that wraps and extends WebDriver and JUnit functionality. Serenity also wraps around BDD style tools like Cucumber and jBehave. It even has some nice Jira integration. These benefits aside, Serenity can be a little hard to wrap your head around so I’m hoping this in-depth post will aid automaters who want to give it a try.
Modern Testing and Design Pressure
I’ve recently had reason to give some training on my overall philosophy and rationale for the introduction of Quality Assurance and Testing into modern development environments. I’ll put up a few posts as an attempt to gather my own thoughts and check if my own thinking is consistent.
The Danger of the Technocrat Tester
If being completely accurate, I would have to title this post something like “The Danger of the Companies that Frame Testing as a Technocratic Discipline and Hire Testers Who Reinforce This View”. But that’s a really cumbersome title to write! However, I believe that the technocrat tester is a big problem in our industry and many companies are reinforcing this problem. So let’s talk about this.
Why Test Engineers Should Learn Geb and Spock
Awhile back I talked about why test engineers should learn Groovy. Here I’ll focus on two specific tools in this ecosystem: Geb and Spock.
Continue reading Why Test Engineers Should Learn Geb and Spock
Conceptualizing Test Intersections
In my previous post on intersections of testing, I set the stage for how testing is an activity that takes place at various points of intersection. Here I want to conceptualize that idea a bit more and provide some focus on what it means from an operational standpoint.
The Intersections of Testing
A lot of testers I know come across Joe Rainsberger and his declaration that integrated tests are a scam. This always leads to interesting discussions so I figured I would use this post to distill my own thoughts particularly because the opinions of “scam-based testing” are usually predicated upon a profusion of testing terminology.