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.
Excerpt taken from the Software Testing Body of Knowledge for CSTE
The “basics” of software testing are represented by the vocabulary of testing, testing approaches, methods and techniques, as well as the materials used by testers in performing their test activities.
Quality Assurance versus Quality Control
There is often confusion regarding the difference between quality control and quality assurance. Many “quality assurance” groups, in fact, practice quality control. Quality methods can be segmented into two categories: preventive methods and detective methods. This distinction serves as the mechanism to distinguish quality assurance activities from quality control activities. This discussion explains the critical difference between control and assurance, and how to recognize a Quality Control practice from a Quality Assurance practice.