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.

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.

When learning about the product you're testing, sometimes it can be helpful to read support and developer forums. This of course assuming your product has those forums. If not, call center logs and FAQs can also do the trick. A lot of people only use information like this to see what doesn't work or where the product might have issues. And it's good for that. But you can also learn:

• Where have people become subject matter experts?


• Where is there a lot of energy for the product? (Think of this in terms of traffic for a particular forum or topic.)


• What new features (as opposed to bugs) do people ask for?


• What are people doing that's not done the way the designers expected?


• What other products are often mentioned in association with this product?


• etc...

You can learn a lot in forums, not only about the product, but about the culture of it's users.

One of the things that can be difficult while testing in sprints is to know where your testing fits in the bigger picture. If you're testing a feature for the first time that was just developed in the sprint you're testing, it can be hard to know when it will be released, what it will be released with, and what other testing might take place. This creates a strong need for coordinated test planning than I've seen in more traditional methodologies.

When testing as part of a sprint, the focus is on the specific features being developed. While that might include some regression testing of areas around the change, it's likely going to be shallow. Someone on the team (a test manager, a lead, or someone in the role of test planning for a release) needs to keep the big picture in view. While each tester is focused on their upcoming features, someone else needs to look across the software and identify what risks might be introduced from a wider perspective.

This doesn't mean you need reams of documentation for each release with hundreds of test cases. However, I don't know what software you're testing, so it might mean that... But for me, I think it means you simply need a light test plan for each release where each of the testers can see where their individual features fit, where someone can look for interdependent risks, and where quality criteria other than basic functionality can be evaluated more easily/clearly.

Is there a way to capture that information in one or two pages or charts? That would be ideal. We'll see if anything occurs to me. If you think of something, or already have something, please share.

In a post on productivity tools, Geekpreneur outlined what might go into a personal dashboard. I've used LifeTick for sometime now and am fairly happy with it. I use it to track some personal items, but also my writing and speaking commitments, large projects at work, and general professional housekeeping (website updates, etc...). It's helped. I drop fewer items, and I feel like I can worry less about forgetting to get something done. That frees me up to focus on the task I'm currently doing.