Pathfinder Blog
Topic Archive: Requirements

Testing

Scot Witt, Thursday, May 15, 2008 @ 4:22 pm

Let's have a little more compassion for the QA Team, eh?

Well, actually, the Design Team disguised as the QA Team.

The little frustrations, system and function failures result in a lot of dog-kicking, huge antacid and alcohol intake and a lot of whining. I begin to understand how little-person tossing may have started down under a few years ago. Obviously QA Teams at the pub got this trend started.

The academics have broken testing up into five or six TLAs (Three Letter Abbreviations designed by Consultants so they can charge more and use more buzzwords than normal people). You got your UAT (User Acceptance Test), your Unit Test, your Sanity Check, your boundary test, your Automated Regressive and Non-automated Regressive series (this means high school kids who click and chew gum while re-Ghosting machines) and on and on.

These labels are obviously created by people who don't do testing.

Us testers use language you shouldn't put on a blog.

This blog started because I had to do a complicated test three times today before I got the dang thing right.

I wrote the test script, had to change it four times because it wasn't really testing what I wanted it to test when I was writing it yesterday. Funny thing. I had the developer who created the function look it over for me. He said it was fine.

But each of those rewrites was one to three new database entries.

When I had it right and came to the end of the second phase of the three part test... the application didn't do what I wanted it to do. Totally unrelated to the test. ARGH!

I know.

You've been there, done that and have the tee-shirt.

Come to think about it, Our PM owes me a tee-shirt. 3XL, Ron, I've lost 45 pounds since 4/4.

Before I threw my laptop at the wall, I calmed myself by repeating the Tester's Mantra: If I didn't find it, the Client would.

The thing is, I don't mind writing Test Cases or even test scripts. I find writing them an interesting challenge. I also find doing them drudgery, akin to the constitutional prohibition against cruel and unusual punishment.

I wish I could get into the spirit of a real QA guy who thinks about these tests creatively and with wild abandon. You know, the fellow or gal who can think like a crazed end user ready to pounce on my poor application with abandon and relish.

Such folks are a treasure.

But with a small team, the lack budget for QA resources and the need to test major functionalities of a complex application, we Business Analysts, Information Architects, Project Managers and Receptionists will continue to click, type, spell check and screen capture.

And moan, groan and whine.

But it's gotta get done.

Oh, for the days when the BA and QA Lead managed the process and others did the work...

Topics: , , ,

tech development Tech Development

Another Way to Pair Program: Generating Requirements

Scot Witt, Tuesday, May 6, 2008 @ 12:13 pm

The CTO (Chief Technical Officer) tells the BA (Business Analyst- me) and the IA (Information Architect) to pair program.

He's our boss' boss.

He's our Agile ubermensch (mensch is a Yiddish-Middle German word meaning, in this context, expert, coach, guide, all around super star; I don't know if it is in Modern German, but our CTO will tell me, he's fluent in German. I took Latin and Spanish).

We gotta do what he says.

I whine that I write faster than the IA.

The IA complains I can't do wireframes as fast as he does (true, VISIO isn't as easy as it looks, kids).

We are despondent and snarl at each other. Pitiful.

An idea.

How about we split the requirements in half. I pull the ones I wanna do, the IA grabs the more visually oriented ones. We write 'em up, do the wireframes and then have the other edit and comment on the other's work while we collaborate on the items we need to.

It allowed me to spit out the bug repairs like a machine gun and freed our IA into drafting wireframes and workflows he needed to do without slowing me down. While we edit the other fellow's stuff, we find small errors, ask some questions and significantly improve the requirements without turning them into novels.

The benefit was to the Developers who had very spiffy, concrete, succinct and directed requirements before the iteration started. They had time to read them, ask questions and begin their design work. The client was able to read them and sign off early making the sprint kick-off run smoothly.

The CTO gave his blessing.

And yeah, I started numbering the dang Business Rules to help the Developers, even though everything I ever learned about writing tells me non-hierarchal/unrelated lists should be bulleted. But it helps the developers refer to specific rules and my sense of technical writing dos and don'ts can suffer this arrow of outrageous fortune.

The Developers were not impressed. They like numbers. Especially ones with decimal points.

Turns out the PM (Project Manager) even likes the IBM-concentric deep diving numbering schemes of the 1970s. There's no accounting for taste, is there?

But I don't have to like it, do I?

Topics: , , ,

tech development Tech Development

It Starts with the User Story

Alice Toth, Thursday, March 6, 2008 @ 12:01 pm

Having recently been asked about the difference between a use case and a user story, I came up with this explanation:

Use cases detail the interactions between an actor and the system in a sequence of steps and are generally used to capture the functional requirements of a system before implementation. Because of their scope, i.e., they take in more exception scenarios, they can be too large to be used for iteration planning since they would be split across multiple iterations. Also, there is a bit of a learning curve to interpreting use cases which can leave the non-technical customer out in the cold.

A user story is a short description of a feature as told from the point of view of the user (generally your persona). They consist of one or two sentences written in the language of the user, and are used to estimate the degree of difficulty to implement (which ties in with iteration planning). At Pathfinder, we also include acceptance tests when we write the user story as a way to set out the criteria that determines when the story's goals have been met. Again, written in plain English so that both technical and non-technical team members understand what success means for that feature.

For our Ruby on Rails projects, we're writing our user stories in a format that'll help the developers convert them into automated tests using the Rails framework:

As a [role]
I want [feature]
so that [benefit]

From here we create the acceptance criteria, which we write as scenarios in a specific format (givens, events and outcomes) in order to help with writing the automated tests:

Scenario 1: Title
Given [context]
  And [some more context]…
When  [event]
Then  [outcome]
  And [another outcome]…

We'll then go on to create flow diagrams, requirements and wireframes to further flesh out the details of this feature, but it all begins with the User Story and Acceptance Tests.

Topics: , , ,

user experience design User Experience Design

We Don’t Need No Stinkin’ Requirements

Alice Toth, Thursday, August 30, 2007 @ 11:52 am

The other day I was reviewing a statement of work for a potential project when the client came to  the line item allocating time for requirements. Oh, the client stated, we don't need to gather requirements. We do Agile development.

*Sigh* This myth of no requirements needed seems to be prevalent lately.

Well I hate to break the myth, but projects still need requirements regardless of the method used for development. The reality is you can’t create something unless you know what it needs to do. In order to know what it needs to do, you need requirements (business, technical and user).

The differences come in with the methods for gathering requirements. Some teams make requirements gathering the central activity, creating documentation detailing everything down to the nth degree before development begins. Other teams put less emphasis on knowing all beforehand and instead start with sketches or three sentence "stories", knowing that details will be filled in and added as the project progresses. Side note: make sure you have some way of documenting those hallway conversations because, yes, those are actually requirements gathering and it's good to keep a record somewhere accessible by the project team.

At the most basic level, the purpose of requirements is to define the problem you're trying to solve. Whether your team waits for a complete definition of the problem before starting development or starts with the basic outline depends on your development method. But you still need requirements. After all, if you don't define the problem, how do you know when you’ve solved it.

Not sure how to write requirements? Check out my colleague's post: Writing Requirements

Topics: ,

user experience design User Experience Design

Unanswered Questions of User Research

Elyse Sanchez, Tuesday, June 6, 2006 @ 9:23 pm

Luckily, formal usability testing offers us the opportunity of conducting a near-scientific study of stimulus and response. We're able to cull prospective users from a pool of particpants, and screen them against  a carefully chosen list of attributes, including gender, age, computer literacy, and other specific qualifications--much more discrimination than the "real world" of users and links and happenstance allows.

When it comes to initial requirements gathering, though, we often (in the words of Tennessee Williams), "depend upon the kindness of strangers." There are at least three types of early user researh/requirements gathering whose success often depends upon the enthusiasm or engagement of the client. It follows that this pool of resources must be evaluated through the filter of operative agendas. Here are three examples of user research that can be potentially valuable if all factors are considered.

1.  Subject matter experts - an incredibly valuable asset for building site or application content. Always keep in mind that the SME's time is constrained. Keep your questions open-ended, but focused on the task.

2. Stakeholder interviews - keep in mind that the client probably has an incentive to obtain "buy in" with these interviews. While much independent data can be garnered from these interviews, pay close attention to the client's needs and goals with these interviews.

3. "User" interviews - at an early stage in the project, these people are probably anticipated or target users. Don't lose track of capturing data to build personas and actual user scenarios.

Topics: ,

user experience design User Experience Design

Requirements Visualization, V1

Charles Field, Thursday, March 30, 2006 @ 9:48 am

At Pathfinder, we have developed some responses born of our collective experiences to the problem of huge requirements documents.

The problem is that on a complex project, a network of interdependent decisions is constructed, then shoehorned into an essentially linear document. While this functions as a form to analyze these problems, it's very [linear] nature makes it... well, boring! Even developers and designers are human!

The functional result is that it ends up as a doorstop somewhere in the office, or finds a quiet angle of repose near a bookshelf and no one ever reads it. These typically represent months of work by large, passionate teams and great expenditures. Not an ideal outcome.

What can prevent this? With all our focus on our favorite personas, and the scenarios we construct to walk them through, it is easy to forget that the person who was just handed 150 pages of your careful work is arguably your most important audience.

Take a moment and review that the order of the parts feels obvious. Make sure that the document has a clear and accessible structure. This means a contents page with content areas that have immediately understandable names. Even though it may seem unnecessary to you, having spent the last 4 months on it, a general overview that orients a first time reader is appreciated. This sets them up for the detailed decisions that follow. Starting someone in the middle of these processes, as I too often see, tends to make people glaze over and just make it up as they go.

Comprehension is more important than brevity here - at PFA, we find that annotated pictures are far more specific & engaging than trying to describe with only text things that can be easily shown. If that adds pages to the document, it is a small price if it gets read and understood. These visualizations do not need to be elaborate. In fact, we are facile at understanding abstracted representations - look at the drawing languages of cartoons. The messages are clear, despite the fact that Mickey has only three fingers or Charlie Brown has a single squiggle that stands for hair.

In sum, showing what you intend is powerful, yet doesn't need to be elaborate in production. The other side of the coin is to spend endless amounts of time illustrating a solution at the expense of more iterations, but that's another blog.

Topics: , , ,

user experience design User Experience Design

About Pathfinder

  • We design and build extraordinary applications for companies looking to make the next great idea a reality.
  • learn more

Topics

Blogroll

WordPress

Comments about this site: info@pathf.com