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

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.

Continue reading Using RSpec and Capybara Without Rails

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.

Continue reading Spiking With Open Source Testing Tools

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

Continue reading Why Do We Test? To Communicate, Of Course