Joshua Bixby has an article about how third party scripts on your Web site can seriously hinder the Web site’s performance (Has your site’s third-party content gone rogue? Here’s how to regain control.)

In addition to the performance issues, you need to consider the following dangers and drawbacks of introducing third party code into your application or Web site:

• You have no control over what they do.
  Sure, they tell you they do something, but that might not be all that they do. For example, a number of years back, I recall a Web site visit tracker that provided a “free” version and a paid version. A lot of people went with the “free” version, which not only provided rudimentary statistics on your Web site, but also served pop-under ads. By that time, most browsers allowed pop-up blocking, this was not always the case, and the host was making money on its users’ content. The provider of this free utility did mention it was going to do it in the terms of use, somewhere around the term that said you could not use the Web counter on Web sites discussing John Norman’s Gor books (no kidding). So not many people read it.
   
• They can be an attack vector for malware.
  This is a corollary of the above point, but it’s worth noting in its own: Not even the third party vendors, especially ad delivery services, have control over what the code does. In many cases, that’s left to the person who buys the ad, and sometimes that’s a bad, bad man who wants to do bad, bad things to user computers and inserts attack code into ads that the third party code serves up. As a matter of fact, the last attack I know of on my client machine came not from a Web site discussing John Norman’s Gor books, but from the live stream page of KMOX radio, a CBS affiliate in St. Louis, where one of its ads tried a JavaScript exploit on me.
   
• You have no control over quality of the third party code.
  No matter how much or how little you test your Web site or application, you can rest assured the third parties test their stuff less (even if that is, in fact, a negative number). Many of the JavaScript errors I see when careering around the corners of the Internet stem from missing objects associated with third party code. This might not adversely impact your Web site, but we don’t like to deal with might not as a plan of action in QA, do we?

I realize this is a repeat of what I have said early and often throughout the almost five (!) years of the blog, but the above article gave me an excuse to repeat it again.

(Link via Scott Barber tweet.)

In this expert response, Lisa Crispin describes how the DevOps approach works on an Agile team and discusses the roles of the different team members.

I have a friend who is a teaching assistant in a local college. She teaches introductory programming courses, mostly to eager and not-so-eager 18 year olds. She's been working on engaging her students more, worried about the dropout rates from the Computer Science program.

So we were spitballing about the problem. And a lightbulb came on:
Let's gamify programming!

"Gamification" is - at least in the circles I move in - the hot trend of 2010-2011. Anything and everything is gamified, it seems. Shopping, fitness, training, surveys: you name it, it's probably been gamed. Gamification at its heart is simply applying the techniques of games to other systems. It usually means adding scoring or points, progress bars, leader boards or other challenges.

So let's gamify programming? Woo hoo! How would that work?

We were throwing out ideas like this:

• Points for shorter methods (rather than thousand line methods of doom)
• Leader boards for writing programs that accomplish their tasks faster
• Teaching test driven development (red-green-refactor is totally a game)

It's all nice, but really, for me, programming was already kind of a game. It's just a different kind of game. Anyone remember Black & White? Black & White was a strategy game that came out in 2001. It was a hugely ambitious game, in which you controlled villagers and a creature, and you had the power to make the creature good or evil (cue maniacal laughter here). Writing software is so much like playing that game, even without gamification elements.  Both things are immersive: I look up and discover that three hours have passed in the blink of an eye, and I have either a creature, or some new feature. It's frustrating: the game was hugely buggy, and writing code can sometimes mean intense effort to come up with.... 2 lines of code (woo too!). Both the game and the programming gives me a god-like feeling: in both the game and the code YOU made that happen (more maniacal laughter). 
I can't really get excited about gamifying software development because to me it's already fun in many of the same ways games are. Maybe that's just me.
But would you gamify programming? If so, how would you do it?

In this expert response, Lisa Crispin explains how the tester contributes to the release management process on an Agile development team.

XKCD uncovers a bug that QA should always find:

(Thanks to the most beautiful developer I know.)

I created the following cartoon for ExpoQA, a software testing conference in Madrid, Spain. I had a great experience attending the conference during 2010, one of the highlights was meeting testers from different countries as well as from different continents! I hope this fact comes across well with the cartoon, even if it's about bugs ;)

You know, reading horror books doesn’t keep me from sleeping like a baby (a colicky baby) at night. What do I read to give me chills and to keep me awake in the darkness, staring at the ceiling and contemplating dark things that might snatch my life away? Books like this book.

The subtitle of the book is And Over 100 Other Stories of Embarrassing and Funny Stories of Technology Gone Mad. It collects a number of humorous incidents where software or software-related processes have gone awry and made the papers, causing great embarrassment for the companies responsible. I wouldn’t call them epic fails, because in the 21st century, epic fails are fleeting. These are legendary failures still half-remembered and fully documented for posterity.

Reading through the book, one identifies some areas of risk to pay particular attention to if you’re trying to prevent your company’s failures from becoming the stuff of legend and Snopes articles. These include:

• Preventing the leak of test data.
  In many of the stories, great fun happens when test data or placeholder material goes into production. Such as the titular “Dear customer, You are a loser.” email or the “Rich Bastard” test name in a mail merge. When you’re creating test data, don’t be clever or wry, since that might leak out. Play it straight. And for Pete’s sake, figure out how to purge it before it gets out there.
   
• Review your CMS procedures.
  A lot of the news-stories-that-aren’t-real tales in this book come from instances where content authors somehow put their incomplete works into draft and they end up live on the Web site. This might be because the content management system has issues, or it might be because the content author has the ability to publish his or her own work and inadvertantly does so before the proper time. Sometimes, this happens without a CMS where code roll-ups get promoted with draft content. Regardless, you need to scrutinize those procedures to minimize the chances of this happening. As a bonus, one of the stories is about a journalist whose story gets promoted to the live site with disrespectful placeholders within it. Have I mentioned that’s a bad thing?
   
• Not understanding practices of the users and building in problems through ignorance.
  Then there’s the story about the guy who got a license plate that said NO PLATE and ended up getting the tickets for every car in the state without a license plate. Or at least those where the police officers had written No plate for a license plate number. If you don’t know what your users’ habits are, you can walk right into a problem where their habits conflict with your software’s interface and abilities.
   
• The impossible calculated numbers.
  The book is rife with the stories of impossible calculation results, such as the trillions of dollars in library fines, the bajillions of dollars in water meter charges, and so on. Does your software have a sanity check to flag outlying calculation results? If not, why not?

This book has a lot for the software quality professional to learn. It exposes patterns of failure we need to recognize and to account for in our testing and rolls up a whole lot of lessons learned meetings into a very browseable 300 or so pages.

Definitely recommended.

Books mentioned in this review:

Scott Sehlhorst explains how requirements management tools can aid in meeting business goals and discusses what actions to take to integrate portfolio management and requirements management tools.

Expert Scott Sehlhorst explains how goals shift in an Agile lifecycle and describes the impact of changes on the portfolio management process.

Apparently, they’re on the Blizzard servers:

The Diablo 3 servers are at full capacity, preventing many from playing the game.

Players across the globe are reporting “Error 37″ when trying to log in following Diablo 3′s midnight launch in the UK at 11pm last night and, just hours ago, on the West Coast.

“Due to high concurrency the login servers are currently at full capacity,” Blizzard wrote on the Battle.net forum. “This may cause delays in the login process, account pages and web services.

The best part, or worst part, depending upon whether you’re a mere observer or a customer who plunked down $60 for the game: Blizzard actually warned they weren’t going to have enough server capacity to handle their user needs in a blog post last week. And didn’t accommodate the usage spike until it happened.

(Seen via Fred Beringer tweet. I’m not a fan of the video game series. It reminds me too much of my day-to-day work.)

Here’s a book excerpt in the Wall Street Journal on improving your judgment of risk:

Most of us have to estimate probabilities every day. Whether as a trader betting on the price of a stock, a lawyer gauging a witness’s reliability or a doctor pondering the accuracy of a diagnosis, we spend much of our time—consciously or not—guessing about the future based on incomplete information. Unfortunately, decades of research indicate that humans are not very good at this. Most of us, for example, tend to vastly overestimate our chances of winning the lottery, while similarly underestimating the chances that we will get divorced.

Psychologists have tended to assume that such biases are universal and virtually impossible to avoid. But certain groups of people—such as meteorologists and professional gamblers—have managed to overcome these biases and are thus able to estimate probabilities much more accurately than the rest of us. Are they doing something the rest of us can learn? Can we improve our risk intelligence?

Sarah Lichtenstein, an expert in the field of decision science, points to several characteristics of groups that exhibit high intelligence with respect to risk. First, they tend to be comfortable assigning numerical probabilities to possible outcomes. Starting in 1965, for instance, U.S. National Weather Service forecasters have been required to say not just whether or not it will rain the next day, but how likely they think it is in percentage terms. Sure enough, when researchers measured the risk intelligence of American forecasters a decade later, they found that it ranked among the highest ever recorded, according to a study in the Journal of the Royal Statistical Society.

The excerpt says that you can improve your risk analysis abilities by getting immediate feedback. However, if you’re trying to answer the risk of deploying undertested software with the potential for hidden defects or if you’re estimating the chances of a discovered error occurring in the wild, that feedback might not be immediately available if the circumstances don’t occur until six months after the software is in use.

At any rate, it’s an article worth reviewing and maybe it’s worth getting the whole book Risk Intelligence: How to Live with Uncertainty.

George Takei shared this photograph on Facebook:

Class, who can tell me what’s wrong with this picture?

Agile expert Lisa Crispin explains the similarities and differences in Scrum and Kanban and describes how the two might be mixed using principles from both.

A Non Sequitor cartoon from April 9, 2012:

Strangely enough, QA does just that.

And, yeah, I am a month behind on the local newspaper. I’m even further behind on the Wall Street Journal, which means when I try to catch up on them, it’s almost like living as Time in Piers Anthony’s Incarnations of Immortality series.

Our family spent a bunch of time this weekend cleaning out the garage and taking care of a variety of long neglected household tasks. One thing I’d been meaning to do for over a year now is to get my Ducati up and running again. Between picking kids up (need a car for that), and riding my bike to work most of last summer, it’s probably been 18 months since I started the thing. Keep in mind, that Ducati’s are fickle machines to start with, but I figured I’d work on it for a while before calling someone to load it on a truck and haul it to the shop.

The first thing I did was drain the gas tank. I couldn’t recall if I added fuel stabilizer, but after that long, I can pretty much guarantee that the fuel was bad. I took the bad gas to the hazardous waste site (open on Sunday from 9-5!), picked up some new fuel, headed home, and gassed the Duc up.

I had the battery on a battery tender, but was still slightly surprised that it still had some starting power in it. Unfortunately, the engine just wouldn’t turn over. I double checked the fuel line (clear) and then pulled the spark plugs. The plugs were a little dirty, so I swapped them with a spare set from the toolbox.

Still nothing.

Sitting on the bike, I took a moment to think through how the engine worked. The starter was working, gas was flowing, but the engine wasn’t starting. Fortunately, I have a carbureted engine, and know what all (or most) of the engine workflow. There could still be bad gas still in the system, or there could be a problem with the carburetor. But neither of those seemed likely. I tried starting it one more time, and the engine just wouldn’t kick in.

While thinking through it some more, I noticed that I forgot to reattach one of the spark plug caps. I reattached it and…still nothing.

But – the behavior (i.e. engine sound) was identical with and without the spark plug cap attached – which pretty much guarantees that the spark plugs weren’t firing. I took them out one more time, cleaned them, and this time, checked the gap. For some reason, my spares were gapped really narrow (hint – always check the gap – even on brand new spark plugs selected for your vehicle). I widened the gap a few millimeters to spec, put them in and…

Vroom!

I immediately grabbed my helmet and gloves and went for a spin, and the bike ran great. No stalls, backfires or stutters. It probably still needs some more air in the tires and an oil change, but it sounds and runs just like a Ducati should.

In the end, this was just another debugging and diagnostic problem – much like the problems I face almost every day. The key points to remember are:

• Know the system, and think about the system. When software (or Ducatis) fail, think through the entire system to note where failures may be occurring
• Observe what’s going on – Products (and engines) fail for a reason. Chances are that there are unnoticed clues to the behavior you are seeing, so remember that anything you see may be helpful.

We're happy to introduce Load Impact 2.3!

Load Impact 2.3 contains a new and improved proxy recorder that automatically detects pages and creates page load time result metrics for each of your web pages. The recorder also allows you to insert code comments in the generated user scenario, which can be useful in order to find where in your user scenario code a certain page is being loaded.

Behind the scenes, Load Impact 2.3 also includes a lot of optimizations that result in a much faster reporting interface, especially for large tests that generate a lot of results data these optimizations will make a huge difference to how snappy the "view test" page feels. And for live tests, the reporting page will also be a lot smoother. In fact, Load Impact 2.3 is a major rewrite of the underlying storage subsystem and how data is being accessed by the user interface code. More things are loaded on-demand now (i.e. as/when needed) and this results in a page that is much lighter on the client computer. You should now be able to view even the largest tests on the flimsiest of laptops.

Other improvements you will find in 2.3 include:

 

• Graphical editor support for data stores, custom metrics and other new API functionality 
• Several API updates - http.page API functions, named parameters, etc.
• You can now plot graphs of load generator CPU and memory usage during the test!
• The URL list on the report page now displays bytes received and compression ratio
• Content type classification now uses the Content-Type header
• Click the pie charts to highlight different objects in the URL list on the test report page
• Many bug fixes...

 

In case any of you are wondering why I haven't been posting here, it's because my blog now lives at Peak Performance. I've tried to migrate all the content from here that I believe has historical significance to make things easy to find. I hope you'll continue following my work (and work-related rants) at my blog's new home.

--

Scott Barber

President & Chief Technologist, PerfTestPlus, Inc.

 

Author, Web Load Testing for Dummies

Co-Author, Performance Testing Guidance for Web Applications

Contributing Author,Beautiful Testing, & How To Reduce the Cost of Testing

In case any of you are wondering why I haven't been posting here, it's because my blog now lives at Peak Performance. I've tried to migrate all the content from here that I believe has historical significance to make things easy to find. I hope you'll continue following my work (and work-related rants) at my blog's new home.

--

Scott Barber

President & Chief Technologist, PerfTestPlus, Inc.

 

Author, Web Load Testing for Dummies

Co-Author, Performance Testing Guidance for Web Applications

Contributing Author,Beautiful Testing, & How To Reduce the Cost of Testing

“Indestructible” by Disturbed.

It sounds better really, really loud.

Imagine that you are load testing the website for a new loyalty card scheme. Millions of people will be mailed a loyalty card, and they will need to register their details online, along with their card number. Each card number may only be used once. So, every time you run your test, you will consume [...]