IMO, production testing and "exploratory" testing are complementary, but incompatible activities. Production testing is the thing that a few people in the community denigrate as "checking," as they turn up their noses and deprecatingly sniff. 1/9
That’s the thing that tells you that the program actually works and is shippable. IMO, that process must be fully automated and integrated into your CI/CD pipeline. 2/9
It must be possible to check-in-test-and-release with an automated, and very fast, indivisible process that in no way involves human hands. IMO, production tests of this sort are created by the dev team, ideally as part of the TDD process, & checked in along with the code. 3/9
Testing of this sort is a skill, not a job title, and is tightly integrated into development. There is no separate testing org, or even "testers" on the team. It’s all part of dev. 4/9
Of course, for this to work, the team must work collaboratively, ideally as an ensemble, but at least with code reviews so that more than one pair of eyes is on the code at all times. 5/9
The second activity called "testing" is manual "exploratory" testing. I see this as more of a discovery process—an entirely separate process than development that’s more like product work—that happens on the side, in parallel to development. 6/9
Putting this sort of manual testing into the "value stream"—as a requirement for release—introduces waterfall phased gates with the concomitant delays and bottlenecks. It’s a destroyer of agility, and a huge antipattern. As an activity separate from dev, though? Sure. 7/9
If a bug is found in exploratory testing, it’s essential to immediately create an automated test for that bug and get it into your CI/CD pipeline. But, truth to tell, if a bug is found at this stage, I’d argue that your dev process needs work. 8/9
Frankly, I think it’s muddying the waters to call both of these activities "testing." I’d call the manual stuff "exploration" and the production-related stuff "testing." Calling testing "checking" fails to grasp the concept of CI/CD, and agility for that matter. 9/9

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Allen Holub

Allen Holub Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @allenholub

28 Sep
Dan Pink’s "Drive" (and his Autonomy, Mastery, & Purpose) is a great book, but he’s just a popularizer of other’s work, primarily that of Ryan and Deci, who’s life work (and vast research) went into their Self-Determination Theory. 1/5
They have many long books, but there’s a reasonable (tho simplistic) summary here: [tinyurl.com/y6ur7dks]. Self-Determination Theory identifies three factors: competence (Pink’s "mastery"), connection (or "relatedness"), and autonomy. 2/5
I’m much more trusting of people like R&D, who spent their lives doing peer-reviewed research, than a popularizer like Pink, so I’ll stick with those three characteristics as primary. Don’t know why Pink left out connection, but it seems critical to me. 3/5
Read 5 tweets
27 Sep
Asked "how do you manage your backlog?" First, my backlog is entirely user stories—no PBIs. Any tech work that does not make your customer’s work in the domain easier probably does not need to be done. 1/9
I put essential overhead (e.g. updating key frameworks) on a separate kanban board, not the backlog. Allocate a fixed percentage of your time to to overhead—say one day a week max—so that it doesn’t overwhelm real work. 2/9
Next, Make the stories small—something you can implement in a day or two. You can’t reliably estimate stories larger than that, so there’s no point in pretending you can. 3/9
Read 9 tweets
26 Sep
Recently, @GeePawHill tweeted about this very issue & I’m very much aligned with his thinking. For a long time, I avoided politics (and still resist most of impulses). The constant walking on eggshells was eating away at me, tho. You cannot separate the code from the person. →
@GeePawHill If I lose followers because they don’t like me as a person, I’m truly sorry to see you go, but I am who I am. I’d argue, in fact, that my thoughts about software dev and everything else are not separable. One follows from the other. →
@GeePawHill I believe what I believe, both about software & life, because I am who I am. One of the things I believe is that people should respect and watch out for one another. People who will happily kill people by spreading contagion are not good people in my mind. →
Read 4 tweets
25 Sep
There is not a customer on the planet who cares how many story points you complete this Sprint 1/5
There is not a customer on the planet who cares what your velocity or burn-down rate is. 2/5
There is not a customer on the planet who cares about your planned:done ratio. 3/5
Read 5 tweets
25 Sep
Was told "Increased revenue or customers are good for product marketing and to please the C level with some vanity but not a direct measure of success. Imagine trying to do that with multiple agile teams running in a larger org." 1/4
That’s wrong on so many levels I don’t know where to start. First, we are in business to make money. Arguing that that’s somehow a "vanity metric" is breathtakingly clueless about how businesses work. 2/4
Moreover, there is no measure for "success" at the team level. What matters is the system as a whole. Organizations are Agile, not teams. 3/4
Read 4 tweets
22 Sep
My friends who are Scrum trainers seem to be getting more and more annoyed with fake Scrum—a twisted perversion that people think is Scrum but isn’t—not at all what the Scrum Guide says or what they teach. 1/4
In other words, the same destruction of meaning that happened to "Agile" has happened to "Scrum." Even certification doesn’t seem able to stop that decay—you’d think it would slow the entropy down a bit at least, but it doesn’t. 2/4
Even the certified ppl ignore what they learn to get certified & descend into fake Scrum. People seem determined to twist things around to look like whatever’s familiar to them. Maintain the status quo at any cost, even when the status quo is a sh**t show that nobody wants. 3/4
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


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

Become a Premium Member ($3/month or $30/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!

Follow Us on Twitter!

:(