QA Alchemy

A few months ago I purchased two new suits for myself.  A blue one and a gray one.  They are a bit more modern, in the fashionable sense, and my wife was relieved I'm finally wearing something that looks somewhat reasonable.  A few weeks ago I put on the gray suit, and picked out a yellow tie, thinking "gray and yellow go together, right?  suuurree..."  Turns out I was right, and the old yellow tie that never got any feedback, suddenly became the catalyst for comments such as "nice suit!" and "is the tie new?"  Actually, its not.  I've had it for years, but apparently it looked so nice with this suit, it really made an impact. Testing software (and hardware for that matter) is a lot like matching the right tie to the right suit - except in this case you're looking to break it.  You see, in testing we run the same tests over and over again.  Often we run on the same environment and configurations.  Once we've passed the initial bug...

Testing Perfection. As we discussed in the last post, testing in agile life-cycles is a constant battle of timelines, priorities, integration and system issues and overall quality of product.  Its very important when running your tests that you are able to see the overall picture of the product and maintain a high level of quality, while keeping in line with the release time frames.  This is true whether your company is running long interval releases, short and frequent or daily releases.  QA is pressured to keep the pace of development and its important for all companies to put into place regular strategies to keep the QA on track without sacrificing quality. Hereby we present the 4 Prong Method to Testing Quality in Agile .  The 4 Prong Method explains how to ensure your testers are keeping up with the speed of agile, and still supplying the best possible quality.  Here's how it goes: Design phase QA inclusion  At what point should...

If you are a tester, or developer, or product manager, or engineer, or any kind of person who work in engineering, then stop what you're doing and listen to this podcast.  For anyone reading this blog, this podcast is required listening. For anyone who is a tester, this podcast is required listening. Have you gone yet?  What are you waiting for? This American Life - NUMMI 2015 And in case you need more convincing, here's a few hints I'll lay out for you. A car plant in Fremont California that might have saved the U.S. car industry. In 1984, General Motors and Toyota opened NUMMI as a joint venture. Toyota showed GM the secrets of its production system: How it made cars of much higher quality and much lower cost than GM achieved. Frank Langfitt explains why GM didn't learn the lessons—until it was too late. So go listen, and it will change your life!

Raise your hand if you remember the days of waterfall life cycles.  Anyone?  Anyone?  Ahh, they were a different time, weren't they?  First Product would talk a lot about what they wanted.  Then Development would fight a lot about what they couldn't do.  Then they would do it, and QA would wait until the whole package dropped and everyone would start seeing where all the holes were.  But there would be several cycles, and the QA team had strong respect.  It was during waterfall cycles that I truly learned the meaning of the term "The Buck Stops Here."  QA is the last stand, and they have to sign off on the project. Three months of blood and sweat and coffee and coke cans and late nights, and finally, a product is ready to release. But the testing process was a lot like this comic of the Ikea Job Interview.  Its like Dev would say: "Here is the product, we finished making it, now put it all together." and they kind of hoped it would all...

In the world of Hi-Tech and software engineering, we are all trying to get ahead, and put out the best possible product.  On the path to success, we stumble across obstacles and various implements that cause us to slow down and prevent our product from reaching greatness.  The great migration of software engineering to move from waterfall life-cycles to agile methodologies was a concerted effort to break down these barriers and improve our release management into faster releases, to improve our overall output - more and faster - and improve overall quality.  However, in the move to produce better and faster, much of our product fell in terms of quality.  The general importance to test and produce at the highest possible quality all too often takes a back seat to "get the product out" and "start making revenue".   During this time period that we as an overall contingency of software and hardware engineering companies moved into agile development, the...