,
8 tweets,
2 min read
Read on Twitter
1) Please don't confuse the product with code we're writing. The code controls some machinery. The product is the sum of code, software platforms, machinery, and the experience and value that the user obtains. It's *very good* to evaluate the code; let's not leave it at that.
2) Apropos of that, please don't confuse *checking the build* with *testing the product*. Checking the build—and making building easy—is very important. Doing so— and fixing any problems that we find—makes it easier to test the product for hidden, rare, subtle, emergent problems.
3) Did I mention data? I didn’t mention data. Data loss, data corruption, data inconsistency, misinterpretation, inaccuracy, imprecision, misrepresentation, mistrust... Is the data checked for problems? What problems might the checks miss? Is data even getting checked at all?
4) Data is not often considered part of the product, but it had better be part of our testing. That includes making sure that data is accessible when and to whom it should be—but only then and to those people. Accessibility and security checking is available; do that for sure.
5) Keep in mind that the checks instantiated in checking tools are always made after insight prompted by imagination or discovery. The tools amplify our ambitions—or our lack of them. So consider using tools not only to check, but to aid discovery and epiphanies.
6) After we’ve checked the build, let’s also consider scenarios where all the components work as designed and specified, but their interactions lead to surprising and/or extreme undesired outcomes. Tools can really help; consider Monte Carlo simulations, varying rates and timing.
7) Did I mention documentation? I didn't. User manuals, API guides, tutorials, help files, help text are all part of the product too. So are specifications, requirements documents, diagrams, flowcharts, user stories, use cases, that guide development and testing.
8) All of these forms of documentation comprise things in, around, and about the product. Inconsistency between the product and any of them points to possible problems in them, the product, or people's understanding of it. So they are also oracles by which we perceive problems.
