Picture this hypothetical situation: you are working in Easy LMS on a fantastic GDPR Course. It's fantastic because you made it fun with cool infographics and appealing videos. Bye, bye boring compliance training. All the GDPR information is there; you just have to put it in the system. Everything is going smoothly. Until you want to upload a video. Suddenly your whole Course is gone! Just in one click. Aaargh!
Obviously, this is something you and we don't want! We think it is better to find out something is broken before our clients do. That's why we have an extensive Quality Assurance (QA) procedure that includes manual and automatic testing. In this article, we will focus only on manual testing. Because sometimes you just need humans instead of robots 😉. Welcome to our world of manual testing!
What is Quality Assurance? And why do we need it?
QA officers are often the gatekeeper in determining whether or not the feature or fixed bug is ready for release
First, let’s take a step back in case you are overwhelmed by the term Quality Assurance 😉. What is Quality Assurance? And why do you need it? Quality Assurance (QA) is making sure that something works as intended. In our opinion, having a QA process is critical to our (software) product and customer satisfaction, and thus our company’s success. QA officers are often the gatekeeper in determining whether or not the feature or fixed bug is ready for release.
While some may reduce QA to simply testing, we think it is more than that. Having a good QA is as crucial as building itself. It ensures you can meet your own high-quality standards! It also makes your product stable, and it makes your team feel safe. We all make mistakes; it is an inevitable part of being human, even if you are a gifted developer (like ours 🙂 ). But having a safety net makes you feel free in mind and work, so you can push your limits. This will lead to more advanced (development, design, writing, you name it) skills in the end!
Who does the testing?
A year ago, Caroline was our one and only QA officer. She tested everything that was developed by our developers manually. And we can tell you: that's a lot. Because we strive for autonomous teams that can operate entirely alone, we experimented with running a QA by the development teams themselves. The experiment was successful! “Testing with our team feels like the right thing to do. Our team is multidisciplinary, so we all notice different things. This gives us a much greater guarantee of spotting small issues than if a single member were to test by themselves. We also know how the code works, so we have a clearer idea as to how we could break it!”, explained Bram, Back-End Developer.
What does our testing procedure look like?
Our manual testing procedure consists of six steps. Let's go through them together!
Step 0: Verify if the code meets our quality standard.
Before we start testing manually, we do a code review. Another developer verifies the quality of the code. We check, for example, explicitly for security vulnerabilities. Also, we run automatic tests that analyze the code quality. These tests need to succeed before we continue. If the test fails, we go back to the drawing board and fix the issues.
Step 1: Verify if all acceptance criteria are met.
When we build a new feature, we start with writing acceptance criteria. Acceptance criteria define how a particular feature could be used from a client's perspective. So, we think of how a feature needs to work, so we could test afterward if it does work as intended.
Step 2: Verify if our Definition of Done has been met.
The Definition of Done is an agreed-upon set of items that must be completed before a project can be considered complete. Our Definition of Done includes, for example:
Step 3: Try and break stuff
We take the client’s perspective. First, we use the feature the way we expect the end-user would. Then, we take it to the extreme. We repeat actions more than once, use extreme test cases, and verify that the new feature did not break existing ones. What happens to X if I push the new button Y? We also test with different test accounts with other characteristics.
We take the client’s perspective
Step 4: Test from a security standpoint.
We aim to be GDPR compliant. We take our clients data seriously. Therefore, we test for possible vulnerabilities with a few commonly used hacking techniques. We are good people, so we never use these techniques in real life; no worries!
Step 5: Test the new translations and edit them.
We support 11 languages in our dashboard, and our player interface is available in 24 languages. We have a pool of freelance translators who translate all text manually in a separate translation tool. We verify if all text is added to that tool. Also, we review and edit them, so they are immediately ready to go!
Step 6: Consider what content will need to be updated or written.
Most of the time, a new feature comes with new text. We prepare any internal or external content ahead of time where possible. When we release a new feature, we want to be complete! That connects to our single item flow vision!
"Doing QA well can be a time-consuming task. The more perspectives and eyes involved, the better. Having the steps documented so that anyone can follow them works, instead of relying on just one individual. At Easy LMS we work in multi-disciplinary teams, with back-end and front-end developers working closely with our implementation consultants that bring in the client perspective. It makes sense!", said Caroline, QA officer.
When do we do manual testing?
Every single feature gets tested manually
Every single feature gets tested manually and goes through the same process! Even small features (like replacing an image on the home page) that don't even need testing at first glance. But the devil is in the details and in small features 😉. We execute our manual testing procedure when development is done. Test succeeded? Then it is time to release it so our clients can enjoy it! Did the test fail? Then the feature is under investigation again. This means the development team will solve the problem and test the quality again. We repeat this until all boxes of our QA review checklist are checked.