Guidelines for QA

Guidelines #2 for QA

Following the previous “Guidelines for developers”, here are some basic rules/advice for Quality Assurance (aka QA) based on my experience. You will notice that sometimes it is seen from the developer’s perspective, the rest consist of things I’ve seen.
Once again, it is not exhaustive, so feel free to add your own! All the rules may not apply to your projects, but I’m sure you can find equivalents.

Guidelines for QA

1. Prepare your tests
Have scenarios ready, know what you need to do, list all the variations of things you can come across, etc.

2. A feature cannot be tested by its own developer only
It needs to be tested by someone else too. If you walk on the same pavement every day, you know where the holes are, and you’ll avoid them without looking. It’s the same thing in development, and believe me, developers don’t do it on purpose.

3. Check all the login methods, always!
Especially when you depend on third-party services, they do updates…

4. Don’t use the same user to test everything
You may end up ignoring a lot of cases.

5. Use meaningful names or variables to test with
For example Test1 and qwerty are a bit less transparent than no_email or CODE10OFF, don’t you think?

6. Use the “extended” company email addresses
You know something like “”, so you don’t end up sending an email to real people!

7. Test tracking if possible
Some third parties have a sandbox mode, take advantage of it.

8. When logging the bugs and ideas, prioritize them
Critical, high, medium, low priority, improvements, next release… And colors can help too :)

9. Separate bugs from improvement and evolutions
You may not have the time to tackle everything before the release, so let’s focus on the bugs first, shall we?

10. If you don’t know, ask!
Don’t make suppositions, especially technically speaking.

11. Don’t say “simple”, “easy” or “just” to a developer
When you’re talking about bug fixing. Please. Thanks :)

12. Use automated tests
A lot of frameworks or software exist, make a good use of them. It will save you time and trouble.

13. Make someone else test the app/website too
Ideally, someone who doesn’t know it or hasn’t been involved in the development process. An extra pair of eyes is always useful, especially for UX.

14. Don’t expect things to work, but rejoice when they do!
I think it’s the best way to stay positive…

15. Use a test environment as close as possible to the live one
Ideally, it would be replicated from live. It will make tests and debug a lot easier. And it’s less risky to push live after the tests!

The final word: be sensible, be meticulous and stay human :)