This post continues on from discussing the theory around path testing. Now I want to put some of that theory into practice. While this is geared toward testing, it by necessity jumps into the programmatic side of things. I think this is an important view for testers to have.
Path Testing: The Theory
Path analysis is often considered an activity that is done only by developers. In fact, path analysis is a technique that can be used by both developers and testers. I find many testers, however, who are unaware of this test technique or are uncertain of how to best apply it. So let’s talk about it.
Quality Is As Quality Does
The notion of a “QA team” can set up unrealistic expectations about who “mandates” quality and who is “responsible” for quality. We know quality by indirect means of how things function or provide value; not as a result of the actions of a team. Does that sound silly? Let’s talk about it.
Symbiont and the Context Factory
In the post on using page objects with Symbiont, the focus was on how Symbiont leverages the page object to allow test scripts to separate intent from implementation. This also allowed for test script logic to be concise in terms of its expression. Here I’m going to focus on how we can get even slightly more concise by adhering to a factory pattern.
Symbiont and the Page Object
In the post on going from Watir to Symbiont, I talked about how Symbiont encourages you to delegate as much as possible to the page definition. The reason for this being that page definitions get turned into page objects, thus allowing your scripts to rely on the page object to handle functionality, rather than having each automated script do so. Here I’ll explore that idea a bit more.
From Watir to Symbiont
Encouraged a bit after the fact by a Ruby test framework in 15 minutes, along with my own post on a slimmed down Ruby test framework, and coupled with my Dialect experiment, I reworked an existing framework of mine (Symbiont) from another framework of mine (Fluent). Here I’ll explain how to get started with Symbiont.
Starting a Rails App, Part 2
This is the second, and final, post in the series about starting off on a Rails application. In the first post the basis for a “Planets” application was created. I ended up with a database (model) and a functioning mechanism around that database that let me create, edit, and delete records (views). All of that was knitted together into a working application by a controller. However, those views have no validation on them. That means the database is not protected from bad data. I’ll fix that here and then focus a lot on how Rails apps are tested.
Starting a Rails App, Part 1
Many testers these days will find themselves in Rails shops and, even if that’s not the case, Rails is a good environment within which to build custom test solutions that require a database and a web interface. This is largely because when using Rails, you are using one of the most concise and expressive languages out there: Ruby. I plan to document some of my learning of the Rails ecosystem in two posts.
The Craft of Testing
Being a tester with an avid interest (and some practice) in fiction writing, I liken the craft of testing to the craft of writing fiction particularly because I found some correlations in terms of writing fiction and writing tests. (Oh, the opportunities for a few jokes there.) The focus I’m going to be building on here is really a similarity of craft or, more accurately, how there are similar thinking styles that translate between crafts.
Learning the Rails Way – A Tester’s Perspective
In a previous post I talked about learning Rails in a way that I wished it had been presented to me. Here I’ll focus a little on the salient facts about the framework that you will no doubt find elsewhere, but sometimes you have to distill it from surrounding material that gets in the way. Near the end, I’ll explain why any of this has relevance to me writing as a tester.
Continue reading Learning the Rails Way – A Tester’s Perspective
A Tester Learns Rails
I played around with Node.js in a previous post for web framework design. Now I want to explore Rails a bit. I haven’t found tutorials that I really like on Rails, at least for those getting started. Now that I have gotten started, some of those tutorials I did find are more helpful to me, but they weren’t as helpful starting out. So here I’ll write in a way that helped me learn more about how Rails is actually working, rather than just relying on the “magic” that everyone tells me is happening behind the scenes.
The Dialect Diary — Symbiont Reborn!
I have spent the better part of the last five years learning how to design effective and efficient test frameworks and libraries. I may actually be making progress. This post will detail a bit of why and show how the Dialect project has evolved into a radically new life form, albeit one that did exist before.
A Tester Learns Node.js
This is essentially a follow-on from my previous post on Node, mainly for the purposes of helping testers like myself figure out if it’s worth spending time on.
Why Test Engineers Should Learn Node.js
Lately I’ve found myself wanting to develop test solutions that essentially require a simple web server along with a lot of client-side logic. For example, a Gherkin repository interface is something I’ve been longing to do. I don’t want to learn Pylons (in the Python world) right now and while my focus is Ruby, I’m not too keen on the overhead and bloat of Rails. I’ve done a Sinatra app (Dialogic). Sinatra is sort of Rails-lite, but that doesn’t really help me with an optimized solution that is going to use a lot of JavaScript. Thus did I come across Node.js.
Post Job Opportunities That Attract Talent
Earlier I talked about the opportunity descriptions that I would like to see. Having these done poorly is a huge pet peeve of mine. Some of this is just the fact that companies go through recruiters. There are many, many good recruiters out there but, quite frankly, there are many others that simply don’t know how to get what clients need — and quite, frankly, some of the clients don’t seem all that in tune with it either. This post presents a case in point.
The Dialect Diary – Element Definitions
Dialect needs to support the idea of element definitions. Like assertion definitions, this is part of the generator concept, where methods are generated as part of Dialect’s operation. This is a core part of Dialect’s design that has to be as right as possible since pretty much everything else will flow from this.
The Dialect Diary – Assertion Generators
As part of Dialect’s operation, I want page and activity definitions to be able to assert aspects of themselves. This is different from the “assertion” you might be used to in terms of testing logic. This post will cover what assertion definitions mean and get into one of the key design elements of Dialect: the generator.
The Dialect Diary – Evaluators
Dialect supports the idea of evaluator methods. These will admittedly be some low-hanging fruit in terms of framework development, but they seemed like a good place to start. This post explains a bit about what an “evaluator” means and how they are used.
The Dialect Diary – Platform Objects
Dialect will use the concept of a platform object. Here I’ll explain what that means.
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