Building an exploratory test plan redux: Software cartography

A map is a visual representation of an area—a symbolic depiction highlighting relationships between elements of that space such as objects, regions, and themes. - http://en.wikipedia.org/wiki/Map

Testing software is like exploring new lands.  The same principles apply: There is an unknown something out there, and we want to turn it into a known something.

Putting systems into System Testing

System - A group of interacting, interrelated, or interdependent elements forming a complex whole.  - http://www.thefreedictionary.com/system

People mean different things when they call themselves testers, and people think different things when they think about what it means to test something.  People generally distinguish between unit testing, integration testing, system testing, and user acceptance testing.  But what does system testing actually mean?  Why is it, when we're "taught" about system testing, noone ever explains what a system is?

"Exploratory Testing" is a pleonasm

It's time to stop talking about Exploratory Testing as a subset of testing.  There is no "exploratory testing" and "other testing".  All testing is exploratory.  If it's not exploratory, it's not testing.

Building a test plan from Woe to Go using Heuristics, Mind Maps, and Test Charters

Creating a test plan can be a daunting task, especially when under time pressure.  "We need you to test this application and, oh, we go live next Monday."  How do you create a plan to test that is accountable, transparent, and structured, yet lightweight enough that can quickly be understood by developers, project managers, other stakeholders, and new testers that may be brought on to help out?  And not only that, but be created quickly?

We should be aiming to automate all our testing

You've heard it.  I've heard it.  This is my response:

Don't (explicitly) charge your clients for testing

Software development houses who write bespoke software will usually provide a quote to develop or customise an application.  Often, it's broken down into "Project management, requirements gathering, development, testing/QA, etc etc".  In my experience, it is a mistake to break testing off as a separate quote to give to clients.

Why?

Before we begin

"Many arguments appear to be about conclusions, when they're almost always about premises."

Before I begin, I think it's important to lay out exactly what I mean when I use certain words and phrases. Then if you disagree with me, you can decide if we're arguing about conclusions or premises. :)