Comments for Web Software QA Random thoughts and opinions on software test management and Agile delivery Thu, 29 Oct 2015 19:50:01 +0000 hourly 1 Comment on How is QA different for Waterfall, Agile, and XP? by Gordon Thu, 29 Oct 2015 19:50:01 +0000 Good article. The problem faced by any of these methods is when they are selected, not by appropriateness to the product, but by Executive staff who just want the fastest cycles. While Waterfall can take longer and Agile can appear to be faster, if they are selected by TTM needs and not product requirements you can end up with a chaotic mess.

You can’t take a cake that bakes at 350 degrees for 30 minutes and bake it in 15 minutes at 700 degrees. Likewise, making a whole lot of smaller cakes that might bake faster is not going to make it easier to assemble them back into one cake. Not recognizing the BETTER method to a quality product and just going with Time To Market is a recipe for disaster.

A hybrid approach selected and/or created by QA professionals is the better method.

Comment on The Value of Differentiation: Defects and Bugs by Eric Mumford Wed, 21 May 2014 14:34:47 +0000 Peter, thanks. I’ve removed the left-right reference and left it simply as, part of our brain. Given present scientific progress on brain study and use, I’m not entirely convinced the left-right comparison is a useful one.

Comment on The Value of Differentiation: Defects and Bugs by Peter Thu, 08 May 2014 19:08:46 +0000 “The right side of the human brain, used for computation, logic, and building” This is a bug in your article! It is the left side.

Comment on Defining Quality-Driven Development (QDD) by Adam Auerbach Wed, 02 Apr 2014 22:25:30 +0000 My company is using QDD. We have expanded it to include DevOps and ATDD so that not only are we driving quality up front but we are doing more during the sprint to reduce hardening and get to production faster with higher quality.

Comment on How to Build a Software QA Process in Two Minutes by Stevan Fickus Tue, 28 Aug 2012 15:35:01 +0000 Eric thanks for the article. I’ve been working on putting together a better QA process at our shop and one thing that really changed our overall process was not allowing the fixer of a bug to be the tester. That second set of eyes makes a big difference in the resolution of the bug.

Comment on Defining Quality-Driven Development (QDD) by Ron Wolf Sat, 26 Nov 2011 19:43:51 +0000 Well said. I’ve been making the TDD vs QDD point for years. TDD – bad. QDD – good. There is very little use of the term QDD. Why not? Why so little reaction to your excellent start of a book.

BTW, I don’t agree with your first premise at all, that QDD is a natural outcome of Agile/Xtreme. I also don’t think it matters that much which is the egg and which the chicken.

Comment on The Value of Differentiation: Defects and Bugs by Ale Thu, 17 Feb 2011 12:15:40 +0000 Excellent and clear article, albeit a little long. Just wanted to point out that the “Sunlight hitting the earth…” is not chemical in nature, but an entirely physical process (nuclear in fact).

Keep it up!

Comment on Applying QA to Waterfall Development: Wait, what? by Eric Mumford Tue, 25 Jan 2011 00:07:13 +0000 Good to see you around this part of town, Mr. Farnan!

You’re right, I think that what you describe as my “[disdain] for waterfall type problems” is more a disdain for the disdain itself. I agree with your suggestion that waterfall is not outdated; I am in sync with the spirit of “just because it’s old doesn’t mean it’s necessarily bad.” Take all of the mainframe re-engineering work going on today — racing to replace FORTRAN code with Java architected apps can provide some relief from (note: not necessarily a pure solution *to*) scalability/supportability issues, right, but what other problems come with Java architected apps created from the user requirement of “make it work like it does today”? Very often a hairball is replaced with… a new hairball. Meet the new boss, same as the old boss.

Some CIOs dictate software methodologies indirectly by first stating that it is not their job to dictate how software is created but then hammering down ideas that don’t fit with their pre-conceived notions. Sure, they’re not dictating the process, but the process that ends up being implemented is the one they were just happening to prefer because they made it too difficult to implement the alternatives. How many times have Agile Scrum projects failed not because Scrum failed, but because you implemented a nasty monstrosity that you called Scrum and looked like Scrum but was really just a set of actions without an exhaustively understood set of principles behind it that mapped to both your corporate culture and your technical ability to execute? Good CIOs think of these things, and they look to their direct reports to audit them and question their assumptions.

In complete agreement on badly managed projects. I don’t know if your prediction about Agile will come true: I do think we can help to prevent that version of the future by standing up for principled, smart software development outside of our expertise, whether we are a Project Manager, Developer, Architect, or QA guy.

Comment on Applying QA to Waterfall Development: Wait, what? by Larry Lunetta Fri, 21 Jan 2011 17:01:52 +0000 It’s nice to see that Waterfall still has a role. In fact we talk to IT executives in many different industries working on many different types of projects and whether they use agile or waterfall development (and I agree, labels are misleading), the one constant is a never-ending search for efficiency. CIO’s don’t have time to make friends—the pace of new business requirements continues to accelerate and that is pushing IT organizations to look for process improvements across the application lifecycle.

One focus we are seeing is a quest to compress the defect management process. Whenever a bug shows up between sprints or at the end of a dedicated test cycle—there is typically a mad scramble to document, replicate and troubleshoot the problem. These steps are complicated by a geographic dispersion of development and test resources, some or all of which may be outsourced. The stakes are high. Many industry experts put the time developers spend on bugs at 35% or higher.

So, whether a project is using Agile or Waterfall development, successful CIO’s are indemnifying their schedules and improving MTTR by: 1) better documenting and communicating defects for teams located across many time zones, 2) reducing the amount of time and capital required to replicate the test environment to reproduce a bug, and 3) accelerating the identification of root cause.
Given that over a third of development time is spent on bugs, lets’ add one more to the “Rules of the Road”: any improvement in defect resolution saves time, money and improves quality. That’s not smoke and mirrors.

Comment on Applying QA to Waterfall Development: Wait, what? by Paul Farnan Tue, 18 Jan 2011 10:02:40 +0000 Mr Mumford,
It is true you are a wierdo for those who have had the pleasure!! I can almost taste your distain for waterfall type problems… :-)

However, I don’t believe that selecting waterfall is as outdated an option as you present here. Good old fashioned business problems that need software solutions are much more common than “a new customer learning and purchase prediction model with multiple A/B tests across a variable semantic customer preference grouping algorithm”.

A CIO’s preference for waterfall (side note: Should CIO’s really be dictating project methodologies?) is understandable. Boring, consistent, predictable controlled delivery, with appropriate stage gates – while doesn’t light your fire, is not a bad thing.

Badly managed projects are just that – irrespective of the methodolgy chosen. 10 years from now Agile will have had the same experiences. It’s just catching up…