EppsNet Archive: Software Testing

9 Links

1 Mar 2014 /
  1. Data Structure Visualizations
  2. Good Tech Lead, Bad Tech Lead
  3. Google Java Style
  4. Guide to 12 Disruptive Technologies
  5. How to Write a Cover Letter
  6. The Landing Page Optimization Guide You Wish You Always Had
  7. Selendroid: Selenium for Android
  8. UX Axioms by Eric Dahl
  9. Yelp’s got style (and the guide to back it up)

Agile, ALM, and Agile 2.0 — Putting the Cart Before the Horse?

1 Aug 2013 /
Cart before 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.


Increase Code Coverage by One Percent

25 Jul 2012 /

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.


Basically Done

9 Dec 2011 /

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 meeting: Effective immediately, we’re not going to describe any task as being “basically done,” “pretty much done,” or my personal favorite, “done — it just needs a little more testing.” (Isn’t that what testing is for — to find out if it’s done?)

We’ll classify things as either Done or Not Done. If it’s not done, we should be able to say what has to happen in order for it to be done.

Thus spoke The Programmer.


The V Model

9 Jun 2009 /
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.

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

  2. 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 out that the system is a failure until we’ve already invested the entire cost of building it, thus the rich history of big-ticket IT failures, where huge sums of money were spent and nothing usable was ever delivered.

IMO, you can use a design-code-test V model, but you have to use it iteratively every week or two weeks or at most every month on a project to avoid these problems and make sure users are getting what they want.

Thus spoke The Programmer.


Programmers Say the Darndest Things

16 May 2009 /

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


James Bach on Software Testing

13 Jan 2008 /

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. . . . Instead of thinking pass vs. fail, consider thinking problem vs. no problem.