The need for good requirements in our projects is essential, and there seems to be some misunderstanding about why. Although the Business Analyst (BA) elicits the requirements for our projects, I am including it in the Quality Assurance (QA) section because we work very close together in this space. And getting good requirements is critically important to achieving good testing.
In fact, it was so important to me that I decided to read the book, Mastering the Requirements Process: Getting Requirements Right 3rd Edition in order to better understand the requirement-gathering process. The first chapter was so captivating that Continue reading
Welcome to the final article of the Introducing QA series. If you read the preceding articles in this series, and I hope you did, you know that QA has to do with improving processes and testing. And you know that quality is a moving target. Our intention is to improve the quality of your next project.
In part 1 of this series, we mentioned how the Project Management Office (PMO) is focusing on ways to provide more value to projects within ITS. So if you are considering a new project, you may be thinking, “what can the PMO do for us?” The PMO as a whole has a lot to offer, and I can assure you that the whole is greater than the sum of our parts. But for the purpose of this article, I will focus mostly on the QA part. (Although, it is sometimes difficult to separate.)
We have been using Software as a Service (SaaS) more and more in our projects at UConn lately. That means the quality of the software itself is somewhat out of our hands. We are depending on the supplier of that software to have very good QA practices. This also changes the way testing Continue reading
The essential mission of testing is always the same; to answer this question…
Are there problems that threaten the on-time, successful completion of our project?
There have been thousands of books written about testing over the years, and I could list over 100 types of testing that are described in those books. But that is not going to help you understand testing, at least not at this point. The most important thing to understand about testing here at UConn is the concept (or concepts) of testing, and how it all relates to QA.
In the last two posts of this series, we have taken a close look at both Quality Assurance (QA) and Quality itself. And we came up with the following definitions as a baseline.
“Quality is free, but only to those who are willing to pay heavily for it.”
– T. DeMarco and T. Lister
In part 1 of this series, What is QA?, we talked about Quality Assurance (QA) and how it means different things to different people. Other factors for these different meanings are the many definitions surrounding the word “quality” by itself. We all know quality is important, and we all have an idea of what it means. But it’s not that easy to define in terms of a project. For some, it means reliability and efficiency. To others, it means fitness of purpose, or usability. As an example, here are just some of the definitions you can find online.
What is QA?
“The bitterness of poor quality remains long after the sweetness of meeting the schedule has been forgotten.” -Anonymous
Hello! My name is Mick Stevens and I am the Quality Assurance (QA) person in the Project Management Office (PMO). The PMO is currently focusing on ways to provide more value to projects within ITS. We have a lot to offer to both new and existing projects so we are conducting a series of short presentations to introduce ourselves to small groups within ITS. These presentations intend to show how we can offer value and support in the areas of:
- Project Management (PM)
- Business Analysis (BA)
- Quality Assurance (QA)
- and Training.
I was very excited to kick off our first of many presentations by talking about QA. I was excited because there are so many differing views on what QA, Quality, and Testing is… how it should be done, and what it should (or should not) do. This could be an opportunity to provide some clarity for these topics as they relate to the projects at UConn. Or so I thought. Continue reading
And what I really learned…
On August 14th and 15th, I attended my first testing conference, ever. Even though testing has always been part of my 30+ year career, I have never had an official testers role. I never even thought of myself as a tester until now. I went to this conference with the intention of getting some ideas on a quality process that could be used for the various projects here at UConn. I dream of the day when all employees are thinking about quality and have a quality mindset.
I was initially a little wary about meeting a bunch of seasoned software testers because I had found the role almost by accident, and I still didn’t really feel like a tester. Even though I have been studying testing strategies for the last three years, I still felt like a newbie. I am happy to say, though, that my fears were completely unfounded. Everyone at the conference was super helpful and encouraging. And as I talked to more people, I found that almost no one started out their career as a software tester. Either they fell into the role by accident, or they were assigned the role on a temporary basis and then fell in love with it.
This month, I want to shed a little more light on requirements and test cases. The general consensus seems to be that requirements, at least, should be 100% complete early on in the project, but that is not always the case. Both test cases and requirements are continually refined as we learn more about the product. And we learn more about the product by testing. Michael Bolton has some interesting views in his blog posts below.
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.
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.
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.