Words to a new software QA
We're not after the developers. We're after the bugs in their code. It's not personal.
If they didn't want us to find the bug, they shouldn't have written it in the first place.
QA starts with the requirements, if those are vague, the result will not be what the product manager wants.
Not finding a bug does not prove there are no bugs. It proves you didn't find one right there, at that particular planetary alignment with that precise set of system and environment and time of day and test data.
There is always a bug somewhere.
Ask "Is it supposed to do X when I do Y?" even if you know the answer is "No, we want it to do Z."
Learn how to program in the language your developers use. Also learn SQL (Structured Query Language), HTML, CSS, and any other acronyms you hear often.
Your developers are generally smart and decent people, they are usually very helpful when presented with a "Can you please help me..." request, or a "Can you teach me how to..."
Keep learning. There is always a new language, or tool, or technique, or platform, or environment, or program.
Get up and walk around often. Drinking large amounts of water will help this. Give your eyes a rest from the screen and go talk to your team.
Leo Tolstoy's War and Peace is a 3Mb text file available from the Gutenberg Project. If you need a large chunk of test data, use this. And if someone says they need more than 3Mb of text in a data entry field, they're doing it wrong. I don't care what they're doing, no-one will ever read that much text on a screen. If someone demands more than 3Mb of text, they are evil, so act accordingly.
Cross-browser testing is like trying to dance while holding an armload of greased snakes. For cross-platform testing, the snakes have flick-knives and a bad attitude. Plan for days like this.
There is an established LD50 (lethal dose required to kill 50% of the test population) for chocolate, but you're unlikely to be able to get there in one go. Remember this on cross-platform testing days.
Keep a virtual environment where time stopped when WinXP was still shiny and IE8 was the new hotness, because someone out there is still trapped in that world.
Test it on a tablet and a phone if it's a web site, because at least one user will try it and complain if it's not working. Use Android and iPhone. Use Linux.
Get a trackball mouse and learn to love it. It is the best way to keep other people from messing with stuff on your computer.
Have something at your desk that visitors can pick up and fiddle with if they're the nervous or tactile type. Visitors often have information you need.
Communicate early and often, QA will think of things developers do not. Ask "What happens if..." questions, especially if you suspect the answer might be "I have no idea".
Make sure your acceptance criteria are testable. "Make the app faster" is not testable, "reduce save time to under two seconds" can be tested.
It's not done until it's tested. If QA hasn't approved a feature, it's not done.
Software should be released when it is capable of doing something useful. Frequent small releases shorten the feedback loop.
Unlock the developer options on your cell phone and play with them. There are all kinds of toys to play with, including graphics tweaks and logging. These will come in handy when you’re testing a mobile web site or mobile apps. If you have a non-mobile web site, at least one of your users will get there via a phone browser.
Keep tabs on what versions of the Android OS and iPhone OS are loose in the wild, and know what versions you are supporting. Your app should fail gracefully when it’s accessed on an unsupported browser, operating system, or platform. "Failing gracefully" means no incomprehensible error messages, and telling the user why they’re not able to access the app.
At least one of the users of your software does not speak English as a first language, possibly not as a second or even third. Someone will be using your application with the system locale set to another part of the world, so try it before they get their hands on it. Figure out how to display your app in Greek, Cyrillic, Mandarin, and Farsi.
Colour-blindness is statistically more likely in males, and they often have one of the two red-green versions, not the blue-yellow. Some people see only shades of grey. Cell phones have accessibility applications that can show you what a person would see if they are colour-blind, use those options on your application. Don’t rely on colour to be an indicator in your application.
Can your app be zoomed in, to help people who are severely vision-impaired? Try using the accessibility options on your desktop computer and see how easy or hard it is to navigate and use the application.
See also From QA to Dev