I do a lot of exploratory testing. So when I'm doing test planning, you'd think the "Approach" section of my test plan would be the shortest, right? Wrong...

I see a lot of value in thinking about, describing, and writing out how I'll approach my testing. So much so, that when I'm getting ready to execute what I think will be a particularly challenging charter, I'll take a few minutes to outline how I'm going to approach my testing. For some tasks, I might even write a short procedure so I don't mess something up if there's a factor or variable I want to control for while I'm testing.

My rule is that I should always be able to articulate how I'm approaching the problem. If I can't do that, I've got no business getting started with my testing. It means I've got some additional research to do before I'm ready. If I can outline what I'm going to do, than I'm ready.

It's difficult to look backwards and reflect on all the work you've done. If you've been working at the same place for 3+ years, I suspect you can't remember half the interesting things you've done. While you don't have to actually drag our your resume and make regular updates, you should create a log file of some of the interesting things you've done. Keep regular notes on tools, technologies, new techniques, recognition and awards, conferences/workshops/training, and other accomplishments. When the time comes to actually update your resume, you'll have a wealth of information to look through to help you build different resumes targeted at the opportunities you're interested in.

I'm invoking the pirate heuristic today and stealing from David Christiansen. Dave wrote a great set of tips on how to recognize when you're testing might be in a rut. In the post he identifies the following test-fatigue-symptoms:

• Randomly pounding the keyboard for data entry.


• Not taking good notes.


• Chasing esoteric bugs when you don’t have time.


• Not bothering to isolate bugs.


• An inability to think of any error scenarios to test.

Read his post for some tips on how he breaks out of a rut when he recognizes he's in one.

What ruts do you find you fall into? His "asdf" rut resonates with me, I know what one well...

It's fairly common for applications to pass sensitive information. When testing, it's our job to make sure that sensitive information, wherever it gets passed to, is stored in a way that's (at least relatively) secured. The first thing I look for is plaintext storage of information. Some common places to look include:

• file or disk (cookies, configuration files, temp files, etc...)


• the registry


• memory


• databases


• the GUI (urls, field properties, hidden fields, etc...)


• executables (I've never reverse engineered a binary, but I know testers who do - and they find license keys, passwords, and other key pieces of information)


• or even just information going across the wire

Checking for plaintext information for the list above is trivial for everything except memory and executables - and for those you can probably setup and learn the tools in a day or two. I find I don't check those two as often, but I do check the others.

Many websites have the requirement that transactions be SSL encrypted. When this is the case, you see HTTPS instead of HTTP in the address bar, and down at the bottom of your browser, you likely see a little padlock icon that you can click to pull up information on the security certificate being used. However, for whatever reason, sometimes websites choose to implement both secure and non-secure versions of their site. Other times, the web server can be misconfigured allowing HTTP transport when it should all be HTTPS.

A quick test you can do to see if both are available is to just try dropping the 's' from HTTPS in your address bar. For an example, check out https://www.getafreelancer.com/ - the site works under both HTTP and HTTPS. (I assume that's by design, but I'm using it as an example because there aren't many sites that support HTTPS and also support HTTP at the same time.) If you can access both HTTP and HTTPS, you might want to double check your security requirements for the site and/or your web server configurations. Also, some sites have portions of the site that are HTTP while others are HTTPS. In those cases you might want to come up with some listings of what should be only HTTPS and just check those areas of the site.