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 →