Quality Assurance
What is QA?
QA or quality assurance is keeping defects and mistakes out of the final product that goes to customers. Quality management assures that quality requirements are delivered. Quality assurance and quality control are often both used. This is quality in both the product and the process. Software QA, or software testing, usually involves running the software to verify specific requirements. These requirements can be the design, the inputs, the calculations, the outputs, stability, speed, installation, and the stakeholder desires.
What did I do as a QA?
When I first started as a software QA, I was not part of the design process, I only knew what I was testing when I got it from dev. I would read through the requirements documentation and try to make sure everything was working as desired and matched the requirements. There were times when I had to reach out to both the developers and then BAs to figure out how the result matched the requirements. As I became more comfortable with my role I would ask different questions as well as request to be part of at least the requirements review. I would test the interface, usually at the end of the cycle. Take note of what didn’t work, or what works, but not the way I think it should. In many ways, the QA or tester is the first user. After the development is complete we are the first people to try to use the feature(tool, software, website) and we don’t know how the developer intended it to work. Many times this is the first time we are seeing the software as well as the requirements that we are testing against. QA is the first (and last) line of defense against poor user experience. If we can’t figure out how to use it, something should be done. It could be fixing the code, improving the experience, adding to training materials, or updating release notes to call out breaking or unexpected changes.
Business Analyst
What is a BA?
A business analyst, BA, analyzes and documents business, processes, or systems. A BA helps guide businesses to improve those processes, products, and services. The business analyst acts as a liaison between the product owners and the technical team. At times the BA will also help with the implementation and creation of training documentation. The results of the analysis can be project plans, data models, business cases, and flowcharts.
What did I do as a BA?
After being part of the requirements process as a QA I became the one responsible for creating the documents. I was asking all the right questions and our team was growing so the documentation needed to be more complete and thorough. Our team had many more user interfaces to define.
I would work with the product owner to fill out the feature requirements. What will it look like to the user, storyboard, wireframes, prototypes, and workflow? The product owner would call a meeting and share the initial idea of the next feature. We would discuss what the main goal of the feature is, what will it be used for. We then look at the workflow, how will the user go from start to finish. Then I would break it up into smaller pieces. For example, to discover the feature will they find it in the right-click menu or a dropdown menu? The choices the user will have to make before moving on to the next step. I would then start writing out the requirements. These documents would be a combination of words and pictures, demonstrating or explaining every step of the way. So within the document, the menu description may be in list form rather than a picture of the menu.
User Experience
User experience, UX, itself is the experience, or perception of usability, efficiency, and effectiveness. User experience design is the practice of creating the products, processes and interactions focused on the quality of that experience. These “designs” cover many aspects of the experience, including the product, the package, the store, the website, and the phone call.
How do BA, QA, and UX relate?
First I want to share my usual project cycle and who is involved:
- Product Owner: Think of an idea, either a feature or a product.
- Product Owner, BA, QA, UX: What is the goal of the product/feature. How do we expect the user to use it? How do we expect to test it?
- BA, QA, UX: Talk through some use cases. How will the user get to the feature?
- BA, DEV, QA: How can we break it up into smaller components to build and test
- BA: Write down assumptions, requirements, etc.
- BA, UX: Create the wireframe, a visual representation of the feature throughout the process.
- BA, Dev: Talk through that with the team when complete. Make sure the developers understand what we are asking for and make sure it is doable. (possible)
- BA, Dev: Developers get started, make sure to ask questions if anything is unclear or ambiguous. Do NOT assume!
- Team!: Halfway through, hold a meeting to show progress as well as have the developer walk through the use cases that they are building for. This could be in front of the team as well as the users or stakeholders. If anything needs to be changed, do it now!
- QA: Development complete. QA gets it. Go through the documentation to verify the feature does what it should. But also pay attention to ease of use and flow… are there any extra steps we can remove? Is there anything missing? Was there any place we got stuck? Again go through the use cases.
Part of being included in the design meetings was thinking of how to test the feature. This helps with usability as well. QA has first-hand experience with programs that are not easy to use, therefore usually not easy to test either. With testing, you get used to certain things working in certain ways, just like the end-user. I would bring it up with the team if it is not easy for me to figure out how to use, or if there are easier ways to flow through the process. According to the NNGroup, a good UX professional is someone who likes puzzles, finds the bugs and typos, and in general wants to make things better for everyone, in other words, a QA.
As a BA I took what the product owner was wanting for the feature and put it into writing. Also working on creating and clarifying the flow. The user interactions are specified and many times I created at least a wireframe; sometimes more of a prototype or storyboard.
What have I learned about being more UX focused?
I am not my user! The users I am designing for definitely do not think the same way that I do. This is a strong reminder to perform actual user research. Another thing about user research is to be careful about how you ask certain questions. To not lead with specific vocabulary if the user has not used it yet.
As QA I did get used to “workarounds”, I have to remember that I only know those because I have experience with the product. This was emphasized by watching the users try to navigate through some things.
The user journey is not just one thing. It includes all interactions and interfaces. With the product, I was only looking at the single feature, not the big picture of how they were even going to get to that part of the product, or why.
Written by Cayley Hunt, Business Analyst & Quality Engineer at Mofiti