This month I’m including a follow-up post to the one from February, Why Do We Need QA Involved So Early….  This post was written by Michael Bolton and talks about more questions that testers can ask, but these questions are not just limited to testers. These are questions that all stakeholders should be thinking about.

As stated in the What is QA page, “No single group can assure the quality of any product. We need everyone involved in order to achieve the highest quality.”

Good questions will create more discussion, which could very well stimulate more ideas.

Continue reading →

I have seen a lot of confusion around the term, “best Practices” lately. In testing, this confusion usually results in many hours of unnecessary work, which also results in project delays.

When project groups are asking for best practices in a new process, what they are really asking for is how other universities are doing the same thing. We are finding that they are all different, so there goes the concept of a best practice. We still need to find the best way for us, but it is NOT a best practice. If it were, we would all be doing it the same way. It may be the best practice for us, though, so I prefer to call it a “good practice in context.”

This is especially true in testing. If you are familiar with the “What is QA?” page on this site, you know that our approach to testing is Context-Driven. Which simply means that there is no one best way to test anything. The testing strategy is fully dependent on the context of the project. After all, if there really were one best way to test, there wouldn’t be so many other companies looking for their own best practices. 

“There are good practices in context, but there are no best practices.”

This month’s post is from a Better Software Magazine article published by Stickyminds.com.  Michael Bolton does an excellent job dispelling the myth of best practices. Read on to see why he believes there’s no such thing as a best practice.

Continue reading →

Yes it is necessary!

Early on in my role as QA Analyst, I saw first hand the pitfalls of getting QA involved in a project too late. After all, it’s common knowledge that testing is not needed until the end of the project… Right?   Wrong! 

The project was about 75% complete when I came on board. The requirements were pretty well set (in somebody’s mind), but they were not all in one place. It turned out that they were sprinkled among the many other project documents and it wasn’t until we gathered them up to review that the stakeholders realized they were not exactly what they thought they were. Nobody likes surprises this late into a project because it usually leads to delays and more cost. As you might suspect, things did not end as well as they should have for this project.

Continue reading →