One thing I’ve found that’s helpful to me in my career as a tester is the ability to abstract information from one venue to another. Testers and especially those who do Quality Assurance activities must be reasonably adept at abstracting knowledge from one domain and applying it in another, all the while accounting for those parts that don’t apply in the new domain. There are many ways to look at this but here I want to consider problem solving as a technique. I’m going to look at the technique of problem solving in relation to the domain of combat. My goal is to show how you can translate aspects of the combat domain into your more traditional day-to-day scenarios.
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.
What Can Time Travel Teach Us About Testing?
I have long maintained that testing is ultimately about thinking. A lot of your work is going to be predicated upon spotting incongruous elements (whether in documents or application code), resolving potential ambiguities in what you read or see, and dealing with potential inconsistencies or outright contradictions. Sometimes people will frame problems in such a way that your ability to “solve” or deal with the problem effectively is compromised from the start.
A good way to practice your thinking skills is to apply them in an entirely different arena than software testing.
Continue reading What Can Time Travel Teach Us About Testing?
Acceptance Tests Are Just Tests
Some testers have problems conceptualizing acceptance tests as I described them in my post on writing tests from stories. The problem seems to be one of seeing how the concept of an acceptance test applies or translates to concepts they already know, such as test conditions and/or test cases.
Be Acceptable: Write Tests from Stories
In my post on Stories, Features, and Acceptance Tests I talked about a lot but I didn’t really cover the acceptance tests themselves. The tests are quite important. Keep in mind that the goal is to have specifications that are clear, sufficiently testable and falsifiable, and in line with client expectations prior to significant development or testing. In essence, the idea is to work out how a system would be tested as a way to check whether the requirements give you enough information to build the system in the first place. You shouldn’t dive straight away into how to implement something, but rather think about how the finished system will be used — i.e., acceptable use — and then double-check the requirements armed with that knowledge.
Acceptance tests should reflect the customers’ perception of when the application meets their requirements. This does not mean that such tests must be defined by a customer or business analyst but it does often mean that such tests are discussed with them.
But how do you write them? What do they look like? Well, let’s talk about that.
Stories, Features, Acceptance Tests: Which Am I Writing?
If you’re a tester that works in an environment where your teams practice test-driven development (TDD), behavior-driven development (BDD), or some other variation that sounds really similar, you’ll quickly be learning that people toss around terms like “story”, “feature”, “acceptance criteria”, and “scenario.” What they often won’t toss around is the context for those terms. That’s context is important to have because it depends entirely on how the terms are used in your environment. While there are not necessarily standards, there are lots of good opinions that have led to good practices in context. Liz Keogh’s Acceptance Criteria vs Scenarios and Matt Wynne’s Features != User Stories are two good examples.
As a tester, what do you have to know? How involved are you in these things? Is all this just for developers? If you’re writing stories, are you also writing tests? Is acceptance criteria the same thing as an acceptance test? Here’s my take on a few of these questions.
Continue reading Stories, Features, Acceptance Tests: Which Am I Writing?
Modularizing Descriptive Programming in QTP
In a previous post, I talked about how I prefer the choice of descriptive programming in terms of my QTP logic for recognizing objects. Descriptive Programming (DP) is a specific approach that QTP makes possible for constructing your recognition strings programmatically. Anyone who has had to modify SilkTest frame files or create XPath-based locators for Selenium will quickly realize that “descriptive programming” is really just a name that QTP has given to what many tools already make possible. In fact, it’s the Object Repository (OR) — the alternative approach in QTP — that tends to be a value-add of QTP beyond other tools, at least for some people.
In any event, my previous post was a little skimpy on specific details so here I’ll look at a specific example of modularizing some test logic using the descriptive approach in QTP.
Continue reading Modularizing Descriptive Programming in QTP
Should I Ditch the Repository and Be Descriptive in QTP?
QTP allows you to use what the tool calls Descriptive Programming (DP) as a way to write your automated test logic. This is really nothing more than a way of referencing objects, similar to the recognition method path (object strings) in Rational Robot, the GUI map strings of WinRunner, the tags and locators in SilkTest, or the selectors in Selenium. This style of object recognition is often put in opposition to another form that QTP allows you to do, which is store strings in the Object Repository (OR).
So which one should you use: DP or OR? Does it really make a difference? Are there advantages to one over the other? Can you use both? Should you? I’ll talk about all this a little here.
Continue reading Should I Ditch the Repository and Be Descriptive in QTP?
Testing with Cucumber, Capybara and Selenium
In a prior post, I talked about using Capybara and Selenium as just a few among many tools. In a related post on using RSpec and Capybara, I brought up the possibility that “the natural language parts are, in fact, the executable code.” This was in reference to the idea of code logic expressed as natural language in RSpec but that still required actual code that sounded almost like the natural language statements. Wouldn’t it be nice if you didn’t have to write it twice? You just write it one way and then it executes? The argument then might be to just write the code, and assume the intent of the test can be explained via comments or something else. But many people really wanted to keep the focus on natural language tests.
Continue reading Testing with Cucumber, Capybara and Selenium
Testers Relax … You Don’t Really Assure Quality
As a tester the bad news is that you’re not assuring quality. That’s also the good news.
Continue reading Testers Relax … You Don’t Really Assure Quality
Using RSpec and Capybara Without Rails
Building off of my post regarding spiking automated testing solutions, one thing I didn’t really do was show you any sort of effective coding practice there at all. In that post I was showing how to get a series of technologies working together for that old “sense of accomplishment” thing. What I want to do here is focus on using two of those technologies together — specifically, Capybara and RSpec — while also showing you how you can start to separate out bits of logic as you start thinking about how to construct automated test frameworks for testing browser-based applications.
Spiking With Open Source Testing Tools
If you are a tester that’s charged with automating the execution of a web application, there’s a fairly good chance that you won’t be using some of the cost solutions out there like QTP or SilkTest. There’s a better than even chance that you’ll be looking at open source testing solutions. If this is your first experience with such technologies, you might find it a bit daunting. Oftentimes the one thing you won’t find is a nice concise script that will at least give you a start. Complicating this is many blogs seem to indicate various tools all interconnect in some ways, or can only be used in certain contexts, leaving you to figure out a lot of the details yourself.
For me, when I look at these tools I need to know, as quickly as possible, if (1) they work at all and (2) if I can wrap my head around how to get started in the first place. Sometimes you just need a gentle nudge in the right direction to see how the technology works. When I practice with technologies, I create little “spike” files that do just enough to show me what I need to know. Here I’ll be showing you my spikes.
Why Do We Test? To Communicate, Of Course
“Perfection of means and confusion of ends seem to characterize our age.” So said Albert Einstein. I think that sentiment can be applied to tests and their role as a communication mechanism. When you get involved in projects that are focusing on “agile” approaches like behavior-driven development (BDD), I’ve found that you’ll want to make sure you keep focusing on how testing will have a focus on intent (what) as opposed to implementation (how). It’s easy for testers to fall into a group think mentality with developers, who are often pushing an agile focus with an emphasis on what amounts to quality of implementation rather than quality of intent. This means testers have to have a good answer to the question, “Why am I testing?”