There are many clear examples of dichotomy (mutually exclusive or contradictory categories) in the world. A light switch is on or off. A gun may have fired, or not fired. A software program is running, or it is not running. But many things we deal with are not dichotomous, but continuous. A person can be happy or sad…or somewhere in between. The temperature outside may be cool or hot…or somewhere in between. Indeed, some things in the world are black and white, but others definitely have multiple shades of grey separating the two concepts.
Differentiating between dichotomous and continuous variables is (IMO) one of the basics of critical thinking – which is probably why I’m annoyed when people in software look for dichotomy where it doesn’t exist. For years, Agile proponents have denounced anything non-Agile as Waterfall (I’m not even completely convinced those two terms are on opposite ends of the same continuum). Software testing, I’m afraid, has had it’s share of dichotomy misdiagnosis in the past, but does seem to be improving as the profession matures.
Some key examples include:
- Exploratory vs. Scripted. While it’s certainly possible to be entirely exploratory or entirely scripted in your test approach, grey areas between the two exist often in the testing world. I suppose you could say that if a test script contains exploratory elements that it’s really just ET, but see my example on Agile vs.Waterfall above for my reason why I disagree.
- Automated vs. Manual. It takes a lot of effort to have a fully automated test – most “automated” testing has some amount of “manual-ness” to it. The same can be said for manual testing. When I’m testing “with my hands”, I almost always use tools to help me. Registry and process monitors, macro recorders, and debuggers are all tools that (automatically) help me test better. The short story is, that there’s a really blurry line that fills the gap between automated and manual testing
- SDET vs. STE. Guess what – very few SDETs write tools and automation all day, and a lot of STEs I know write plenty of code (once upon a time, I wrote IIS server extensions to help with some test scenarios – my title at the time: SDET). I realize that these terms are Microsoft-ish, but although the titles are dichotomous, the roles are definitely continuous.
What other examples of misdiagnosed dichotomy have you seen?
Feature vs. Bug
Specialist vs. Generalist
There are indeed a few that come to my mind.
1. Test design vs. Test execution – It is common to find some bugs during test design. It is also common to design new tests or enhance existing tests based on one’s experience during test execution.
2. Regimented vs. Adhoc – Even a software development process described in detail cannot cover each decision point that arises during project execution. Similarly, a project being executed by doing what seems right will have the practioners following some process even if it is not overt.
3. Employee vs. Manager – An employee is expected to perform a number of management tasks e.g. time management, own task and schedule management, own career management. And we all know that a manager is an employee.
False dichotomies include:
Agile vs Waterfall – every single waterfall project I have ever been on has always ended up Agile in the end. By that I mean that always the testing finishes first -Then the final code is deployed – and Then last of all the documentation of ‘requirements’ is finalized… the precise reverse order to waterfall. You see that’s the way software has always been built – Agile merely stops trying to reverse the flow / push sh1t up hill! (hence why it saves time/money and removes conflict/resentment)
Polyglot vs Monolingual – I don’t believe I know any programmer that only knows a single programming language. Sure everyone may have a preferred language (everyone does, even if subconsciously). Generally everyone knows some form of data storage language (SQL, MongoDB DSL etc) in addition to a language they code with.