This is essentially a follow-on from my previous post on Node, mainly for the purposes of helping testers like myself figure out if it’s worth spending time on.
Why Test Engineers Should Learn Node.js
Lately I’ve found myself wanting to develop test solutions that essentially require a simple web server along with a lot of client-side logic. For example, a Gherkin repository interface is something I’ve been longing to do. I don’t want to learn Pylons (in the Python world) right now and while my focus is Ruby, I’m not too keen on the overhead and bloat of Rails. I’ve done a Sinatra app (Dialogic). Sinatra is sort of Rails-lite, but that doesn’t really help me with an optimized solution that is going to use a lot of JavaScript. Thus did I come across Node.js.
Post Job Opportunities That Attract Talent
Earlier I talked about the opportunity descriptions that I would like to see. Having these done poorly is a huge pet peeve of mine. Some of this is just the fact that companies go through recruiters. There are many, many good recruiters out there but, quite frankly, there are many others that simply don’t know how to get what clients need — and quite, frankly, some of the clients don’t seem all that in tune with it either. This post presents a case in point.
The Dialect Diary – Element Definitions
Dialect needs to support the idea of element definitions. Like assertion definitions, this is part of the generator concept, where methods are generated as part of Dialect’s operation. This is a core part of Dialect’s design that has to be as right as possible since pretty much everything else will flow from this.
The Dialect Diary – Assertion Generators
As part of Dialect’s operation, I want page and activity definitions to be able to assert aspects of themselves. This is different from the “assertion” you might be used to in terms of testing logic. This post will cover what assertion definitions mean and get into one of the key design elements of Dialect: the generator.
The Dialect Diary – Evaluators
Dialect supports the idea of evaluator methods. These will admittedly be some low-hanging fruit in terms of framework development, but they seemed like a good place to start. This post explains a bit about what an “evaluator” means and how they are used.
The Dialect Diary – Platform Objects
Dialect will use the concept of a platform object. Here I’ll explain what that means.
The Dialect Diary – The Formation of a Test Framework
I’m starting yet another new test execution framework, called Dialect. I’ll be the first to admit any “dialect” posts will be self-serving in one respect: they will be my attempt to document to myself my own thought process as I go about creating the framework. That said, I definitely wish I had a resource like this when I was first starting out. So my hope is others will find value in what I’m providing, whether or not they ever use Dialect.
Continue reading The Dialect Diary – The Formation of a Test Framework
The “Which Language Should I Learn” Dilemma
A lot of times I get asked by technical testers the following question: “What language should I learn?” The rationale for the question is obvious: there is limited time and they want to focus on that which will do them the most good. The good news is: this is a false dilemma.
Continue reading The “Which Language Should I Learn” Dilemma
The Testing Focus Shift: Back To Its Roots?
There is a large debate ongoing in the testing community about how technical a tester has to be. I actually believe that a tester has to be technical enough to implement test solutions when they are most needed or know how to gather the skills to become technical enough. Pretty vague, huh? The problem is that it really depends on what test solutions you need and the skills needed to create them.
Continue reading The Testing Focus Shift: Back To Its Roots?
Put Thought Into Naming Your Test Tools
I have a really hard time getting behind the names of many of the open source test tools that are out there. Here I want to talk about that just a little bit and what I’ve been doing to combat that. I do realize that I am probably in the vast minority of people who are concerned about this issue.
Providing Data with Lucid Sequences
This post continues directly from Using Sequences in Lucid. In this post I want to show a bit about how sequences can be parameterized, from simple variable elements in statements all the way to the use of data tables.
Using Sequences in Lucid
With the release of 0.2.0, Lucid has the ability to use sequences as part of the test description language. In this post I’ll explain what that means and we’ll go through an example that puts this concept to use.
A Spec-Based TDL Primer
There are many references out there that discuss Gherkin, which is a structuring element for your test description language (TDL). So what I’ll be offering here is really nothing new. This post is simply a relatively concise look at the TDL pieces and parts in terms of how these elements can be used in the context of Lucid or related tools.
Connect Quantity to Quality
For those of you who have read my posts on test specifications you know that I tend to focus on the idea of writing requirements as tests. This, to me, is essentially a large part of the benefit of collaboration-based approaches such as those suggested by Behavior-Driven Development (BDD) practices. (Although I still prefer Business-Driven Development, but whatever.) What I like about this approach, among other things, is that it builds in traceability. And I like that because requirements traceability was always something that I had an issue with as my career developed.
Is Lucid Agile?
I periodically get asked if my Lucid solution is “agile.” The answer, of course, is no. It’s a tool. The better question is whether Lucid, as a tool solution, supports practices that are usually referred to as agile. So let’s talk about that.
Don’t Be So Negative … or Positive
Previously I talked about the distinction between positive and negative tests and why I felt such a distinction was not only unnecessary but also potentially harmful. This is still a topic that interests me because I run into testers who still like to make these distinctions.
Align Automated Test Language with Development Language?
I pose the title of this post as a question. My focus here is as a tester who sometimes has to work with Java shops that really don’t want to involve their developers with Ruby or some other dynamic language. I, on the other hand, do not want to give up the benefits of a dynamic language when I develop my automated test solutions. Yet I do want to involve the developers in test automation. I don’t want to use JRuby necessarily because it’s really just a complicating element of running Ruby on the JVM. What I want is to utilize the Java platform (the JVM) but look beyond the Java language to languages that are lightweight but also dynamic. Groovy is proving to be that.
Continue reading Align Automated Test Language with Development Language?
Why Test Engineers Should Learn Groovy
If you’re a Ruby programmer than, like me, you may have a healthy distrust of the bloated thing that is Java. That said, Java really does have a lot of good points and it would be silly for any tester to discount it. Well, more to the point, discounting Java, the language, for your test solutions may not be a problem; but don’t discount the JVM. There are other languages that run on it, Scala being one of them. Here I want to talk about a language that a Rubyist should feel right at home with: Groovy. So let’s learn to be Groovy.
What Can Hordes of Zombies Teach Us About Testing?
I already tried to figure out if time travel can teach us about testing and I wondered if military history might also have a few lessons to share. I was marginally surprised that when I saw the recent film World War Z, I found myself thinking about testing.
Continue reading What Can Hordes of Zombies Teach Us About Testing?