QA skills besides testing

Figure out who you are
The Myers-Briggs Type Indicator (MBTI) test is useful. Are you an introvert or an extrovert? How do you handle stress? Are you a pattern-noticing person? Are you a visual, tactile, textual, or auditory person? Try a DiSC test.

Figure out how you learn
QA is a career that requires continual learning. Find out what works for you (books, video classes, working through problems, pairing with someone who knows the skill you want to develop). Experiment with different learning methods. How did your favourite teacher work?

How do you transmit information
Others learn and process information in different ways to you. Find out the ways to simply and clearly convey ideas to groups of others. Teach something to a person that does not learn the same way as you do.

Taking notes that will be helpful to you later
You're not going to remember everything. Use flashcards, coloured sticky notes, diagrams, doodles, sketchnotes, a notebook, Evernote, Google Drive, find some way of storing data to find it later. If you use a notebook, consider indexing it (add page numbers, make a spreadsheet of topics). In six months time, you will have lost the context you currently have on your project, so find a way to record that information and get it to the people who will need it.

How to talk to difficult people
People who have done customer service or tech support have developed skills for dealing with that one customer that is furious with everyone and taking it out on you. You learn how to steer people towards an answer, how to stay calm under pressure, how to think on your feet, and how to say no. These skills are invaluable.

How to be a good part of a team
Quality Advocates are part of two teams: their product team, and the team of Quality Advocates across offices. Other QAs have a wealth of knowledge and information and they are happy to share it with you.

How to ask questions
Sometimes we ask questions we know the answer to, in order to help someone else get to the same answer. A well placed "can you help me understand X?" can uncover a hole in someone's thinking. You learn by teaching to others, and by getting someone else to teach you, you help them know the subject better. And you learn something too.

How to listen
Listen so you can reply and add to the conversation. Don't listen for a break so you can say the bit you were thinking about while they were talking to you. Pay attention when people are speaking.

Sharpen your observational skills
Who just got a haircut? Who looks like they didn't sleep well last night? Who looks happy, or sad, or angry? Play 'find the typo' with every email you get. Learn to see visual bugs in apps, use a sticky note as a straight edge to check if things line up.

Know when and how to argue.
Always fight fair. No manipulation, no passive-aggressive behaviour. Speak clearly and with precision (say "four days this week" instead of "all the time"). Don't talk over people.

Drive your own career
You are responsible for your own growth and learning. If you need help, ask for it. If you don't take the advice of people trying to help you, that is your choice and the consequences of your choices are on you. If you see something you want to learn, go learn it, you don't need permission.

Practice 'recreational QA'
Find bugs in the wild, and try to figure out how you would test so that bug did not get past you. Proofread books as you read, look for typos and wrong grammar. Try and figure out what game designers were thinking when they made your favourite game.

Talk in front of groups
In retrospectives, team stand-up meetings, and other meetings, you will need to address groups. Put the points you want to cover on an index card and use it as a prompt when you get nervous. Everyone is not staring at you, they will not throw rotten fruit. Take a prop with you to hold if it makes you feel better.

Find out what resets you from stressful situations
Try a short walk, a cup of tea, a quick stretching exercise, a few minutes of silence and meditation. You will be in situations that poke your sore spots, reacting emotionally will not make things better. Recognise your emotional state and take the steps you need to return to a calm center, without freezing off or bottling up your reactions.

Figure out your blind spots
If you're a lifelong iPhone user, find out how to test Android phones, and vice-versa. Web app people can look into iPad apps, Windows people can get a Linux VM on their machine to explore. Ask people you work with to tell you what your weaker skills are, and listen to them.

Figure out what you're trying to improve
You improve with deliberate practice on your weak spots in an environment where it is OK to make mistakes and not be perfect. If you only operate in your strengths, you don't improve over time. Keep your focus on the skill you want to improve and act in ways that will force that growth. Then focus on another area to improve.
From Anna Z: Always know what your short term and long term professional goals are, use SMART goals (Specific, Measurable, Achievable, Relevant, Time-bound).

Where are the unknown unknowns?

Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – the ones we don't know we don't know. And if one looks throughout the history of our country and other free countries, it is the latter category that tend to be the difficult ones.

Quote from then United States Secretary of Defense Donald Rumsfeld, in answer to a question at a U.S. Department of Defense (DoD) news briefing on February 12, 2002.

I love this quote, because in software testing, we are always hunting the "unknown unknowns," that bug we believe exists but haven't caught up to yet, that new technique for a different kind of test we haven't tried before, and the hunt for the pernicious but tiny flaws that grow over time into horrible ugly nastiness.

What makes a good software QA person?

We have a few quirks, a hint of obsessive compulsive disorder, and we’re brutally honest. We never lie to our developers. We don’t sugar-coat, soft-shoe, back-peddle, exaggerate, or outright lie. We can’t. Our job requires us to be utterly truthful. We’ll tell it to you straight, we’re paid to be honest.

We think this stuff is funny. And it is! You have to appreciate the bug found in the wild, the "disastrous misconfiguration" error message on Chrome when it finds a "weak ephemeral Diffie-Hellman public key" (it has to do with TLS encryption), or the mall TV screen showing a Blue Screen Of Death. It’s free entertainment, but it also makes you think: what got missed that this bug escaped into the real world? How do I find a bug like that? How would I reproduce this bug? We know other people don’t always appreciate the humour in a good bug find, but a QA always will.

We’re in the details. There’s a slight correlation between being a good Dot Net developer and having blue eyes, based on two companies I've worked at. I notice colours, including eye colours, and I’m always looking for patterns. I spot when someone has matched their glasses, fingernails, shoes, toenails, and purse. If a line on a user interface is bumped down by a pixel partway along, I’ll see it. The fact that there are different numbers of steps between floors in my office building is a source of amusement, and some floors are a prime number of steps apart. When you use the back staircase, you get different numbers of stairs between floors. In the main stairwell, the door out isn’t on a consistent side as you go up the stairs, sometimes it’s on the south side, sometimes on the west. We live for details and patterns, sequences and clean lines.

We need more input, more tools, more tricks, more ways to play. More languages, more front-end and more back-end knowledge, and the stuff in between. Once we know about injection attacks, we'll test that everywhere we can. We're the reason you have client-side and server-side validation. "Why" and "how" are the most used words we know, followed by "what if". We're not trying to take your job, we want to know enough that we can see the weak spots in the armour, right where you think we could never shove a buffer overrun but we do it anyway. We have an insatiable need to learn and we're not afraid to be the least-informed person in the room while we pick up something new.

We ask a lot of questions. Some of them we already know the answer to, we're trying to show you something in a gentle and non-confrontational way. Some of them we have no idea what the answer is, and it may be an obvious or dumb question to a developer, but we need to know. Asking questions is one way to find out. Breaking stuff is another, and scenario questions ("what if the user does X or Y") are a third. We have an idea of how you're feeling from how you talk and type and move, we pay attention to that.

What NOT to say to your QA

It's a feature, not a bug.
But why would you even do that?
QAs are just failed developers.
My code is perfect, I don't write bugs.
You're not supposed to do that in the app.
It's a design error, not a bug.
I'm not fixing that.
Why are you worried about that? No one ever does THAT...
QAs aren't technical, they don't need to attend to that meeting.
You're testing it wrong.
This doesn't concern QA.
Get me on %MANAGER%'s calendar for tomorrow afternoon.
It works on MY machine, so it's fine.
Load testing is for developers to do, not QAs.
We turned off all the tests.
The user will never be able to do that, so it's an invalid test.
It'll be fine in production.
You're using invalid data, that's why you think it's a bug.
This way is better.
You need to take notes in the meeting for everyone.
QA can do that admin task, they're not doing anything worthwhile.
Where are the batteries kept?
Can you hurry up? We have a deadline.
I thought you were a nice person.
So when will you be DONE?

(Some mine, others collected from Asynchrony QAs Slack channel.)

The Red Team Rules for Software QA

I found the Original 12 Red Team Rules recently (there's profanity in the list), and a lot of them are relevant to life as a software quality advocate/analyst/engineer/assurance person with a bit of modification.

Rule 1: Know when the test will be over.
(Was: Always have an escape plan).

Rule 2: Be aware of the environment for your app, database, network, mobile devices, etc. (Was: Be aware of your surroundings.) Different environments require different testing strategies and tools.

Rule 3: Assume nothing.
(Was: Assumption is the mother of all f***ups.) Get your acceptance criteria spelled out, and if there's not code in place to stop you trying something, do it.

Rule 4: Vary your attack.
(Was: Always have a backup plan.) If you don't find a bug the first time out, try something different. Someone that always tests the same way won't find new kinds of defects.

Rule 5: Never get caught by surprise.
(Was: Never get caught.) Know your application, who will be using it, how they will use it, and its vulnerabilities.

Rule 6: Collaborate effectively.
(Was: Keep your mouth shut.) Quality is a collaborative process, but talk with respect, and don't log a half-baked bug report that can't be replicated.

Rule 7: KISS: Keep it simple, stupid.
This applies equally to QA and the Red Team. Write stories, acceptance criteria, bug reports, and regression test plans that a total stranger could follow. Because in six months time, that total stranger could be you.

Rule 8: Simple and light equals freedom, agility and mobility.
Don't get bogged down in a document-heavy test process. Test Driven Development will help if you can read code (and QA people should be reading the code).

Rule 9: Do the job and then go home.
(Was: Plan, execute, and vanish.) Tired and cranky people do poor work.

Rule 10: Automate the boring bits.
(Was: You don’t have to like it - you just have to do it.) Sometimes we have to do repetitive stuff. Automate it if you can so you don't have to do it again, but don't duplicate automated tests.

Rule 11: Always invest in good quality stuff.
Get the right tool for the job and learn to use it well. JMeter is unfriendly but provides excellent information.

Rule 12: Trust your gut.
If you have a hunch there's a bug in an area of the application, keep digging until you find it.

Your software project might have a QA if…

Some of these are mine, some I lifted from the company Slack channel for Quality Advocacy.

  • You're used to finding Cyrillic or Greek or Mandarin in the database
  • There's code in place to stop you copying War and Peace into the app multiple times
  • You know how the system reacts with 10 users, or 50, or 500, or 5000
  • Your developers know what happened in Europe between 4th and 15th October 1582
  • You have client-side and server-side data validation
  • This conversation: "But why would you even do that?" "Because there was nothing to stop me."
  • You know when Daylight Savings Time starts in Australia
  • Names and addresses make you nervous
  • Your app looks stunning with the colors reversed
  • You know how to close your h3 tags
  • You fear what will happen to everything run by computers in January of 2038
  • Your app survives a genuine DDoS attack in production and everyone shrugs because "she's done worse to us in dev."

Sh*t my QA says

There is a bug, I just haven't found it yet.

Well, it's broken on my machine!

In the Danish version of Windows, if you click really fast, the app just crashes.

It doesn't work when I put Cyrillic text in. Or Greek, Hebrew, or Mandarin.

One copy of "War and Peace" in the description field was OK, but the second crashed it.

What if you rotate the screen/turn on airplane mode/get a text/drop the phone into the toilet from ten feet up?

The app doesn't handle itself well if you delete its database after you log in.

Ooh, I haven't seen it do that before! Wonder if it'll do it again?

Can't stop, I saw a bug and I'm trying to find it again.

(From a QA friend) There you are, you little sh*t! I have you now!

Words to a new software QA

We're not after the developers. We're after 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 customer 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.

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 an amazing resource and are usually very helpful when presented with a "Can you please help me..." request.

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.

From QA to Dev

Dear programmers, a few notes from your QA team lead:

We don't actually hate you.
Not by default, and not at first. It takes time and effort on your part to earn the ire of the QA team. But if you tangle with one of us, you tangle with all of us. We talk about you. We trade horror stories about that one bug that took weeks to fix because you stalled every step of the way. Yep, we remember that one well. You can redeem yourself, but it's not easy.

We want the same thing.
We want the best possible product to go out of the door and our job is to make you look good, rock star good. Sometimes, you get in the way of that.

Sloppiness annoys the snot out of us.
Like that zip code field in the database that only accepts ten characters, but we can enter 255 in the app? That's something you should have thought of before you checked in the code. Spell check is your friend when you're doing UI stuff. Think before you type.

You and I think alike, but we're different.
You build it, we break it. Good QA people can program in your language, so we understand what you're talking about, and we might have a suggestion as to how it could be done differently, or something you missed. Try bouncing ideas off us once in a while. Also, we may have an idea of what you're actually doing, so lay off the BS about how hard it is.

We are extremely picky because we're paid to be picky.
It's not personal, it's just how we are. Details are important and we care about all of them. Even the annoying ones. We also like the pictures to hang straight on the walls, and shoelaces to be tied neatly.

We don't expect you to be perfect.
If you were perfect, we'd be out of a job. We know you're not perfect, and neither are we. What we'd like is for you to accept that you're capable of making mistakes and missing details, and stop acting like we're out to get you. Trust me, if we were out to get you, we'd be waiting in the parking lot with pitchforks (we keep them in the server room, just in case).

We're not perfect either.
Guess what? We make mistakes too! It's OK to tell us when you think we're wrong, but please don't be a jerk about it. It's not a contest.

Just fix the darned bug already.
We don't care about whose fault it is, or how hard it was to fix, or how Joe Coder did such sloppy work you have to refactor all his stuff to fix it (believe me, we already know all about Joe Coder). We just want the bug fixed so we can re-test it and get it out the door and we have no patience for whining.

Never, EVER break the build we're working in.
Please make absolutely sure the app will both compile and run before AND after you check your stuff in. If you break the build we're WORKING IN, we're dead in the water till you fix it. We'll come and sit in your cube and stare at you until it's fixed and we can go back to work.

Test it before you send it to us.
If we can't even get through the happy path, then dude, what were you thinking when you checked the code in? (See "Sloppiness annoys the snot out of us")

If you don't understand us, talk to us.
Sometimes we don't communicate all that well. Some things just make more sense face to face. Come talk to us, we rarely bite programmers.

See you at the release party!
Love, your QA team.

(Yes, I really am a QA team lead.)