Dialect will use the concept of a platform object. Here I’ll explain what that means.
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.
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?
Testing Games is Hard!
Actually, testing games is not all that much harder than testing other applications. What’s hard is sometimes being able to figure out how to test them well, given their numerous interfaces and means of interaction. Even harder is sometimes isolating the very specific, but very odd bugs that come up. I recently came across just this issue with a particular bug I found while testing a popular game.
Why Test Engineers Should Learn Scala
Technical testers are often in a role where they have to utilize a programming language in order to build their own tools. Many testers will focus on languages like Ruby and Python for those solutions. The reason for that is because in the open source testing community, those languages do tend to be the focus of test solutions, the usual reason being given that they are “dynamic” languages. I’ve been in that same camp for a long time now. But there are cool alternatives worth exploring.
Why Test Engineers Should Learn Ruby
Test engineers most definitely should have Ruby as part of their tool set. This post is not so much to showcase my clear bias for Ruby when writing test solutions. This post is rather to showcase with some evidence why I have chosen Ruby as my tool of choice. My reason is mainly because you can do so many cool things with Ruby that other languages struggle with, particularly if your emphasis is on creating a DSL.
Testers Should Be Cross-Discipline Associative
Cross-Discipline Associative? What does that even mean? I don’t know. It sounds good, though, right? What I mean by it is that testers take information from one area of thought (a discipline) and attempt to apply it to their own area of thought. (Eating my own dog food, I tried this when I talked about ubiquity or looking at military history.)
Being perhaps a little more relevant here, I’ve come to the conclusion that just as we expect developers to learn from testers, more focus on this needs to occur from the other direction. I’ll be the first to admit: my ideas are still forming on this. Or, rather, my ability to express these ideas intelligently are still forming.
Continue reading Testers Should Be Cross-Discipline Associative
A Values-Based Approach to Systemic Test Team Problems
I was recently in a work environment where we had literally thousands and thousands of test cases that were stored in a tool called TestLink. A major problem was that there was very little impetus for the testers to ever really analyze all these tests or to ever question if TestLink was the most effective tool to be used. This was due in part to some members of management who, perhaps in fear of bruising egos or seeming too critical, basically said: “What we’ve done has worked.” When the testers heard that, they basically assumed: “Well, that means our testing has been good.” Eventually I came along and essentially argued that our test repository was a mess and that our tool of choice was not the most effective. Here’s a little of what I learned from that experience.
Continue reading A Values-Based Approach to Systemic Test Team Problems
Using Lucid in Context, Part 2
This post will clearly follow on from the first part where we created a project (called tutorial-web), created a test spec, created test matchers and test definitions based on the test steps in the test spec, and we wrote a page definition.