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.
Your Ideal Role in the Testing World
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.
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.