Category: Quality Assurance

Influencers – James Bach

  • September 15, 2016
  • Kevin Rutkowski
  • Comments Off on Influencers – James Bach

There are a number of blogs that I enjoy reading about all areas of the software development process. The software development process includes project management, business analysis, development, and testing, of course. In addition, delivering software that works requires consideration of concepts around management, sales, and business organization.

I’d like to share some of the blogs that I find influential when thinking about how to build software that works.

James Bach and Exploratory Testing

One of my favorite blogs is James Bach’s Blog. He is the creator of Rapid Software Testing. I first became interested in his blog because he wrote about exploratory testing in a way that made sense to me. I knew from experience that exploratory testing was one of the best ways to find important bugs, but I didn’t have a great way to communicate the high value of exploratory testing to teams that were focused heavily on mechanizing the testing process. James Bach has written a lot on the topic of exploratory testing. This particular post about the history of Exploratory Testing captures many of the concepts that drew me to the blog.

I particularly like the concepts of testing vs checking and the “responsible tester.”

Feedback

What do you think of James Bach’s blog and the concepts he writes about? What blogs and resources do you find particularly interesting and useful for building software that works?

Embedded Quality – Building on a Solid Foundation

Embedded Quality is a Quality Assurance (QA) technique that I’ve introduced on many projects with great success. Embedded Quality has some of the following benefits:

  • Avoids long test/fix cycles at the end of projects
  • Ensures that projects finish strong
  • Lowers cost
  • Shortens timeline
  • Improves quality
  • Increases customer confidence in IT department
  • Easily applied to any software development methodology

Basic Concepts

The basic concepts of Embedded Quality are nothing Earth-shattering. The concepts draw from standard software development techniques and seem like they should be common sense. However, in the 20+ years that I’ve been working in software development, I’ve found that these concepts are not commonly practiced.

QA starts on Day 1

I have found that on many projects, Quality Assurance is an after-thought. Involving QA as part of the core project team helps prevent nasty surprises at the end of the project.

QA is part of the Core Project Team

Too often, the development team and QA team are completely separate entities who send their work “over the wall” to each other. Quality and speed increase exponentially when we break down the barriers between these groups and work as a team.

QA is performed by qualified experts

One of my clients used to hire people out of high school to test their software. If they did well, they got promoted to doing phone support. Eventually, they realized that they could drastically decrease phone support and increase customer satisfaction by hiring qualified people to do their Quality Assurance work.

Just as building inspectors need special knowledge and experience to do their jobs well, software QA experts need special knowledge and experience to do their jobs well.

General User Acceptance Testing (UAT) does not begin until Core Project Team QA is complete

A common practice on projects is to rely on UAT as the only form of testing. This results in the end users seeing a large number of the flaws in the software. Invariably, I have seen the end users permanently lose confidence in the development team when using this QA strategy.

I liken this to a builder turning over a new house to a buyer without having any inspections and saying, “We don’t really know if the plumbing is solid, all the electricity works, or the roof leaks. Just try everything out and let us know what the problems are.” (In fact, this does happen: http://abcnews.go.com/GMA/Consumer/story?id=2630414&page=1.)

Strong Foundation – No code is “Complete” until it is tested and works correctly

Many project schedules track code as complete when the developer completes their initial delivery. This can give a false impression of the project status.

More importantly, this ensures that new code is built on a strong foundation. When developers build new code on untested code, it is very similar to building an office tower on a foundation that has not been inspected. If a problem exists in the foundation and is not identified early, the building will fail.

http://blogs.wsj.com/chinarealtime/2009/06/29/shanghai-building-collapses-nearly-intact/

Embedded Quality – Next Steps

Over the next few months, I will post tips on how to implement Embedded Quality on your next project. I’ll share stories of my experiences over the past 20+ years, and I would like to hear your experiences as well.

Scroll to top