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
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
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
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. →
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
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