I hit Dice.com to check out the local job market action, but instead of letting me go about my bidness, immediately the home page asks me to take a poll wherein I could win a Kindle. All the better for reading a $.99 copy of John Donnelly’s Gold, I think, so I click through to it.

And then I get to this particular bit of logical Möbius strip:

To clarify: The control is labeled What did you accomplish on Dice.com today? (Select all that apply)

However, not one of the checkboxes is labeled None of these.

So to continue to the next step, if you want to continue, you must lie. And remember, the entrance to this quiz is on page load of Dice.com. That is, before you have accomplished anything at all.

Me, I didn’t lie: I eventually checked Other and Specified I got a blog post out of it.

What’s the lesson here, lads and lasses? Read the labels of the controls you’re checking, and make sure they make sense and make sure any enforcement rules upon them make sense vis-à-vis that label text.

It's been a data-riffic week. It all started with a product comparison, then segued to a series of staffing questions, and is gearing up to conclude with a big bang load test. Suffice to say I've had a whole lot of paper shuffling around. These projects have two things in common: they're all dependent on the collection of large amounts of data; and their success depends on the clear presentation of that data to support my (brilliant, of course) conclusions.

So, how do we get our hands around all that data? And once we have a conclusion, how do we present it effectively?

Slice up the data. Then start over from the raw data and dice it an entirely different way. Repeat.

The point is to look at the data from several angles to gain comprehension. Let's take the product comparison as an angle. It was a pretty straightforward project: We need a CMS. Which one should we use? There are literally hundreds of CMSs in this world, and a whole lot of information available about most of them. Let's commence data analysis:

• Slice. Make a feature comparison table, showing which ones have the features we're interested in.
• Dice. Map out the release frequency of modules, showing how quickly these introduce new features (as a proxy for future feature development pace).
• Slice. Figure out the annual cost of each CMS.
• Dice. Describe the community around each CMS, including number of job postings/candidates, presence and activity in forums or other documentation, and breakdown of current users in our industry.

Etc. etc. etc. You get the point. The idea is to take the data available and look at it from several different angles. Each angle will point up some CMS that is more appropriate than others. By starting over each time, you avoid bias based on your earlier analysis. Collectively, the slicing and dicing produces a small list of really good candidates, and provides comprehensive grounds for argument.
So often we deal with large amounts of data, and it's easy to get overwhelmed and make a choice based on just a few data points and a rough guess. Take the time to cut through the data in a few ways, though, and your choice will not only be more obvious, it'll also be a better decision.

By James Whittaker

This will be my last post on this blog. Tomorrow is my last day at Google. It was a great ride and a great pleasure to work alongside such brilliant engineers. I will hand over this blog to another test director and then find a new place for whatever blogging I do in the future.

Follow me on Twitter (@docjamesw) if you are interested in where I land and to find my next blog outlet.

Peace.

So I installed the new full CD version of Intuit QuickBooks, which is adware designed to get you to buy a lot of Intuit additional services disguised as accounting software. Now, if you’re like me, you’re not into the intricacies of actual accounting nor the myriad business rules that the various state and Federal governments change upon a whim, but you rely on software and a good accountant (or, sometimes, an accountant, although I’d like to add my current accountant is a good accountant unlike previous engagements who continue to bill me a small amount every year for simply having my address in their files).

Where was I? Oh, yes. I was talking about trusting your application, particularly one with complicated rules whose violation might result in a prison sentence. You want to trust that application, don’t you? So do I.

But I get the software installed and get into the mandatory registration (that is, give us personal information so we can target more in-application advertising pop-ups to you), and I get confronted with obvious slops on the design.

To whit:

A couple missing lines and slurred text, probably caused by poor compression or sizing.

Next up:

A stray bracket in the corner.

Man, oh man, I can’t wait to find out what strange punctuation marks it leaves in my figures.

Do I trust the application? Not so much. Which is why I don’t use it for much more than a glorified check register. And if it continues with its unrepentant, unrelenting barrage of “Collect credit cards with Intuit!”, “Print checks with Intuit!”, “Let Intuit have access to all your financial accounts!” banners popping up before I can pay my bills, I won’t have to trust it in the future, as I move to Microsoft Excel where it’s nice and quiet.

Ilya Kurnosov asked an interesting question regarding my Avoid Trivial Bugs, Report What Works post. He was referring to my statement:

 

"Instead of figuring out what works, they are stuck investigating what doesn’t work.”

Ilya asked:

Why did you use "stuck" referring to context of the other testers? Isn't "investigating what doesn’t work" more important than "figuring out what works" (other factors being equal)?

I love that question.  It really made me think.  Here is my answer:

• If stuff doesn’t work, then investigating why it doesn’t work may be more important than figuring out what works.
• If we’re not aware of anything that is broken, then figuring out what else works (or what else is not broken) is more important than investigating why something doesn’t work…because there is nothing broken to investigate.

When testers spend their time investigating things that don’t work, rather than figuring out what does work, it is less desirable than the opposite.  Less desirable because it means we’ve got stuff that doesn’t work!  Less desirable to who?  It is less desirable for the development team.  It means there are problems in the way we are developing software. 

An ultimate goal would be bug free software, right?  If skilled testers are not finding any bugs, and they are able to tell the team how the software appears to work, that is a good thing for the development team.  However, it may be a bad thing for the tester. 

• Many testers feel like failures if they don’t have any issues to investigate. 
• Many testers are not sure what to do if they don’t have any issues to investigate. 
• If everything works, many testers get bored.
• If everything works, there are fewer hero opportunities for many testers. 

I don’t believe things need to be that way.  I‘m interested in exploring ways to have hero moments by delivering good news to the team.  It sounds so natural but it isn’t.  As a tester, it is soooooo much more interesting to tell the team that stuff just doesn’t work.  Now that’s dysfunctional.  Or is it?

And that is the initial thought that sparked my Avoid Trivial Bugs, Report What Works post.

Thanks, Ilya, for making me think.

James Bach has written up a list of heuristics around Testability. Definitely worth a read.

While we've touched upon client side caching in our series on Web performance, we haven't discussed how client caching has grown more rich and useful over the years. In the initial days of the Web and the HTTP/1.0 protocol, caching was mostly limited to a handful of headers, including Expires, If-Modified-Since, and Pragma: no-cache. Since then, client caching has evolved to embrace greater granularity. Some new technologies even permit the deployment of offline-aware, browser-based applications.

Browser Request Caching

The most common and oldest type of client-side caching on the client is browser request caching. Built into the HTTP protocol standard, browser request caching allows the server to control how often the browser requests new copies of files from the server. We discussed the major aspects of browser request caching in part 1 of our series. Over time, Webmasters have taken to using different headers to improve caching on their site, including:

Pragma: no-cache. This old directive is used mostly by HTTP/1.0 servers, and instructs a client that a specific response's contents should never be cached. It is used for highly dynamic content that is apt to change from request to request.

Expires. Supported since HTTP/1.0, this header specifies an explicit expiration date for cached content. It can be superseded by the value of the Cache-Control header. For example, if Cache-Control: no-cache is sent in a response, this will take precedence over any value of the Expires header.

If-Modified-Since: Since the HTTP/1.0 protocol, clients have been able to use this header to request that the server only send data if the resource has been changed since the specified date. If there have been no changed, the server returns an HTTP 304 Not Modified response.

Last-Modified. This HTTP/1.0 and 1.1 header designates when the resource was most recently changed. Browsers usually supply this value as the value of the If-Modified-Since header.

Cache-Control. This core directive, introduced in the HTTP/1.1 standard, specifies whether a response's contents can be cached, and if so, for how long. The header "Cache-Control: no-cache" obsoletes the "Pragma: no-cache" header of the HTTP/1.0 protocol.

ETag. The ETag ("entity tag") header is a hash value that is specific to a given version of a resource. It can be used by the client in conjunction with the If-Match, If-None-Match, and If-Range headers to decide whether it should generate a new request for the latest version of a resource. The format of entity tags themselves is defined in section 3.11 of RFC2616.

Note that this header and the Last-Modified header are exclusive; servers should set one or the other. The ETag header is new with the HTTP/1.1 protocol standard.

For modern applications, the good folks at Google recommend setting one of either Cache-Control or Expires, and one of either Last-Modified or ETag.

 

Javascript/AJAX Caching

With the advent of JavaScript and AJAX, more Web applications are downloading data dynamically. JavaScript developers can use the XmlHttpRequest object to fetch data in XML (or other) format, and display it in real time without forcing a refresh of the entire page. This presents opportunities for finer-grained caching based on the nature of the data displayed within the page.

AJAX applications can still use all of the browser request caching mechanisms discussed above. The resource requested by the XmlHttpRequest object will be stored in the browser's file cache just as other HTTP objects are. A given AJAX application can go further and make refresh calls to the XmlHttpRequest object using programmatic rules. In his article "An AJAX Caching Strategy", Bruce Perry shows how he uses a custom CacheDecider object that he wrote in JavaScript to determine when to update an AJAX display of oil, gasoline, and propane prices.

 

HTML5 Caching

Developers creating HTML5 applications can create fully offline-aware applications using the HTML5 ApplicationCache interface. The Application Cache uses a cache manifest file to specify which files in an HTML5 application can be used offline, and which files require a network connection. The manifest may also specify a list of fallback files for network resources when the user is offline. For example, instead of fetching the file /get-data.php when disconnected, the manifest can instruct the browser to display the file /offline.html instead. This manifest is referenced in the HTML element of an HTML5 app:

<html manifest="manifest.appcache">
...
</html>

 

Conclusion

Web performance optimization is very important, and today's Web application development team can boost site performance and improve its site's load testing scores by selecting from a variety of client side caching techniques. An effective client side caching strategy can reduce load times by several factors. The most recent innovations in client side caching, such as the HTML5 Application Cache, enable an application to run (though perhaps in a more limited form) even without a network connection present.

Over at Forbes.com, Susannah Breslin posts This Is Why Your Employees Hate You.

Basically, here three order list points boil down to 1)You’re hired into a new company and don’t get the lay of the land before you start making a mess, 2) You’re unlikeable, and 3) You are not a leader.

As you might know, I think #1 is very important, and I’ve harped on it on occasion here. When you’re hired in as a manager, you have (or have convinced someone that you have) skill and ideas applicable to leading people in doing whatever you’re managing. You might have led a team in some other industry doing something similar, or you might even have been working within the same industry for a competitor or some related organization. Be that as it may, you don’t know how things are done in your new organization, and until you do, you should probably avoid upsetting the apple cart with your new ideas and processes which are really only old ideas and processes that might have worked at your last employer. At your new posting, some things are done that way because they’ve always been done that way, but some things are done that way because they work for your new employer and new employees. Until you can tell them apart, you don’t know where your new ideas are improvements or impediments.

As to number 2, remember, lads and lasses, there’s a fine line between being a jerk and being confident and right. Regardless of which side of that line you’re on, people who don’t like you or what you’re saying will think and say you’re a jerk. So be professional, but be confident and tell people the hard truths. Clearly. Dare I say, bluntly? I DARE.

And for number 3, we’ve seen QA managers like this, haven’t we? Just glad to be sitting at the big table and unafraid to rock the boat. You’re not going to add anything dodging that responsibility, and when it comes time to trim budget, if nobody remembers you saying anything about anything, especially not saying anything that stuck up for anything, they’re going to wonder why you’re on the payroll in the first place.

So do what Ms. Breslin says. Or the opposite of what she says. You’ll be a better manager for it.

But know these are not the reasons QA hates you. QA hates you because QA hates everybody.

You know, when this blog first started, I used to noodle around existing Web sites, find errors on their Web forms, and do some commentary on them. I haven’t been in that habit for a while, so you might think the quality of applications in the wild has improved. Oh, but no.

Take the Progressive Insurance contact us form:

Now, if you don’t select a topic before you click Submit, it asks for a topic. But only a topic

When you select a topic, it changes the fields on the form to reflect what they want for that kind of inquiry (enquiry for our R.P. friends). If you click Submit then, it shows you a list of the fields you need to fill out:

But if you click the Reset button to reset the form, well, that’s not cricket (cricket for our R.P. friends):

You know, any time your form changes the controls on the screen due to AJAX or other techniques, it’s a different form. And it never hurts to check your reset button in various forms of filling out the form, especially if there are look-ups or state changes as you fill out the form.

UPDATE: Welcome, Progressive Insurance readers!

Here are the links and the slides from the APIL2012 keynote:

• Forrester research on water-scrum-fall
• Article summarising the research
• Specification by example
• Effect mapping
• Feature injection
• User story mapping

Almost no matter what process you use, there's almost always the idea of planning. RUP has its Inception Phase. SCRUM has its sprint kickoff and grooming. Even Kanban has a backlog and planning in the form of creating item cards. Apparently, we all really think planning matters! We may disagree about timing, how much we plan, etc., but we all like planning.

Planning gives us a lot of things:

• An explicitly-expressed understanding of what we're doing
• An explicit communication of how hard that is (points, hours, whatever)
• Accountability for how well we did (whether you call this velocity, signup, whatever)
• Insight into trends for macro planning (i.e., we get roughly X done every week, so this feature will be done in approximately Y weeks, give or take)

I'd like to make a counterargument: sometimes we shouldn't plan.
There are a lot of things that can be planned - features, data processing, even performance work. There are a lot of things, though, where planning is just guessing. Bug finding/fixing is a good example of this. "How long is it going to take you to fix all the issues we're going to find in this integration effort?" True answer: "Gosh I really don't know. Depends on what issues we find." Planning answer: "Umm... about 4 hours". With a long term concerted effort, you can figure out very rough estimates based on how many bugs you usually find in similar features and . You'll frequently be off by a bit, but statistically you can make it work out, again, with a lot of effort.
With some things and with some time periods, the effort of planning is not worth the benefit. If you can only plan with reasonable accuracy based on a lot of research and tracking, and if you don't have that, you can't plan with reasonable accuracy. Rather than just guess, consider skipping the planning.
For example, I worked with a company that was doing a big Christmas Day launch (yes, it was Christmas related). It didn't matter how good or bad it was, that was the date. We finished all the features with about two weeks to go. It was shaky, of course. If you did everything right, it worked, but we hadn't tried anything else other than the happy path. We had two weeks for testing and bug fixing and any tweaks. So we needed a planning session! Right? Nope. No way. We didn't know what bugs there were; we didn't know how long they would take to fix. Planning would have been a big guessing system. Better to get started, spend a few days learning just how brittle things were, and THEN we can plan.
Most of the time, we should plan. Most of the time we do plan. Every once in a while, we get to a point where planning doesn't make sense, and it's okay to skip it, at least for a while.

There are quite a few videos going round on YouTube about rubbish certain people say about certain stuff (YouTube it, some are very funny!).


I thought: "I should do a video about testers!" And here it is, I used me and the rubbish I say to get the content (so don't be [too] offended). Hope you like it:




I will endeavour to post cartoons in the very near future :)

Organizations that implement successful user acceptance testing can greatly reduce errors and business risks.

Madhouse “6″. From before many of you kids were born.

For testers, being skeptical is generally a good thing. When someone says, “Our application doesn’t have any reliability errors”, I, for one, am skeptical. I’ll poke and prod and (usually) find something they haven’t thought about. There’s power in skepticism. Last year, I led a team of testers in performing code reviews of production code. My hypothesis was, that while developers perform code reviews thinking, “Does the code do what it’s supposed to do”, testers think, “In what conditions will the code not do what its supposed to do. You can insert the comment about testers being pessimistic (or overly pessimistic) here, but in general, the tester mindset is to question statements that seem…well, questionable.

But it’s easy to go overboard with skepticism. Time and time again, I hear good testers apply their skepticism broadly and liberally. Some (paraphrased) quotes I’ve heard recently include:

• “Model-based testing is interesting, but it doesn’t work in a lot of places”
• “I’m skeptical of static analysis tools – sometimes they have false positives”
• “Metrics are evil, because someone may use them to measure people”

I agree whole heartedly with each of these quotes. However, I worry that folks are throwing the baby out with the bathwater. Model-based testing (just an example), is a wonderful test design technique for stateful test problems. Although occasionally someone will screw up the value of MBT by claiming that it’s the only test approach you’re ever going to need, it’s just another technique (and the perfect technique given the proper context). Static analysis tools are also awesome, but aren’t perfect It’s good to measure some things too, but sure, one can screw it up.

I’m trying to think of anything in my life that works perfectly in every situation, but I’m coming up empty. I run into situations nearly every day where someone has a good idea that will obviously work most of the time – but not always. Given these situations, we could just send them back to the drawing board telling them, “I’m skeptical of your approach, because it won’t work in situation z”, but it’s probably a better idea to have a conversation about the limitations, understand where and when the approach may fail, and discuss mitigation or workarounds. Instead of throwing out the idea of running static analysis tools because of the potential false positives, discuss the false positive problem. Find out what causes them. Tweak the configuration. Do whatever you need to do to ensure the value of the approach.

Over the years, I’ve found value in some pretty stupid approaches. It seems that we should be able to find more value from some the ideas frequently discounted.

Even if we’re skeptical.

"Smartphone" author Majeed Ahmad discusses present and future smartphone trends, including growing consumerization, democratization in the IT world, cloud computing and HTML 5. CIOs and other information technology buyers in the enterprise can examine how smartphones are affecting business.

Explore smartphone and mobile computing technologies and services with expert Majeed Ahmad, author of a new book, Smartphone.

As many of you know, my engineering career started in software testing. I'm in engineering management now, and spend most of my time building and managing teams, writing code (product code and test code), and handling technology strategy for various clients. I feel like that's important to mention up front: I am not anti-test.

But.

Well, here's the thing. I haven't hired a straight up manual tester since 2007. I haven't hired anyone to a test position since 2009. I've hired developers, contracted designers, even hired project managers and contracted documentation experts. But no testers. I know what kind of value a tester can bring to an organization... so why haven't I hired one?

Well, partly because the testers that we did hire mostly stayed. That guy I hired in 2007 is still with the company and still doing testing. The guy I hired in 2009 is still with the company, although he has moved into development. We're still getting the testing function.

There's another part, too. I've basically stopped hiring testers as an early team component.

The testing function is hugely important. We do want to know that what we built works and that it fits our customers needs. So why no testers?

Increasingly, I have other people who are embracing the tasks that used to be reserved for a dedicated tester:
- developers have survived - thrived even - while writing test automation
- product owners have been eager to use the product in a structured way
- customer service reps and implementation managers have been able to provide additional context about application usage and behavior
- improved monitoring points out problems in dev, QA and production, and makes the patterns behind them apparent so debugging is a lot easier

Now, for some applications I'd still hire a tester. I'd make that hire when I needed that kind of specialized knowledge. But that knowledge is becoming less and less specialized as more people start listening to the mantra that "quality is everyone's responsibility". We're seeing more people who test, even as I'm around fewer testers.

Test is not dead. Test is more pervasive and discussed than it has been for most of my career. The dedicated tester, however, is becoming more rare. And I think that's actually good.

Software consultant Nari Kannan reveals eight metrics that are most important in ALM in this tip.

As I'm surfing the net, or riding the subway, I notice ads that contain code. Usually they're ads for job sites or degree programs. Sitting on the subway is actually pretty dull, so I find myself playing that "what language is that?" game.

For example, this is an ad I saw today:



This one was for a job board (job boards play this game a lot). Other common advertisers are training or college programs; and tech or biotech companies. It's a fun mix of languages and styles. Here are some recent ones:

• a for-profit college: Java
• biotech company: C++? (I think?)
• a large college: Java
• the same large college: JavaScript
• a job board: that was totally not a language. We'll be polite and say pseudocode
• another job board: JavaScript
• a technology company: Perl

The use of actual recognizable languages is surprisingly high!
It's also interesting to watch how languages change. When I first started noticing these ads four or five years ago, the language was predominantly Java or Perl. These days I see a whole lot of JavaScript. I don't necessarily think that it says anything about languages you need to know, but it sure makes a subway ride more fun!