Many of us are used to the question during an interview wherein someone says: “what would your ideal role look like?” It’s a question that has an answer that is easy to envision for me, but not always easy to articulate on the spot. Recently I left a position where my role had to be replaced and the manager was asking for ideas on what kind of person would be a good replacement. I had to put myself in the position of someone coming into that role and what would have made me stay in that position.
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.
Using Lucid in Context, Part 1
Here I’m assuming you have followed the previous post and have a project set up and ready to go. This post will take you through using Lucid with Fluent and also talk a little bit about how you write your TDL and some of the considerations that go into that. This will be a fairly comprehensive post, attacking along a few different lines of thought.
Using the Lucid Project Generator
In previous posts regarding the Lucid tool, I showed how to use it in terms of its basic execution cycle as well as how to augment that cycle by calling out to an external library. In this post I’ll show how Lucid can help people get started with the tool by having it generate a particular project structure for you.
Using Lucid on Web Apps
In the previous Getting Started with Lucid series (see parts 1, 2 and 3), I gave a general idea of how to use the Lucid tool, with some broad brush strokes into the execution cycle as well as some of the options you can use to modify that cycle. Here we’ll investigate how to get Lucid to talk with another application that you want to test.
Starting Out With Lucid, Part 3
Starting Out With Lucid, Part 2
In the first post in this series I took you through some steps to use Lucid by creating the start of a test specification and seeing how that specification could be made executable. This post will continue the process, building on what was already created, but also getting into some details about the conventions Lucid uses for directories where it looks for files.
Starting Out With Lucid, Part 1
In a previous post I introduced the basics of Lucid. This post, and a few follow-ups, will be all about putting Lucid through its paces. If you have a Ruby system all set up, you just need to install the lucid gem. You can read the Setting Up Lucid instructions for more details.
Introducing Lucid
Tester as Learner
I’ve always been interested in the different ways that testers think and how those modes of thinking directly apply to the work testers do. What it comes down to for me is how people learn. This ultimately impacts how they evolve their career. And, in a somewhat loaded statement, how a tester has evolved their career tells me how useful they are going to be.
Seeking Conditions in TDL
Regarding my post on Seeking Requirements in TDL, a comment was made regarding the question of whether or not I was focusing on the conditions as part of the scenario and whether or not this tied into how I view requirements being made manifest in a test spec. The answer to both questions is “yes” but since that response may require a bit of elaboration, this post is my attempt at that.
Seeking Requirements in TDL
Regarding my previous post on this subject, a tester I work with asked me a great question regarding the readability of the TDL and the ability to discern the actual requirements from it. This post is essentially what my answer was. Whether my answer is good or not is up to the individual reader.
A TDL Communicates Intent and Describes Behavior
The goal of a Test Description Language (TDL) is to put a little structure and a little rigor around effective test writing, where “effective test writing” means tests that communicate intent (which correspond to your scenario title) and describe behavior (the steps of your scenario). Since those attributes should be what all statements of requirement strive for, this means that requirements and tests, at some level of approximation, can be the same artifact. That “level of approximation” is the point at which you get down to specifying the behavior that users find value in.
Let’s dig into this a bit more.
Continue reading A TDL Communicates Intent and Describes Behavior
Communicating In a Test Description Language
A TDL (Test Description Language) is a constructed language that we use to describe, and thus specify, our requirements as tests. Or our tests as requirements, if you prefer. This is what allows testing to be a design activity. What makes a style of writing a TDL is adherence to a structuring element and a set of principles and patterns that are used to guide expression.
Current forms of TDL swirl around various BDD concepts, such as Given-When-Then. But it’s clear that just having that focus in place does nothing for you by itself because there is a lot of thought that goes into how you want to express yourself. I’ve found many testers really struggle with this but, equally, I’ve found I struggle in being able to adequately teach at what level you work at with a TDL.
Continue reading Communicating In a Test Description Language
Building Simple Web Apps with Ruby, Part 6
In this post I’ll continue what I started in the previous post: using Sass. We’ll explore a different option around how to use this engine. Also, while I’ve focused on changing the CSS and HTML elements of our application, I’ve done very little with the JavaScript portion. So here we’ll explore that a little bit as well.
Building Simple Web Apps with Ruby, Part 5
In this post I want to switch around some of what we already did regarding HTML and CSS, by using “variants” of these. Specifically, I’ll look at Slim (to replace our HTML/ERB) and Sass (to replace our CSS).
Building Simple Web Apps with Ruby, Part 4
Following on from the other posts in this series, here I want to focus more on the static and dynamic content aspects. This will actually be fairly tame stuff for the most part but it’s a way to make sure we can do some of the basics with Sinatra — just in time to change them all around a bit.
Building Simple Web Apps with Ruby, Part 3
Here I want to focus more on the particulars of constructing a Sinatra web application. Up to now you basically have something that can serve up static or dynamic web pages. It’s time to get an application structure in place. This in turn will let us deploy our web application.
Building Simple Web Apps with Ruby, Part 2
This post continues on from the first one. That first post was a setup to getting the tools you needed. Here we’re going to put Sinatra through its paces and make sure we understand how it works so we can get on to creating an application.
Building Simple Web Apps with Ruby, Part 1
As a tester I’m often in a position where I want to write web applications for a variety of purposes. Most recently I wanted to make a simple test application that could be used to prove out my Symbiont test framework. Then I realized I wanted to deploy this application so that it would be available for a variety of purposes. I started looking into the simplest solutions I could find. This series of posts will cover what I learned.
When Business Needs Become Specs That Become Code
There is a distinction I want to make in this post regarding what you change in a test specification and how a test specification itself my change, in terms of the role it provides. That leads into a nice segue about how team roles also change. Here by “test specification” I mean the traditional “feature file” of BDD tools like Cucumber, Lettuce, Spinach, SpecFlow, and so on.
Continue reading When Business Needs Become Specs That Become Code