Questions to help clarify test status
Stealing from a post I did on SearchSoftwareQuality.com, here are some questions I use to clarify testing status when doing debriefs:
- What was your mission for this session?
- What did you test and what did you find?
- What did you not test (and why)?
- How does your testing affect the remaining testing for the project? Do we need to add new charters or re-prioritize the remaining work?
- Is there anything you could have had that would have made your testing go faster or might have made your job easier?
- How do you feel about your testing?
Confirm estimates with a different approach
When estimating, I often start with a bottom up approach. That is, take the individual tasks, estimate each of them, and look at the total for the project. Once that's done, I try to step back and check my estimate with a top-down approach. In that approach, I ask how many people I think I need, for how long, and see what the numbers work out to. I'll keep going, making changes to both estimates, until the numbers converge. It's a nice simple way for me to check for the reasonableness of any estimate. There are other techniques that can be used as well. What's important isn't the technique, it's more that you're doing some sort of double-check before you make the commitment.
Knowing the details
I've seen a lot of test managers (and/or testing project managers) who don't know the details of what's happening in their projects. They attend the meetings, keep plans up to date, give out assignments to the team, and make sure all the charts are up to date. But they never really develop a working knowledge of the project or a feel for the testing. I don't like to work that way. When I'm managing a testing project, I want to know the details.
There are a couple of key ways I do this:
- I try to contribute to writing, editing, or (at a minimum) reviewing all the test strategies, plans, and schedules (many of the larger projects I've worked on have several).
- I review test cases, scripts, charters, or results (depending on the team's approach). I also review the test data being used.
- I read the defects - all of them. I want to know where the issues are, what they are, and what they look like.
I think developing my understanding of the defects is the most important aspect for me. It helps me develop an intuition about the software and it's state. It also keeps me in tune with what work is actually taking place. They other stuff is important, but if I really want to know what's going on, I look at what's getting executed and what's coming out of that work.
Is your testing process this clear?
In my opinion, one of the biggest success factors for a centralized testing organziation is a clear engagement model. One that starts with new project intake and ends with project closeout, follow-up, and portfolio management. I've tried to tackle this problem at two different organizations, and at each one I struggled to get clear and easy to follow definition around what we did.
Take a look at how HUGE laid out their process. I understand that it's marketing material, so it's obviously going to be pretty, but look past that. They lay out seven clear phases for engagement. Each phase has a summary of the steps that will be undertaken in that phase.
If you're centralized group offers products and services, imagine that your products and services are listed next to those phases. Those are the various products and services teams could expect during each phase. I find it to be a very simple visualization for what your organization might offer to project teams.
Assign a tool guru
This is a management tip I've used that's worked well.
Have someone on your team own each testing tool. Have someone be the tool guru, the go to person to learn from, the person who knows when the license needs to be renewed.
If you host brownbag learning sessions an occasional tool review is a good topic too.
Test in parallel with debugging and fixing
While it's inspired by something Ross Collard once said to me, this tip came home for me this week while talking with a fellow test manager who was struggling to find enough time to test. Don't forget that while developers are fixing bugs for the next build, you can likely keep testing. Major blocking bugs aside, if you've still got the code there's likely something you can keep moving forward on. Just because you're turned around enough issues for them to work a new build, doesn't mean you have to stop.
Even if your process states you shouldn't be submitting bugs against a known bad build, you can continue to:
- learn about the product;
- develop test ideas;
- execute tests for areas you believe to be stable;
- develop test assets (like automation, or performance tests);
- etc...
All of those require some version of the product, even if it's not the final version of the product.
Only list the technologies you’re fluent in on your resume
Only list the technologies you're fluent in on your resume, or make it clear what your skill level is if you're listing things you've had exposure to in the past. I use to add qualifiers to my resume; like beginner, intermediate, and advanced when I listed a tool, language, or technology. Now I don't list very many technologies at all, since most managers I've interviewed with have been less concerned with technology and more concerned with skill. I think that's natural as you get more experience under your belt. But I could be wrong.
When you're pulling together your resume, only list tools and technologies that you actually know. Don't list the stuff you've had "exposure" to. If I can't ask you an interview question on it (like, write code in language X, or tell me how you would configure Y, etc...) then you either don't want to list it, or make it very clear that you've only had exposure to it. When looking at resumes nothing turns me off faster than seeing a laundry list of tools and technologies without context for how they have been applied by the candidate.
For me, it comes down to trust. In an interview, I'm trying to figure out what you can really do. If you get my hopes up by listing Java, Ruby, or some other techno-widgit I'm really looking for, and you can't actually do it, I don't know what else you can't really do that you're telling me you can. Even if you're really good at all the other stuff, once I feel like you've falsely represented your skills, it's hard to dig out. On the other hand, if someone has all the right skills but is missing the techno-widgit, I'm likely to hire them. I can teach someone Ruby.
For me, loosing the interviewer's trust isn't worth the eye-candy of listing all the technologies.
Get out of the office
Sometimes, when you have a pile of work to do, and you just can't find the time to do it, it means you need to get out of the office. The office comes with distractions: people stopping by with questions, noise from across the hall, email, IM, and phone calls. Getting out of the office might mean working from home, working at the coffee shop down the street, or even just book a conference room and working in there. To make the time most effective, give yourself specific goals for the time you block off. What are you hoping to finish during that time you're away. While you're away, turn off the phone, close IM, and don't check email. Get done what you need to get done.
Periodically clean out the backlog
Defect databases get big quick. Even on a well coded, well run project, if the development team is firing on all pistons a backlog of possible issues, bugs, and feature requests will build up. Over time, tickets can get stale. They become less relavent, are fixed indirectly, or change in priority/severity. From time to time, get in there and clean em up!
This activity can be rewarding on multiple levels. First, if you just go in and clean our your personal backlog (the tickets in your queue), you get a better idea of the work that's really on your plate. This both reduces the burden you might feel (like when you have an empty inbox), and also helps you prioritize the work better. Second, if you clean up, update, or refresh all the tickets you've entered (possibly hitting other people's backlogs), you give that same small charge to the entire project team. If everyone does it regularly, the database of tickets remains clean and relavent.
