Hello World
This is a test. Think of it as an test of WordPress analytics. No really, you're participating in it right now. I'm curious who's reading this thing we call QuickTestingTips. Here's your mission - should you choose to accept it...
There are two steps:
- Right NOW: leave a comment on this post. Be sure to include a link to your web page, blog, or twitter feed - your choice. Something that lets the world know who you are. Say anything, just don't say you don't like the site. That's not cool. We're fragile.
- Tomorrow: Come back and see who posted. Check out who they are. Follow them on twitter or RSS their blog. Connect to someone new - who you've never seen or heard before.
I'll likely turn off comments after the first day. (Otherwise it's not a very effective measurement is it?)
Update: I didn't turn off comments. I figured it would be better to let the links continue. Please post!
Leverage heuristics for speeding up recall when communicating
When you work with someone for a long period of time, you start to develop a shorthand for communication. Similarly, many of us have found that we leverage a lot of the same heuristics and mnemonics for communicating how we're thinking about the problem and where we're at with our work. This can become incredibly powerful as a means of saving time during documentation and verbal communication.
If your team regularly uses mnemonics like FIBLOTS, MCOASTER, SFDPOTS, HICCUPPS or SLIME then you can in many situations save yourself some verbiage and just reference those mnemonics or heuristics. If you find you don't have one for a process or technique you often practice - then CREATE ONE! And share it. For some idea of the mnemonics out there, check out this list curated by Lynn McKee.
(How can you not freaking love a mnemonic called SLIME?)
This tip was part of a brainstorm developed at the September 2011 Indianapolis Workshop on Software Testing on the topic of "Documenting for Testing." The attendees of that workshop (and participants in the brainstorm) included: Charlie Audritsh, Scott Barber, Rick Grey, Michael Kelly, Natalie Mego, Charles Penn, Margie Weaver, and Tina Zaza.
Saying no
Some people struggle with saying no. It happens for a lot of reasons:
- we want to please others
- we really do want to do what we're committing to
- we are afraid to say no
- etc...
Here are some tips for saying no that I've found helpful:
- Force prioritization: "If I do that, something else needs to fall off my plate. What would you like that to be?"
- Remind them about long term effects: "If we write this code without writing our tests according to our methodology, in six months you'll regret it when we need to refactor this section of the code."
- Clarify that you're being asked to do something you can't: "You recognize that you're asking me to make a commitment that I can't really make, correct?"
However, no matter how you sugar coat it nothing beats a plain-spoken "No, I can't or I won't do that."
Practice it. No is more difficult than yes. Especially if you're saying it to yourself. Trust me when people would rather hear "no" upfront then have you say yes and then they don't get what they wanted.
Ask for help
Here's how I can tell I need help:
- I'm working at 1:00 AM and it's not because it's required (like some performance testing) or because I really like doing it (too much cool software and not enough daylight time).
- People are talking about something that needs to be tested and I can't follow the conversation (due to a lack of domain knowledge or technical knowledge).
- I'm missing deadlines (for the project I'm struggling with or for other projects because I can't get away from the project I'm struggling with).
- I'm not happy with the quality of my work.
If one or two of those happen for a short period of time, I probably need help. If all of them are happening (like they are right now), I know I need help.
When you need help, ask for it. That's easy to say, but hard for a lot of people to do. I know it's hard for me. I also know it's hard for many people who've worked for me. For me, it's an ego thing. But sometimes I need to recognize that I'm not helping anyone (most of all myself) by trying to hide the fact that I need help. Often, help is there - ready and waiting to be had.
If you're overwhelmed, ask for help. You might be surprised where it comes from.
Listening Driven Testing
A lot of testers know that if you want to be able to test well, you have to ask lots of questions and not just to one or two developers, but to a whole range of people who have some vested interest in the product your testing. We ask questions to understand the context. We ask questions to understand the application we are testing.
I wonder though, am I the only tester out there who is not that great at listening to the answer?
I ask the question, I hear the answer, what the Project Manager, or Marketing Director says, but that's different to listening.
Listening means, "I hear what you say, and I will take that into account"
As a tester with a bit of experience, I have to confess I sometimes think I know best. I go into "Yeah sure, that's what you think you want, but here is what you really need" mode and forget to listen to other people.
It takes respect and humility to listen properly to other people. Its something I want to improve on. I know it will make me a better tester in the end.
So, next time you have that conversation with your colleagues or potential clients. Do yourself a favor and really listen to what they have to say. You might even learn something.
Merry Christmas
Don’t be a paperweight
Picture a boat anchor made out of stacks of paper.
That's what I call a paperweight - a tester who literally drags down projects because of the amout of paperwork they generate and/or require. They don't add value, they just add paper (digital or physical).
Dave Christiansen often talks about being an asset. Paperweights are on the opposite end of assets, they want you to do stuff for them. You need to provide them with information. You need to provide them with an environment. You need to provide them with test data. You need to clarify their requirements. You need to ...
A paperweight can't do, they can only ask...
It's been a while since I've encountered a paperweight. Recently, I've seen one in action. They are a visible drag on progress. They slow down the project, without adding value.
Don't do that.
Recognize that nothing about testing dictates that you need to be a drag on the project. That doesn't mean you can't ask for things. It doesn't mean you can't raise issues and risks when needed. But always always always do it from the position of being an asset to the project team. If you're doing that, trying to help move the project forward in the safest way possible, you'll have nothing to worry about.
Getting along with developers
David Christiansen recently published an article on getting along with developers. Some tips from that article:
- Don't editorialize the bugs you find
- Stay in sync with the development cadence
- Isolate bugs effectively
- Sleep on bug reports
Check out the full article for details on each point.
Don’t let your distrust of software influence your trust in people
Today's tip is guest written by Zachary Fisher.
Working as we do, it is easy to let skepticism become our default position on any statement made by any person. At any time. On any subject.
This behavior becomes maladaptive when we see ourselves as the only person who can be trusted. It thrusts the onus of proof onto ourselves and causes us to micro-manage every minute detail of our lives and/or project. This dysfunction reveals itself in subtle ways: we keep details from others while trying to figure it out, preferring to create tools rather than relationships, not delegating crucial tasks because someone else won't do it right; basically seeing ourselves as the hub from which anything done right flows.
As a manager of resources, i.e., people, time, money, etc, we should walk in the light of some truths:
(1) We can be wrong sometimes
(2) We will be wrong sometimes
(3) Other people can forgive
(4) Other people can help
(5) Grace abounds in humility
So if the project is taking on gargantuan proportions and you're being consumed by fears of catastrophic failure - take a step back and ask yourself if the task seems so great because you secretly envision having to do it all yourself. If so, kudos for being a responsible adult. Now, take a step of faith and give other people the opportunity to prove themselves as trustworthy as you've become.
Using your product expertise wisely
In small companies especially, software testers get to perform lots of different tasks apart from testing. A software tester doesn’t just know how to use a new product, but invariably knows how to install, configure, work around issues, upgrade and back up data. Software testers will also know about minimum requirements and the applications limitations.
Not surprisingly, a good software tester starts to get a reputation of being a bit of a product expert. Someone people can come to to get product knowledge. Or someone who can setup demonstrations as well as perform them. This is very gratifying, but it can also lead to problems if it starts to impact your own work.
This can lead to stress and can often be a cause of resentment. It's best to try and manage this situations early on. I find the following approaches helpful:
1) Learn to let go
Try not to perform tasks for people, but teach them the basics and let me go and learn it themselves. If lots of people are asking for the same thing, consider writing a short cheat sheet or posting stuff onto wiki.
2) Learn to delegate
Always make sure someone else trains up with you. Don’t be the only person with all the knowledge. Make sure you share it by training up other team members.
3) Learn to say no.
Sometimes its better not to take on work that is inevitably going to compromise your deadlines and deliverables. Say No, explaining why you are unable to help. You may upset people initially, but in the long term you are not doing anyone any favors by taking on too much work. If your decision is overridden you may still have to go and do the extra work, but at least people are aware of the compromises being made.
If you are the only person who can fix things and you are overstretched, you are in fact more of a liability than an asset. Spread your knowledge and let you and your company benefit from your wealth of knowledge.
Promiscuous Pairing
If your team already does some pair testing, take a look at promiscuous pairing.
"Promiscuity, it turns out, is a good way to spread a lot of information through a group quickly. Rapid partner swapping ensures that a good idea, once envisioned, is soon practiced by every pair. Replacing individual accountability with team accountability empowers each person to do those tasks at which he excels — and allow someone else to take over for his weaknesses."
Try 60 to 90 minute sessions where you alternate partners each session.
Categories
- Accessibility (4)
- Automation (26)
- Availability (1)
- Bias (8)
- Bug Reports (26)
- Career Tips (8)
- Collaboration (3)
- Compliance (1)
- Database (3)
- Disaster Recovery (2)
- Documentation (31)
- DOS/UNIX Apps (1)
- Estimation (1)
- Exploratory Testing (29)
- Free Tools (78)
- Heuristics (57)
- Hiring Testers (1)
- Internationalization (5)
- Learning about the product (8)
- Mind Mapping (11)
- Performance Testing (34)
- Playing Well With Others (42)
- Practicing Testing (9)
- Regression Testing (2)
- Security Testing (13)
- SEO (1)
- Skilled Bug Investigation (13)
- Stress Testing (1)
- Technical Tricks (3)
- Test Data (17)
- Test Management (33)
- Test Oracles (2)
- Test Planning (33)
- Test Theory (5)
- Testability (1)
- Testing mobile (6)
- Testing Techniques (18)
- Time Savers (31)
- Tools under $100 (11)
- Uncategorized (2)
- Unit Testing (2)
- Usability (13)
- Web Testing (32)
Authors
- Albert Gareev's website
- Anne-Marie Charrett's blog
- Jonathan Kohl’s blog
- Julian Harty’s website
- Karen Johnson’s blog
- Mike Kelly's blog
- Rick Grey's profile
