Test your Twitter
I'm seeing more and more testers using twitter these days, so I thought a tip on designing and testing your tweets might be helpful.
Jakob Nielsen's Alertbox has a great lesson on designing your twitter post. He uses an iterative design process to make sure you express yourself clearly and succinctly.
Essentially, you need to:
- Grab the user's attention. In his example he uses capitals to identify key words in the tweet
- Front-load the tweet with attractive keywords
- Be specific and try and keep your tweet to 130 characters so that others can re-tweet
- Save space by abbreviating over full sentences
- Don't make multiple points in your tweet
- Think about when you post your tweet
It's much better put by the man himself. You can find his post here: http://www.useit.com/alertbox/twitter-iterations.html
I like the way he partially shortens the URL link to help emphasize the point of the tweet.
And you thought twitter was easy!
Keeping it personal
People can be messy can't they? They can be unpredictable and can disagree with you and your opinions. Because of this, it's easy to shy away from communicating directly with others and resort to email and documents to present information, especially if the news is bad. A scenario we testers are often faced with!
But communicating directly with someone either face to face or by phone is a great time saver. I will give you an example.
My current client has a very 'organic' way of developing software. Having no experience in IT development, a lot of the typical methods of communication just don't work. Status reports are left unread on desks, emails and bug reports are ignored. I was finding it hard to get him to understand that the quality of the software was just not there. Until I resorted to 'the face-to-face'.
I called him down to the showroom and showed him all the bugs I had found that morning. He was stunned and amazed to see what issues I was finding. It helped him understand how far there was to go on the project.
This simple face to face event saved me a lot of time and him a lot of money.
You may not work in such a 'flexible' environment, but its still possible to incorporate verbal communication into your testing tasks.
Here are some suggestions:
- Talk to your developer before writing up important bugs
- Show your stakeholder bugs to clarify what type of testing is required (Is this bug important to you?)
- Show your stakeholder the application status instead of writing up a status report
- Hold a workshop and discuss the application with developers and shareholders before testing
I'm sure there are lots of other ways. If you can't communicate face to face, phone and even IM are good alternatives.
Working in groups vs. alone
Following up on yesterday's post on finding and protecting your most productive time, pay attention to who you're working with and how you're working with them. Take for example the following poll I found in Writers Digest magazine:
How do you do your best writing?
a. By working alone
b. By meeting regularly with a writing group
c. By participating in an online community
d. Through all of the social options above—and more
In the poll above, 85.7% of respondents said they do their best work alone. The other 14.3% said all the social options above. That resonates with my experiences as well (as a writer and as a tester).
I often think writing is a great metaphor for software development. In this particular case, it's spot on. We do a lot of work alone. We do a lot of work in meetings or with team members. And we use a lot of social media (IM, email, wiki's, project blogs, RSS, etc...).
I do my most productive work alone. While I appreciate the feedback that comes with working with others, I know I'm more productive when working alone.
Guard your most productive time of day
I know when I'm my most productive. It's somewhere between 6:00 AM and 9:00 AM. I'm lucky actually. Few people schedule meetings during that time. (Where I work right now, few people are even awake during those times.) It would be much worse if my most productive time was right after lunch.
I call that time period my most productive because it's where I turn out the most X. For me, X could be code, words (for an article or blog post), or test ideas. I do my highest quality and most prolific work during that period of the day. It has something to do with my head being clear and the coffee just kicking in. I'm not thinking about life's pressures yet because my day just started, my email queue is empty. I just get stuff done.
If you know when you're most productive, do everything you can to protect that time. Block your calendar so people don't schedule meetings. Turn off your phone and close your email and instant messaging clients. Do what you have to keep the world at bay. Try to create at least two or three hours for yourself where you know it's your time to get stuff done. And if possible, get that window to overlap with when you're most productive.
Try passive voice
Today's tip come from dailytestingtip - a recent Twitter creation similar to this blog. It's been started by our newest QuickTestingTips author, Anne-Marie Charrett.
"If bug reports are getting developers riled up, try adopting a passive voice approach to writing."
The post then links to Ivan Walsh's post on when you should use passive voice. From that post:
When to use the Passive Voice:
1. To emphasize the action being performed; the active voice highlights the person doing the action.
2. To show that results are more important than the person/system performing the action, for example, ‘the errors were generated by the system.”
3. To avoid assigning blame to a person, for example, “An error occurred when the system overloaded.”
CoE’s might need sales people too
Yesterday I read this article by Jill Konrath on 7 Sales Mistakes Guaranteed to Make Your New Service Fail. It reminded me on when I was working to build out a centralized testing group in a large organization. In many ways, I was the business developer for my team within the organization. We may have been a Center of Excellence (CoE), but we weren't really required to be used. We had to earn our business.
The tips in the article that resonated with me the most were:
Setting up meetings to update customers about the new product or service can lead to trouble. Arranging the meeting isn't the mistake—just its premise. If sales reps tell customers they're bringing information about the new product or service, that's exactly what customers expect the meeting to be about. Sellers then find it exceedingly difficult to switch into a questioning mode—an essential step for determining valid business and financial reasons for changing. Instead they're expected to talk, talk, talk—and boy, do they ever!
and
If salespeople don't have a clearly defined next step implanted in their brains prior to the call, they are doomed. Just sharing exciting new product information gets sellers nowhere. Unless they have a clearly defined objective before the call and are ready to offer logical next steps, they'll be left sitting by the phone waiting for it to ring.
We "sold" automation and performance testing "products" to project teams. Getting teams to use us, and getting them to pay for enhancements to the products we provided, was in every way a sales call. Good advice - read the entire article.
Staying out of testing ruts
I'm invoking the pirate heuristic today and stealing from David Christiansen. Dave wrote a great set of tips on how to recognize when you're testing might be in a rut. In the post he identifies the following test-fatigue-symptoms:
- Randomly pounding the keyboard for data entry.
- Not taking good notes.
- Chasing esoteric bugs when you don’t have time.
- Not bothering to isolate bugs.
- An inability to think of any error scenarios to test.
Read his post for some tips on how he breaks out of a rut when he recognizes he's in one.
What ruts do you find you fall into? His "asdf" rut resonates with me, I know what one well...
Deliver difficult feedback
I recently had a couple people who work for me provide me with difficult feedback. Difficult for me to hear, and I'm sure it was difficult for them to say. If someone you work with needs feedback, even if it's difficult, be willing to provide it.
If you're not sure how to do that, I recommend starting with Crucial Conversations. It's the first step in becoming an Influencer, but it's also an important step in building the team you want to work in. You need to be willing and able to talk with your boss and peers about difficult topics.
Note, those two books are written by the same authors. I'm a fan of their work, and I've read "Crucial Conversations" around five times now. They've also written a book called Crucial Confrontations. I'm less of a fan of that book, but I only think that's because it seems like it's only a specific application of the general principles laid out in "Crucial Conversations."
Share articles, blog posts, and podcasts
One thing that happens at my current company that hasn't ever really happened in the past is that we share a lot of media. There is rarely a week where there isn't a flurry of emails forwarding an article, blog posts, or podcasts on tops related to the technologies we work with, programming or agile, or some other aspect of development. It's great. Not only do I get insight into what others are reading (and where they get their news and insights), but I also get to share topics that are important to me.
If you read something you think is profound (like all the content in this blog of course) or excites you (like a new tool or an idea from a podcast), pass it along to a group of your co-workers.
Stock prices and software testers
Similar to Friday's post on baseball cards, I have another interesting metric I think about. It's my stock price (also known is some circles as "street-cred"). It works like this, I think everyone on a team has a fluctuation stock-price. It represents how attractive they are to work with at any given time, encompassing both their perceived productivity and personability. If someone severely flubs up a project or is simply a jerk to work with, their stock price goes down. If they are particularly strong at a skill in high demand, their price goes up.
Think of it like this, if five managers were building teams from a pool 100 candidates, and they each had fixed and equal "budgets" and could choose team members from the pool, what would they be willing to pay for any given candidate? The price of any given member would reflect the "future earnings" (or project value) of the person being brought onto the team.
Editorial comment: It's a thought experiment... It's not perfect, roll with it. I'm not saying this would be a good idea for a company, I am saying it's a neat thought experiment for the following reason.
If you're a software tester (and I have to assume you are if you're reading QuickTestingTips), think about what might affect your stock price. What are the factors that you think generate "street-cred" and make you a more valuable team player (and thus a higher-value team commodity)? If you had to issue quarterly and annual (testing) reports, what would be in them? How would you position yourself so you could demand a higher price?
Similar to the Friday post, if five people respond, I'll post my answer. The more people respond past that, I'll try to get the other authors on this blog to post their thoughts as well.
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
