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 is done. Instead of actual testing for defects, we are more likely to check that the integration was completed correctly. We will insure that whatever software we choose fits well with all of the systems it needs to connect with at UConn: KFS, HR and Payroll systems, Student systems, various databases, and much more. This all starts by correctly identifying the improvements we want to make.
Here are a few areas where I believe QA can help.
Requirements Review: Requirements exist whether you write them down or not. I will work with the Business Analyst (BA) and the project stakeholders to review the requirements. We need to ensure that all requirements are measurable. If they are measurable, they are testable. If we cannot find a measurement for a requirement, then it is not really a requirement, but merely an idle thought.
Documentation Review: The product’s documentation includes the user/training manuals, installation guide, online help, or anything else that explains how to use the system. We are concerned with improving its accuracy, completeness, clarity, ease of use, and the degree to which it captures the spirit of the design for UConn.
Test Planning: Here we can help to determine the best test strategy. The who, what, why, when, where, and how of the testing process. Do we need test cases, scenarios, one round, two rounds, more? Do we have the proper environment? If we need user testing, do we need to train the users?
It is worth noting here that the test plan document is a dynamic document that needs to be referred to often. For that reason, it is my intention to keep it short and simple: one or two pages max.
Test Training: we can provide periodic testing workshops to train users how to recognize and report issues when they occur. In these workshops, we will also clarify some testing terms so when we talk, we are speaking the same language.
Lessons Learned: Of course the PMO will do a “lessons learned” activity at the end of every project, but I will be taking a critical look at the QA functions to see what worked and what didn’t. We have come away with “lessons learned” from every project we have done so far. Additionally, all of the testing results have been documented for future reference and audit purposes as necessary.
Continuous Improvement: There are two areas of improvement we are concerned with; our QA skills and the product that was just installed or updated. We are always looking for ways to streamline the QA process, based on the context of the project. We also want to ensure that the product (upgrade, integration, etc.) continues to work efficiently well after the project is over. We can help to set up a process for reporting problems going forward.
Notice that almost all of the areas mentioned above are shared with at least one other member of the PMO team. We are an integrated group and much of what we do blends back and forth with other members. There may be more ways we can help; we just haven’t found them yet, but we are always looking.
A Value Add
I see the QA function as a value add to any project under the PMO. To that end, here are the core values that I personally strive to uphold on any project.
- I do not claim to assure, ensure, or control quality. I do not control anything about the product. A tester is a witness, and in that capacity, I strive to assist the quality creation process.
- I strive to maintain a reasonable impartiality. The purpose of testing is to cast light on the status of the project and its context.
- I will report everything that I believe, in good faith, to be a threat to the project or to the users thereof, according to my understanding of the best interests of the stakeholders.
- I will continuously study my craft, be alert to better solutions, and to better ways of working.
Thanks for reading!
Mick
Related articles:
Introducing QA Part 1: What is QA?
Introducing QA Part 2: What is Quality?
Introducing QA Part 3: What is Testing?