Posts Tagged ‘testing’

Quality Assurance (i.e. testing) Is A Roller Coaster

November 14, 2008

We are in the heat of preparing a new release, which will be let out into the wild next week.  The ups and downs of building a release are quite dramatic.  I’ll focus on testing for this conversation.  It is a funny set of emotions.  In the beginning, you feel like kid opening presents for your birthday.  After talking about new features for weeks, designing them, arguing about how the work, etc, you get your first glimpse of the actual new application and features.  This part is really fun.

The next phase is when you get into testing.  In the beginning, you find bugs but you get in a groove.  The bugs are usually in the new stuff, so they are relatively easy to find.  This part is good because you feel like you are really working.

The phase after this one is the toughest (the one we are in right now).  The application is really shaping up, and it is much tougher to find bugs.  On one hand, this is obviously a really good thing.  For the tester, it is really boring and tedious.  You search for things that are wrong and try to think of as many edge cases as you can.  Every now and then, you get rewarded.  As the days go by, it becomes harder to break things (again, a good thing).

Finally, you finish the testing phase and get ready to release the software.  The excitement builds.  We put up system notices letting our customers know.  Then we go to sleep knowing there is a shiny new present that will be waiting the next day.  In the middle of the night, the boys in Sweden do their magic and presto.  This is the REALLY fun and exciting part.  Hope this helps explain one small part of the software development process.

Executing a Major Software Release

September 11, 2008

As you probably know, we are gearing up for a major release of GroupSwim next week.  I thought you might be interested in the things we do to prepare for this event.

  1. Testing, Testing, Testing – Did I mention we test?  In all seriousness, it is the most important component of the process.  Quality and customer success are critical, so we try to avoid any and all bugs.  We also learn about the software by everyone pitching in on the testing process.  We often tweak designs and the user interface based on what we learn.  As good as our initial designs are, nothing trumps rolling up the sleeves and playing with the software.  As someone who sells and demos GroupSwim every day, I find there is no better way to learn it.  The engineering team takes the bugs we find and turns-around fixes overnight.  We are a well-oiled machine, but it takes time and effort.
  2. Technical Tasks – Rolling out a major release involves important technical tasks.  Once we take the system off-line to do the migration, we perform back-ups, checks, software migrations, queue-up requests, redirect URLs, and a host of other activities.  Since GroupSwim is a SaaS application, it requires a different set of tasks (and mindset) than traditional software.  We aren’t migrating one customer; we are migrating 1,000s. The engineering team does an amazing job in a very short time frame.  We do mock go-lives and test with copies of production data to make sure we are as rigorous as possible.
  3. Training and Help – When we roll-out software of this magnitude, we update everything.  The list of stuff we change includes but is not limited to:
    • The website.  This particular release will touch almost every page
    • Marketing collateral
    • Online help.  This is a big task when we add so many features
    • Seed content for new sites.  These are the discussions, documents and wikis we put in every new site a customer creates to give them a running start
    • Videos
    • Update the Pool.  This is our own customer community, so we put announcements, tips and tricks and other content on it
    • Demo sites
  4. Marketing Activities – When we create software of this magnitude, we want to tell the world.  Marketing takes a significant amount of effort.  For starters, we do the following:
    • Write and distribute press releases
    • Email past and present users
    • Reach out to bloggers and analysts
    • Email campaigns to leads and contacts

Every time we release software, we learn something new.  I’m giddy about this next one and look forward to a new stage in our company’s evolution.

Christmas in September – We opened our present this morning

September 2, 2008

For those of you who haven’t worked at a software company (nice move by the way), the first look at a new software release brings a palpable feeling of excitement. Our engineering team just released the first Test Candidate for our next release.  It contains the new wiki and a host of other new features. It is very exciting to see our wiki in reality after talking about it and planning it for the past several months. I can’t wait to see it out in the market and our customers using it.

The testing process is both exciting and boring at the same time.  For the next 2 weeks, we will hammer the system as hard as we can.  We’ll try to do everything we can to anticipate how users will use the system.  We’ll test the “happy path” (when people use the software they way we anticipated) and more unconventional use cases that users will undoubtedly try. Each day we go through as many iterations and use cases as we can, and file any bugs we find.

The engineers in Stockholm and here then fix the bugs we find as we sleep, make improvements, and release a new test candidate for us to start all over on the following day.  Starting next week, we’ll issue Release Candidates which will be closer to General Availability in quality.  We’ll do several of those and ultimately release the software in about 2 weeks.

This process is very similar to what other software companies use, but we have it down to a science. Wish us Happy Testing!

Testing: The Ever Dreaded Word

July 18, 2008

Testing. The very word can send shivers down my spine. In the sports realm, it means finding out who’s the fastest, strongest, most agile – and no one likes to be the slowest, weakest, or least agile. In school, it can mean a variety of things. It can mean a big exam that students spend hours, days even, preparing for. Other times it could mean an unpleasant surprise for students, intending to find out who has been diligent with their reading and who has not.

With all this prior experience with testing, I didn’t know how to react to the handful of threats thrown at me to test GroupSwim. First of all, I had no idea how I could possibly test GroupSwim. Would it entail testing GroupSwim or testing my own performance on GroupSwim?

Then I heard talks of finding and filing “bugs.” What could this possibly mean? I knew there weren’t insects crawling through the Internet, so was GroupSwim sick? I later realized that “bugs” were defects in the system that are fixed by re-writing the respective html. Is this what I would be testing? How would I find these “bugs”? The very idea that there could be bugs on GroupSwim baffles me. All the websites I visit seem to function easily and quickly – in fact, I would be upset if they didn’t. So does this mean that every website has a team of programmers constantly filing and fixing bugs? I guess you learn something new everyday.

In the end, testing was like a finger prick. Anxiety built up in anticipation of finding out what testing was, just like how it builds up between the time the doctor tells you you need a finger prick and when the nurse walks in with the stick and band aid. But then afterwards, it was like “that’s it?”  Naturally, it was very tough to find any bugs in GroupSwim since it is such excellent software;)