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
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?
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.
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.
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.
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.
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.
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.
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.
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?
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.
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?
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.
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.
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.
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
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
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.
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.
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.