I like using sequence and activity diagrams to generate test ideas. When looking at a sequence and activity diagrams, ask yourself what would happen in the system if a specific line didn't happen or didn't happen correctly. For example, if you look at the following example from Donald Bell's article on UML Sequence Diagrams:



If I were to use this to create test cases, I'd ask questions like:

• What happens if the amount doesn't come back?


• What happens if the amount that comes back is in an invalid or unexpected format?


• What happens if the amount that comes back is corrupted, very large, or if the connection is interrupted?


• (similar questions for balance)


• If the balance is less than the amount, what happens if I note the returned check without adding the insufficient fund fee? Can I do that?


• What if, while noting the returned check, I use an invalid check number, use a check that's already been noted previously, or don't pass a check number?


• (etc...)

You get the idea. When generating the test ideas, just list them out as you think of them. If you have a sequence or activity diagram of any complexity, you'll get a long list. Afterward, you can work with other project team members to shrink the list down into the scenarios you feel will provide the most value to the project.

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.

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.

benerator supports load and performance testing by providing a framework for generating high-volume test data. From the tool's website, out of the box benerator supports database systems, XML, XML Schema, CSV, Flat Files and Excel. Domain packages provide reusable generators for creating domain-specific data as names and addresses internationalizable in language and region (via nestable datasets).



A commercial version is available in addition to the free GPL version.

I recently started (another) new project. I find that whenever I start a new project, there are a few places I begin digging in:

• finding whatever documentation I can (requirements, diagrams, contracts, project plans, emails, meeting notes, etc...) - it's a mad dash to get anything that's been written down about the project


• finding (or making) a list of who's doing what - many times new projects come with new faces and names, keeping everyone straight can take some effort early on


• starting a new notebook or electronic notes file - I write down my open questions, my assumptions, and my ideas around testing/design/time-lines

When a new project gets dumped on your lap, where do you start first?