Every drug commercial you see on TV, half the commercial is a voice-over listing all the side effects, many of which are worse than the disease that the drug is intended to treat. May reduce your body’s ability to fight infection, which could lead to serious illness or death . . . “Death” is almost always in there somewhere. And these are drugs that have been through years of trials, full FDA approval, not just emergency approval or experimental approval or whatever it’s called for the COVID vaccines. What are the side effects of COVID vaccines? Who knows? There wasn’t time to test for them, except very short-term stuff like you might feel tired or you might have a sore arm. In the software business, we call this “testing in production,” meaning we don’t have time to fully test the product in a non-destructive way, so we slam it into… Read more →
EppsNet Archive: Software Testing
9 Links
Data Structure Visualizations Good Tech Lead, Bad Tech Lead Google Java Style Guide to 12 Disruptive Technologies How to Write a Cover Letter The Landing Page Optimization Guide You Wish You Always Had Selendroid: Selenium for Android UX Axioms by Eric Dahl Yelp’s got style (and the guide to back it up) Read more →
Agile, ALM, and Agile 2.0 — Putting the Cart Before the Horse?
Speaking of selling chickens still in shells, an august panel of industry giants laid out their recent improvements and plans for ALM products (Application Lifecycle Management, for those not in the know). These guys dazzled the audience with how they’ve moved far beyond simple source code repositories and testing tools to a complete integration of all modern software practices. Quite a coup, indeed, since most real live software developers I’m seeing out there today still aren’t using the practices automated by the ALM tools. . . . In other words, many software developers aren’t using practices such as test driven development or source version control. Yet here are HP, Microsoft, and IBM announcing new ALM tools that automate more advanced practice in areas not even in use in the first place. Unbelievable. — Ken Schwaber Read more →
Increase Code Coverage by One Percent
Don’t kill yourself striving for 100% coverage of code with automated unit tests. But take a few minutes to increase your coverage by 1%. Most likely, that means going from 0% to 1%. And that’s the biggest improvement of all. — 8 ways to be a better programmer in 6 minutes Read more →
Basically Done
One of our contract programmers tells me that his current project is “basically done.” “It’s done or it’s basically done?” I ask. “It’s done. Amanda is testing it.” “How do you know it’s done if she’s still testing it?” “All the tickets are closed except one, so it’s basically done.” “I don’t mean to give you a hard time. I’m trying to figure out if there’s a difference between ‘basically done’ and ‘done.’ Because usually there is. I inherited a project here last year that when I got it, it was ‘basically done,’ except it needed some more testing. I put one of my best guys on it and he was still working on it a year later when it was finally cancelled. It took a year to go from ‘basically done’ to cancelled. Hence my lack of fondness for hearing projects described as ‘basically done.’” Notes for next team… Read more →
The V Model
The graphic on the right came up for discussion at the office today. The V Model is a traditional model, still widely used, but (IMO) bad for at least a couple of reasons. Look where User Requirements and UAT are — the first and last items in the V. This ensures that the maximum amount of time goes by between users saying what they want and being able to test out the implementation. The more time that goes by between users saying what they want and being able to try it out, the more likely it is that they’re going to change their minds, for any number of reasons. That’s bad. If our testing is honest, there’s always some non-zero probablilty that the system will fail, again for any number of reasons — too slow, too buggy, not what I asked for, etc. By putting testing last, we don’t find… Read more →
Programmers Say the Darndest Things
It’s done but we’re still working on a few things. Then it’s not done, is it? It mostly works, but it still needs a lot of testing. How do you know it mostly works if it still needs a lot of testing? Isn’t that what testing is for — to figure out if it works? I’m not making these up, by the way . . . Read more →
James Bach on Software Testing
Jerry Weinberg has suggested that “it works” may mean “We haven’t tried very hard to make it fail, and we haven’t been running it very long or under very diverse conditions, but so far we haven’t seen any failures, though we haven’t been looking too closely, either.” In this pessimistic view, you have to be on guard for people who say it works without checking even once to see if it could work. “No user would do that” really means “No user I can think of, who I like, would do that on purpose.” Who aren’t you thinking of? Who don’t you like who might really use this product? What might good users do by accident? In general it can vastly simplify testing if we focus on whether the product has a problem that matters, rather than whether the product merely satisfies all relevant standards. . . .… Read more →