, 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.
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Michael Bolton
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!