How To Spot A Software Testing Train Wreck?

How To Spot A Software Testing Train Wreck? has served as the poster boy for the potential dangers awaiting those who go down this path. As CIO contributor Matthew Heusser noted, agile-focused terms such as “sprints” was thrown around a lot during development, creating the illusion that the various project teams were adhering to that overarching methodology. However, it has come to light that testing was handled in a waterfall fashion, tacked on at the end of the production cycle and given little time for completion. Such compromises should raise red flags within any QA team

Sadly, this is a bigger issue than just with  A lot of companies tend to do this same thing, and it leads to a lot of the same problems and challenges.  Just because you have sprints, and do daily standups, it doesn’t mean that you are Agile.  There is a lot more that goes into it, and it is time we start acknowledging that.


Why we need realism in testing

Why we need realism in testing

My message with this story: Yes, it’s often inconvenient to figure out and set up realistic conditions when testing but failing to do so can be catastrophic. As the train attendant pointed out: “Some days when my arm is aching I just look at the tickets and assume they are valid“.

I think this is a great example of what has to happen to build a product that people want to use.  If you don’t know how your product is going to be used, and haven’t eaten your own dog food, then chances are your end result will not turn out the way you expect.


Why Agile won’t solve maintenance problems

Why Agile won’t solve maintenance problems

In every case, there is a common result that I must say is not directly related to development methodologies, but more to human being natural procrastination allied to unrealistic planning: the lack of good documentation at the end of projects.

Great post on one of the pitfalls about Agile…it’s often used as a scapegoat when it comes to documentation and maintenance.