![\"Guidelines](\"http:\/\/strawberrycode.com\/blog\/wp-content\/uploads\/2016\/09\/GuidelinesQA_banner.png\")
<\/p>\nFollowing 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\u2019s perspective, the rest consist of things I\u2019ve seen.
\nOnce 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.<\/p>\n
<\/p>\n
1. Prepare your tests<\/strong> 2. A feature cannot be tested by its own developer only<\/strong> 3. Check all the login methods, always!<\/strong> 4. Don’t use the same user to test everything<\/strong> 5. Use meaningful names or variables to test with<\/strong> 6. Use the \u201cextended\u201d company email addresses<\/strong> 7. Test tracking if possible<\/strong> 8. When logging the bugs and ideas, prioritize them<\/strong> 9. Separate bugs from improvement and evolutions<\/strong> 10. If you don\u2019t know, ask!<\/strong> 11. Don\u2019t say \u201csimple\u201d, \u201ceasy\u201d or \u201cjust\u201d to a developer<\/strong> 12. Use automated tests<\/strong> 13. Make someone else test the app\/website too<\/strong> 14. Don\u2019t expect things to work, but rejoice when they do!<\/strong> 15. Use a test environment as close as possible to the live one<\/strong> The final word: be sensible, be meticulous and stay human :)<\/p>\n","protected":false},"excerpt":{"rendered":" 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\u2019s perspective, the rest consist of things I\u2019ve 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. 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 … Continue reading Guidelines #2 for QA<\/span>
\nHave scenarios ready, know what you need to do, list all the variations of things you can come across, etc.<\/p>\n
\nIt 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.<\/p>\n
\nEspecially when you depend on third-party services, they do updates…<\/p>\n
\nYou may end up ignoring a lot of cases.<\/p>\n
\nFor example Test1<\/code> and qwerty<\/code> are a bit less transparent than no_email<\/code> or CODE10OFF<\/code>, don’t you think?<\/p>\n
\nYou know something like \u201cname+001@company.com\u201d, so you don\u2019t end up sending an email to real people!<\/p>\n
\nSome third parties have a sandbox mode, take advantage of it.<\/p>\n
\nCritical, high, medium, low priority, improvements, next release… And colors can help too :)<\/p>\n
\nYou may not have the time to tackle everything before the release, so let\u2019s focus on the bugs first, shall we?<\/p>\n
\nDon\u2019t make suppositions, especially technically speaking.<\/p>\n
\nWhen you\u2019re talking about bug fixing. Please. Thanks :)<\/p>\n
\nA lot of frameworks or software exist, make a good use of them. It will save you time and trouble.<\/p>\n
\nIdeally, someone who doesn\u2019t know it or hasn\u2019t been involved in the development process. An extra pair of eyes is always useful, especially for UX.<\/p>\n
\nI think it\u2019s the best way to stay positive\u2026<\/p>\n
\nIdeally, it would be replicated from live. It will make tests and debug a lot easier. And it\u2019s less risky to push live after the tests!<\/p>\n