Just Another Manic Cyber Monday: Are you Ready?

Once September starts to roll around it seems like everyone’s preparing for something, be it returning to school, the fantasy football season, corporate budget planning, or looking for deals on end of model year vehicles. For me, it’s the time of year when I help people prepare for Cyber Monday, which has become the biggest online shopping day of the year.

So, is your website really ready to capitalize on all that buying fervor? Think about it. By September, your company is surely finalizing new products and marketing campaigns for the holiday season. But all those preparations will be for naught if your website isn't up to the challenge of increased holiday traffic – especially if your ops group doesn't have a system in place to monitor and react to the impact of that traffic in real time. The truth is, if your organization doesn't have a strategy in place by early September, you have a scant few weeks remaining to put one together. After that is done, you’re at serious risk of becoming ‘that company’ – you know, the one that makes headlines this holiday season for a massive site outage instead of record sales numbers – and the risk increases exponentially with every week you delay. If your company sells products that people want to give as gifts for the holidays, Cyber Monday is likely to be the busiest day of the year for your website.

Read the rest of this post here.
 
--
Scott Barber
Chief Technologist, PerfTestPlus, Inc.
About.me

Co-Author, Performance Testing Guidance for Web Applications
Author, Web Load Testing for Dummies
Contributing Author, Beautiful Testing, and How To Reduce the Cost of Testing

I don't produce software systems.
I help those who do produce software systems do it better.
I am a tester.

Any Given Thursday – Digging into Nasdaq’s 3-Hour Outage

This has been an uncharacteristically bad week for web performance, with several major and historically reliable services reporting outages due to "network issues". In my (not always so humble) opinion:

"Insufficient available bandwidth causing an outage, however, bothers me. A lot. There is absolutely no good reason for insufficient bandwidth to cause an outage. Maybe a slowdown, but if a flood of network traffic (not a flood of traffic to your site, just a whole bunch of traffic on the same network as your site) leads to an outage, something is wrong, at least in my book."

Read the rest of Any Given Thursday
Read part 1 of my commentary in Any Given Monday

--
Scott Barber
Chief Technologist, PerfTestPlus, Inc.
About.me

Co-Author, Performance Testing Guidance for Web Applications
Author, Web Load Testing for Dummies
Contributing Author, Beautiful Testing, and How To Reduce the Cost of Testing

I don't produce software systems.
I help those who do produce software systems do it better.
I am a tester.

Top 10 Tips for Test Managers from STP Online Summit

I had the pleasure of hosting the another Online Summit, delivered by Software Test Professionals: Test Management: Bridging the Gap Between Tests and Stakeholders.  The online summit format consists of 3 sessions each for 3 consecutive days.  The sessions for this summit were:

• Invigorating Your Test Team – Anne-Marie Charrett
• Talking to Triangles – Dawn Haynes
• Mentoring Testers: Leading from the Inside Out – Brian Osman
• Getting Your Testing MBA – Catherine Powell
• Whiteboard Test Team Management – Paul Holland
• Test Management for COTS Applications – Virginia Reynolds
• Motivating and Managing Distributed Testers – Karen Johnson
• The “Testing Bubble”:  Motivating, Insulating, and Protecting Tester – Ben Yaroch
• Top Tips from the Summit – Scott Barber
• Speaker Panel – Scott Barber, Karen Johnson & Ben Yaroch

One of my duties as host was to try to summarize the most valuable nuggets of information from across all of the presentations into a "top tips" list.  This is what I came up with:

Scott's Top 10 Tips for Test Managers from:

Agile Sprint Sanctity Valued at Over $13M?!?

During STPCon last week (which, BTW, was fabulous, but more on that in another post, 'cause I've got to get this off my chest) I was a panelist for The Hard Stuff: Questions About Agile. During the course of the discussion, someone asked a question that I heard as the following:

"... but what should I do about our sprints getting messed up when [executive] comes in and tells us to stop what we're doing and add [feature X] before the end of the following week so s/he can finalize the $13 Million deal with [new client Y, but only if the feature X is implemented by then]..."

Let's Test 2012

The first (as far as anyone I know is aware) Context-Driven conference in Europe is quickly approaching. On May 7-9, 2012 in Stockholm, Sweden, Let's Test "A European conference on context-driven testing - for testers, by testers" will take place.

This is a CAST inspired conference, meaning that it focuses on in-depth exploration of topics, includes facilitated discussion as part of every talk (i.e. speakers don't get to "run out of time" as soon as they hear that "hard question") and conferring only increases between and after sessions. It's a fabulous format! If you haven't experienced it, and you are passionate about testing, you really want to -- it will change your perspective on conferences forever.

I am proud to say that I will not only be attending Let's Test 2012, but that I am honored to be on the program with some first-run content that I'm very excited about:

A Full Day Tutorial: Context Appropriate Performance Testing, from Simple to Rocket Science
A Keynote: Testing Missions in Context From Checking to Assessment
 

Trust is a Cornerstone to Delivering Business Value

In my last post about Metrics I introduced the notion of trust as it relates to Business Value by stating:

"Failing to trust 'the Business' does NOT add Business Value"

I'd like to generalize that statement further to say "A lack of trust that individuals or groups involved in the project are primarily focused on helping the business succeed undermines business value".

Now, I can only imagine the reaction many testers are having while reading this. For instance "If I trust the developer when they say 'This is fine, you don't need to test it', we'll have major bugs make it to production." And anyone thinking that would be absolutely right -- because that is not the *kind* of trust I'm talking about.

When I say trust, I don't mean "Trust others to tell you how to do your job" or "Trust others to do what you believe is correct/best" or even "Trust others to be successful in accomplishing what they have been assigned to accomplish on time, on mission, on quality, and on budget"

When I say trust, I mean "Trust others to approach their role with integrity" and "Trust that others are doing the best they can to make the decisions or take the actions appropriate to their role and responsibilities based on the information they have" and "Trust that if you haven't been assigned to do or to be the decision maker about something, that task or decision is better handled by someone else -- whether or not *you* have the information necessary to make sense out of why.

Business Value of (Software Test) Metrics

I was *totally* in the middle of another blog post when I came across the latest from Cem Kaner on context-driven-testing.com and after reading it, I (cognitively speaking) had no choice, but to save that other post as a draft and write this one -- and by that I mean, there's no way I was going to be able to focus on anything else until I got this down and out.

So, click the link below and read the post... no seriously, it's required reading for what I have to say. (Ok, if you want you can start at the line prior to the 2 bullet points about half-way down the screen -- the backstory is optional reading)

Metrics, Ethics, & Context-Driven Testing (Part 2)

Did you read it? No? I mean it. Go. Read. I'll wait.

Business Value of Testing: Find Bugs ≠ Mission

My introduction to software testing was as a performance tester. Before the completion of my first project, I had a firm understanding of the primary mission of performance testing. That understanding has changed very little to this day, though I have improved how I communicate that mission. Currently, I phrase the (generic) primary mission of performance testing as:

"To find how many, how fast, how much and for how long; to assist business w/ related technical and/or business decisions and/or; to support related improvement activities as prioritized by the business."

That certainly doesn't mean that all performance testing efforts include every aspect of that mission, but I'm hard pressed to imagine something that I'd call performance testing that includes none of the aspects of that mission. It is also true that I have experienced all manner of secondary missions as part of a performance testing effort (missions related to fail-over, and denial of service attack security, for example). Those combinations, permutations, variations and additions are all where context comes into play.

However; when I was first asked to help out with some functional testing, I quickly realized that I didn't really know what was expected of me, so I asked. As you might imagine, folks looked at me like I'd grown a second head... a green one... with scales and horns. After about the 4th time I asked the question, got a funny look, watched as it became clear I was serious and received some variant of the answer:

"Find bugs"

A Context-Driven Approach to Delivering Business Value

This is Part IV in a series of entries inspired by the following quote from the "about page" of context-driven-testing.com hosted by Cem Kaner:

"...However, over the past 11 years, the founders have gone our separate ways. We have developed distinctly different visions. If there ever was one context-driven school, there is not one now..."

And James Bach's blog update (Context-Driven Testing at a Crossroads):

"I’m the last of the founders of the Context-Driven School, as such, who remain true to the original vision. I will bear its torch along with any fellow travelers who wish to pursue a similar program."

If you haven't done so already, I recommend starting with:

• Part I: Is Testing Dead? Dunno, but the Context-Driven School Is 
• Part II: With the Context-Driven School "closed" what's next?
• Part III: Context-Driven School (of thought): "I'm not dead yet... I feel happy!"

---

So far I've established that I'm a Context-Driven guy. For completeness, I should also share that I'm a guy who is most comfortable operating as part of a healthy team that embraces Agile principles, but who recognizes that Agile is not the most appropriate or effective answer for all organizations, teams, or situations.

I've also noted that I find the notion of "product" in both Context-Driven and Agile principles to be too subtle of a reference to the fact that the propensity of software is developed in a business context for my tastes. This is mostly due to many, many personal observations of individuals involved in the process of developing and delivering software emphasizing some aspect of the software over business value -- from individuals who self-identify as Context-Driven, Agile or neither.

The reality that I have lived in since beginning my career as a technologist is that, business is the primary context-driver behind the development of the propensity of software and that money is the primary context-driver behind business (yes, I know, that's a broad generalization, with somewhat ambiguous qualifiers -- I'm going to ask you trust that I'm happy to support and specify that statement if needed, but for the time being, please accept the premise... at least while reading the remainder of this post.)