TechDev

Testing

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

The Problem of Encoding H.264 In a Flash Client

Flash Player 9 introduced the ability to decode H.264 video format.  However, it cannot encode video as H.264 (although it does encode as H.263).

This is a problem for people who want to take advantage of H.264's ability to encode at a higher quality with a lower bitrate. There are a few vendors out there who propose to offer a solution, but some of the solutions require an extra download which isn't necessarily cross platform.

With the release of AIR, Adobe seems to be targeting the Desktop market as one of their future goals. Many existing desktop applications already support H.264 encoding (see iChat for a good example).  If Adobe wants to keep up with the desktop application market, it might be prudent to add support for encoding as H.264 soon.

Another Way to Pair Program: Generating Requirements

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?

.NET 3.5 Linq to Sql and IBatis.NET

I've been looking at some of the new features in the .NET 3.5 framework and have found Object Relation Mapping (ORM) very similar to IBatis.NET and NHibernate. In .NET 3.5, they use attribute based mapping between the underlying data table and entity class (Domain Object). For instance

using System.Data.Linq;
using System.Data.Linq.Mapping;

[Table="Books"]
public class Book {
    [Column="Name"]
    public string _Name;
    [Column="ISBNNo"]
    public string _isbn;
    ...
}

What you notice is the the class Book is mapped to a table called Books using the Table attribute and particular table columns are mapped using the column attribute on the Book class instance fields. Compared with IBatis.NET XML files; you would have to:

1. Reference the Book class using the <typedalias type="Namespace.Book, Namespace"/>
2. Create a ResultMap that exposes the Book class internal fields using <property name="ISBN" Column="ISBN">
3. Create the sql statement that references the resultmap for the Book class so IBatis.NET and hydrate the results. Below is sample sqlmap.xml file for Ibastis.net

<sqlMap namespace="Surveys" xmlns="http://ibatis.apache.org/mapping">
    <alias>
        <typeAlias alias="Book" type="Namespace.Books, AssemblyName"/>
    </alias>
    <resultMaps>
        <resultMap id="BookMap" class="Book">
            <result property="Name" column="Name"/>
            <result property="ISBN" column="ISBN"/>
        </resultMap>
    </resultMaps>
    <statements>
        <select id="GetBooks" parameterClass="map" resultMap="BookMap">
            select name, isbn from books
        </select>
    </statements>
</sqlMap> 

Furthermore, much of the guesswork required to create the parameterizes queries used to pull information from the database and load a collection of Book objects has been added. Simply creating a new Linq DataContext object, passing the connection string to the database and calling the generic GetTable<T> (where T is class name. in this case Book) is all you need to get the results, versus creating the individual sql in the xml file and calling one of the QueryForObject or QueryForList methods found for IBatis.NET.

Last but not least, Linq provides the programmer with built-in sql like keywords used to build expressions that  sort, aggregate and limit the original result set to some more specific or limited result result set without going back to the underlying database.

Although, this is a very simplicity view of mapping a database table to .NET class. This does give you a good picture to the additional overhead required to using IBatis.NET xml file mapping versus Microsoft's Linq to Sql attribute base mapping, and demonstrates how ORM is now built right into the .NET Framework. And, you be happy to know that your .NET 3.5 Linq to Sql applications will still run on .NET 2.0 because the new features are specific to the specific 3.5 .NET compiler.

One Way to Organize the Documentation for Wikis and Trackers in Agile

One of the most difficult things I've had to get my arms around has been how you put user stories up on a wiki.&nbsp;

The books tell you to put 'em on cards with a number associated to the title. The idea being the developer and BA use the card to open conversation about a feature or function to draw out the requirements. And then, when the iteration is over, you throw the cards away.

Well, Blinkey, it doesn't appear to work when your client is 800 miles away. You have limited access to the Subject Matter Experts. The client wants docs for the business team. We've got nothing to show them but the specifications we're supposed to throw out. Don't make no sense, no how.

The Agilites (pretty good, eh?) usually say the BA comes in to run JAD sessions at the beginning of a project and the team never sees them again. Then the books suggest you bring the IA in with a designer 'when needed.'

PFD joins development with User Experience Design.

That means the IA and I (the BA) are permanently assigned to the team. So we do the documentation, run interference for the Dev and Business Teams and help everyone talk to everyone else.

Nice. But. The teams that have an active business team member empowered to make decisions are very lucky. We have built in delays on Q and A. And unless we politely remind the Business Team to concentrate on what's in the current&nbsp; iteration, we can lose a great deal of productivity.

So. We've pulled some detail from fellow PFD'er Alice Toth and Agile Coach Dietrich Kappe and discussed between our Dev and Design Teams (the Design Team is me and the IA, marketing, it's all about marketing).

At the top level of the Wiki is the Release Master page. It contains the Iterations for that Release and links to each of the Iteration Pages.

The Iteration Pages have a live link to the Tracker application. Each item is linked. The items include the Tracking Issue (we use JIRA) and the Specification (User Story, work flow, business rules, wireframes and tests) for each Tracking Issue. Each Issue includes a cross reference link to the Specification and vice versa.

Pretty kewl, eh?

I sort of mashed the old specification form with Alice's User Story form (thanks again, Alice!).

• The Wiki Page Title is the User Story Title.
• Under the first header is the User Story. We've kept them to six sentences or less.
• Under the second header is workflow (task-flow for my UxD brothers and sisters).
• The third header is for Business Rules. If this goes over five, we start looking at splitting it up.
• The fourth header is the Wireframes. More than three and we start thinking about splitting the doc.
• The fifth is Tests. Two columns- one for action and one for expected result.

If we pour more than one User Story into the document, I'll place the test for each user story right under the User Story.

Advantages of this new system:

1. The docs are getting much closer to 'just enough' documentation.
2. The cross references are making it a lot easier for the developers since they're creating their technical documentation as they code and cross referencing everything in their browsers. In other words, it's easier for the developers.
3. Clearing out the crap lets the Design Team work ahead so we can have the developers read and research each Specification before the Iteration kickoff- we get better estimates and know when we have to go back to the client for more detail.
4. We know when the scope creeps- immediately.
5. The client has to approve before an item will be included in an iteration.

Disadvantages:

• Client confidence- for some reason the client wants the docs to dig a little deeper and be closer to Use Cases and complete functional specifications. So far, education seems to be mitigating this need.
• We made the shift in mid-iteration, so we still use a few old formatted specifications and the process isn't totally integrated yet- but this would be true of any change.

The key is the tests.

We hadn't included them until a month ago.

The Developers like them, as does the Design Team since it helps us all catch mistakes quickly and easily... if the design team missed specifying something, we revise before the specification ever leaves our browser.

And of course, Agile Development is test-directed development, we're getting closer and closer to that standard as well.

All in all, some fine changes.

Callback interfaces in Java == delegates in .NET (a Java developer's journey into .NET world)

After several years in Java/J2EE world, I recently started working on a .NET project. The motivation was to get to know the pros and cons of both world and leverage better ideas from each going forward.

Having used Apache Commons/Collections in Java, I longed for similar library in .NET. I am not sure if one already exists (quick google didn't turn up any result). However, considering that fact that Commons/Collections uses Callback interfaces a lot, it was clear that any such attempt would leverage .NET's "delegate" feature extensively. I couldn't resist trying to implement it myself. Here is what I ended up with.

So, in my case, I wanted CollectionUtils.collect() method, which transforms a list of object into a list of some other type of objects. This is a handy utility to unwrap/wrap an exising list into another list. So, for example, I have a List<StringWrapper> object in which each StringWrapper object is simply a wrapper around a "String" object. And let's say that I need to get a List<String> from List<StringWrapper> object.

In Java's Commons Collection I would use a call like this:

class StringWrapper {
    public String a;
    public StringWrapper(String a) {
        this.a = a;
    }
}

...
List<StringWrapper> aColl = new ArrayList<StringWrapper>();
aColl.add(new StringWrapper("x"));
aColl.add(new StringWrapper("y"));
aColl.add(new StringWrapper("z"));
List result = CollectionUtils.collect(aColl, new Transformer() {
  public Object transform(Object o) {
    return ((StringWrapper) o).a;
  }
});
...

Here CollectionUtils.collect() would be something like (a very lame version of what is in Apache's Commons/Collection library):

class CollectionUtils {
    public static <T, N> List<N> collect(List<T> list, Transformer<T,N> transformer) {
        List<N> result = new ArrayList<N>();
        for(T t: list) {
            result.add(transformer.transform(t));
        }
        return result;
    }
}

// Callback interface
interface Transformer<T,N> {
    public N transform(T o);
}

In .NET, we could replicate this code 1-for-1 and get the same result. However, .NET's delegate keyword helps cut the fat and provides for a lean implementation as follows:

public class Collections
{
  // a 'delegate' defines a method signature. Any method with same method signature can be used as callback method.
  public delegate N Transformer<T,N>(T o);

  // a function that takes a delegate method whose signature is declared by 'Transformer'
  public static IList<N> Collect<T, N>(IList<T> originalList, Transformer<T,N> transformer)
  {
    IList<N> returnList = new List<N>();
    foreach (T oo in originalList)
    {
      returnList.Add(transformer(oo));
    }
    return returnList;
  }
}

Here, a delegate is like an abstract method and my concrete implementation could be like:

string transform(StringWrapper str) // this method's signature should match the delegate declaration
{
  return str.a;
}

And the client call then becomes:

...
IList<string> result = Collections.Collect<StringWrapper, string>(listOfStringWrappers, transform);
...

Or I can do away with an anonymous delegate implementation as:

...
IList<string> result = Collections.Collect<StringWrapper, string>(listOfStringWrappers, delegate(StringWrapper str) { return str.a; });
...

 

Qualification of a Pair Programmer: A Good Listener

Be a Good Listener. We've all heard this phrase. As I experienced recently, it applies readily to pair programming as well.

I am currently helping a student learn Java while she is taking an algorithms class. Having had teaching experience in the past, I was able to teach her the basic stuff fast and well. It was mostly a one way street where I talked and she listened. As she grew more comfortable with Java, she starting asking non-trivial questions. I quickly realized that it was no longer a one way street. I had to make conscious effort to not discount what she said/asked and say what I had to say. It took us longer to arrive at a solution _together_ if I talked more than I listened. I had to resist the temptation to arrive at a solution _alone_ and bring her along; at her speed. To bring her along, I had to listen more and make an effort to understand what she understood and where she missed. This may seem counter-intuitive but I realized that it was best (in terms of code quality and long term sustainability of happy pairing relationship) when I listened to her and gave her just enough information to find her way instead of imposing my way onto her.

I understand that pairing with a newbie is distinct from pairing with your co-developer. But still, being able to align yourself to someone else's thoughts goes a long way in achieving better results.

Happy Pairing !

Fingerpointing

My index finger is about to explode.

Some clients  cling to the 'us versus them' mentality of old school
development. You know:

Them: "It says here in your very own document that when I click <Massage> the back panel of my chair would start vibrating, and it doesn't! Fix it!"

Us: "But the master document clearly states you need to install a Yamahoochi 45697 Vibrating Chair Back for this to operation correctly"

Them: "Where?"

Us: "Master Document 123, Section 56, Hardware Requirements, Sub 876, Chair Backs, sentence two."

Them: "What page was that again?"

Hoisted by his own petard indeed.

I was reminded of this recently when I asked a client why
his team was doing the fourth review of a specification about which we
just ended an hour long conversation. Her comment was, the
specification didn't accurately represent field which
they wanted set to read only. Originally they wanted to be able to change it.

My fault. The specification was written 9 weeks before, the client never reviewed it (nor did the development team). The changes were minor and the conversation had nothing to do with the field.

So the client initiated another full blown review of the specification, four days before we're supposed to start prototyping it.

I missed two areas I should have changed. The other four, I changed.

I am reminded getting everyone on the same team with the same dedication to assisting
everyone else appears to be an never ending
goal.

In a former life, I was a Senior Technical Writer on the Cause Team for a chemical gases company that had some fabulous tools for determining root causes.

Very good idea.

Very kewl explosions.

It turns out that checking to see if an LP cylinder is empty with your cigarette lighter is not a really smart thing to do.

And it's a really bad idea to lay blame and be done with it.

On an Agile Team, when fault occurs, no one's happy. The better idea is to ignore the person and deal with the fault.

1. Find the fault (what happened?)
2. Figure out the cause (why did it happen?)
3. Repair the fault (repair how it happened)
4. Make sure the fault cannot occur again.

My Six Sigma Green Belt is pulsating contentedly. Not so strange. The idea behind Six Sigma was Motorola's desire to reduce manufacturing faults to three per one million units produced. The mathematician/Speakers of Greek tell me that's what Six Sigma means. I just took a seminar, filled out a 34 page application and took a test- I dread the thought of getting a Black Belt.

When a team is developing something brand new, we're in a creative thinking space, Much of the time, some of the holes of the new pieces don't match up on the machine. Or the client remembers or sees something else that absolutely positively has to be included. Or we can make the end user's job easier and make them more productive in user testing .

So the Development Team rarely points fingers. In fact, most of the time I've seen the developer whose work is brought into question turn bright red and pressures him or herself to get a fix as quickly as possible. Everyone on the team looks for answers. And everybody learns as well. That's one of the reasons Agile Methodology for medium and small projects works best with highly motivated and senior level folks.

Which means I'm gonna keep my mouth shut, fix the specification and get back to the other stuff I have to do.

You'll have to excuse me for a little while, though.

I'm gonna go find an Ace bandage, soak it with water and apply it to my index finger so it doesn't explode.


Technorati Tags: fault finding six sigma team

Powered by ScribeFire.

Agilize Your Project Just Before the First Release- for Fun and Profit!

You're a full year into a multi-year multi=million dollar  project but the first actual release is seen o the horizon.

What does everyone do naturally?

PANIC, of course.

This time there was reason:

• Your deliverables have been fine to date and the architecture is rock solid (just as you promised)

• The Business Team is killing the Client Sponsor because the business team has exceedingly high expectations that should have been managed better.

• Your Client Sponsor is getting angrier and angrier because his reports people can't do parallel testing on the old and new versions yet because your application still has issues. He originally planned for six months of such testing and might get two weeks under the existing schedule.

• Your Client Sponsor's boss is demanding more functionality than your team can provide in a month of Sundays as it prepares for the first beta release and code freeze.

• Your DevTeam is pointing fingers at you and the PM because they suspect (rightly) the client will want features build through load and performance testing.

Well, what could have been a major disaster with a lot of egg running off a lot of people was avoided with a lot of team assistance and a lot of hard work. No wonder I like working on teams so much:


1. Analyze the Problem and Causes

We're in the first code freeze of my first Agile Project. It took a lot of doing.

The problem was:

1. Exceedingly poor communication
2. Lack of planning
3. Lack of managing expectations (on both sides)
4. Not using a more Agile approach sooner in the project than we did.

2. Experience Counts- Listen to It

Here's what our CTO (Chief Technical Officer) hammered into our heads:

• Practical Agile Methods
• The BA promotes communication between the Business and Technical Teams and acts as a day-to-day Project Manager for the Technical Team (high level- Technical Lead runs the team).
  
• BA needs to meet and talk with the Client at least once a day (preferably with the IA (Information Architect).
• BA runs the requirements gathering, documentation (just enough documentation), the non-SCRUM Meetings and handles the project calendar for the PM.
• The IA is the interface and usability Czar/Czarina.
• The Client controls the features/bug lists. But the feature/fix doesn't get on the list until the BA/IA translates the into documents the Developer can develop from.

Our PM is also the firm's Sales Director. He revised his role to be umbers cruncher/support for the BA/IA and Lead Developer instead of intermediary between the customer and DevTeam/BA/IA. Instead, the PM and the BA will buffer the Client together.

3. Take Concrete, Understandable Steps

Here's what I (the BA- Deputy Associate Assistant Project Manager In Waiting):

Defined terms for both sides in their own contexts. I originally started a Glossary of terms, but someone from UxD pulled it. It was never used, never updated ad never referred to. Never again.

• The business side didn't know a checkbox from a checkbook.
  
• The DevTeam had no idea what 'parallel testing' meant nor how deep it went (down to the field level for hundreds of transactions).

It got worse, then got a little better when we formalized the process and touch points. Now every feel confident in asking "what does that mean?" Oh, how my first radio news director would smile!

Explained, demonstrated and awarded control of the Agile-based process to the business team four or five times and adjusted it to make them feel comfortable in their Word, PowerPoint and Excel World.

I gave up on the business side using any of the new tools except the bug tracker. The wiki is an active tool for the DevTeam and a simple resource for the Business Side.

If they're more comfortable in Office, fine, the BA and IA will translate i the wiki.

Told the DevTeam categorically it had but two 'controls' on the process- agreeing/disagreeing to a list of iteration features/issue repairs and providing the Client options and potential results/mitigation strategies.

A Developer can ask why a feature is needed/wanted, but the developer can't say no to a feature. If there's violet disagreement, offer options, but when the client makes an informed decision, that's it.

Got both sides into two actual Iteration Planning Meetings to get an identified list of develop-able items together for the upcoming iteration. What a concept! Things began settling down with the first freeze/performance-load test iteration plan and eased significantly with the list for the first 'go live' release that follows immediately.

Despite my best efforts, the DevTeam wasted the two days I set aside for research and questions between the first and second planned iterations with little stuff like speeding up the transaction times on the servers.

Got the Client to think out loud. ow we have the rudiments of a road map. Another planning tool!

Early Results:

The respect meter is consistently rising on both the Business and the DevTeam sides since we moved to a more standard.

Now don't get me wrong.

When we started, only our highly experienced Architect was Agile proficient and he was moving us to this sort of practice. We needed a lot more leeway to get the base functions designed, win client support and rapport as well as train the team. But as usual, communication is always the first casualty in any engagement we needed planning and giving the features over to the Client badly. Hence the major change a bit earlier than expected.

Things are a lot calmer, the client is more satisfied now that he knows where items he wants may be developed (we're Agile- these plans and iteration lists are like vaporware- useful only to make everyone realize that any change means a push for the item originally planned for.)

I'll letcha know what happens as we continue down this path, but it looks really good and will allow us to get automated testing implemented along with regression ad unit testing fairly easily from my perspective...making us test-based developers a lot sooner than I thought.

Powered by ScribeFire.

Plug: Designing Invisible Interfaces Webinar

My colleagues Matt Nolker and Shalom Sandalow have put together a nice little webinar entitled "This Won’t Hurt a Bit": Designing the Invisible Interface.. For those of us writing Web 2.0 applications, there are some key insights here, such as: "interacting with the software is not the primary goal or responsibility of the user." So when you use those nifty Ajax widgets, think about whether you are placing a usability burden on the user or are using the power of Ajax to make the interface disappear.

Technorati Tags: uxd, webinar, invisible interfaces, usability