Testing in the cloud: Considering the risks

Article by Matt Heusser .

Cloud computing promises a huge number of advantages for software developers. There’s the ability to rent servers, to scale those servers out, to create new capacity on-demand and possibly even to eliminate the need for a physical data center.

Sadly, eliminating the need for testing isn’t one of them.

Instead of a list of common failure points and things to test for, I’ll focus on high-level risks. As a tester or IT professional, you’ll want to begin a dialogue about elements which are within your role to address. Let’s break these down into the following four areas: functionality, scalability, security and other business risks for cloud computing.

Functional testing

Starting with what doesn’t change much, functional testing remains functional testing, regardless of where it’s executed.

All the traditional rules still hold. You’ll want to perform quick attacks, break down the software into its business logic, execute domain modeling, conduct scenario testing and so on.

What will be different is how you create the environment. Unless you have physical servers you are “porting” to the cloud, you will likely need some sort of test set-up code. This code should be nearly identical to the production code, perhaps with a different domain name, less built-in scalability, or different data.

In other words, someone will need to test the process of building an electric data center, upgrading software within that data center, possibly saving the data locally. Are you that person?
Continue reading

Agile software development: Tips for writing testable user stories

Article by Mike Kelly

Many testers on Agile projects struggle to keep up with the pace the development team sets in terms of story delivery. In time-sensitive environments, it’s critical for the tester to get a leg up on testing by having clarity in what needs to be tested.

In addition, most Agile teams have extensive unit and functional test automation that tell the developer when she’s done with development on a given story. Given both of these situations, you’d think we’d be a bit more rigorous with how we write our stories to make sure it’s clear to both developers and testers what needs to be tested. In this article, we look at some simple techniques for making your stories practically test themselves.

Templates help you remember what’s important

There are a number of methods for writing user stories, and a popular technique for teams getting started is to leverage a template. One such story template that I really like is Dan North and Chris Stevenson’s story framework for behavior driven-development:

As a <role>, I want <feature>, so that <benefit>.

Here are a couple of examples:

  • As an unauthenticated user, I want to see the login link in the upper right hand corner of each page, so I don’t need to navigate back to the homepage or some account page to login.
  • As a sales associate, I want to be able to pull up my current active leads, deals and tasks on my iPhone, so that I can still follow up with clients and update deals status while traveling.

Those look good right? You get an immediate feel for who cares about this story, what they want, and why they want it. However, when most teams write stories using this template, what typically happens over time is something like this:

  • As an unauthenticated user, I want to see the login link in the upper right hand corner of each page.
  • As a sales associate, I want to be able to pull up my current active leads, deals and tasks on my iPhone.

It’s exceedingly easy to leave off that last piece of the story. To the person writing the story, it’s obvious why the user would want that feature. However, to the developer and the tester, it’s not.

For example, with the first story, I might conclude that the login link in the upper-right hand corner of each page should take you to a login page. However, when I read the original story, it’s easy for me to see that the benefit is fewer clicks to login — the user doesn’t want to leave the current page to authenticate. With that knowledge, I can design an Ajaxy solution to keep them on the current page and still authenticate.

Don’t leave the benefit of the story off of the story. Even if you’re not using a template, make sure it’s clear why this feature is important. That gives powerful insight to the developer as they design the solution. It gives valuable insight to both the developer and tester when they assess risk for what should be tested.
Continue reading

SOLID design

SOLID

Enough chatter, let’s get to it. SOLID is an acronym. It stands for:

  1. Single Responsibility Principle
  2. Open-Closed Principle
  3. Liskov Substitution Principle
  4. Interface Segregation Principle
  5. Dependency Inversion Principle

Please see article here.