Services provided by Brian Marick

Consulting

As a consultant, I help companies better understand risks, alternatives, and consequences. That leads to better decisions. I usually work with test teams and test managers who want to be more effective at testing. I also consult with development managers and product architects.

Here are some things I can do:

• Help the testing team design a test automation architecture.

• Help individual testers with task planning and mentor them in test design techniques.

• Help create a strategy for using code coverage effectively.

• Work with the system architect to produce a testable product architecture.

• Work with the whole project to create a project testing plan that tailors testing activities to the project schedule.

• Show developers how to put fewer bugs in the source base.

Here is why I believe I am worth your consideration:

• I believe that testing is as much about risk reduction as it is about finding bugs. (For more, see this essay and my paper "Classic Testing Mistakes".) If, after all the work the testing team does, people still feel that somehow testers aren't finding the right bugs, I can help.

• Many consultants who talk about software development haven't actually done any for a decade or more. They view everything through the lens of ancient experience. Make no mistake: much has stayed the same. But much has changed. Because I dread becoming one of those consultants, I spend time on contract work in real-world environments.

• One of my specialties is teaching developers how to test their own code. Not many testing consultants do that, and still fewer of them have recent development experience. When working with developers, that's important. Developers are intolerant of outsiders telling them how to do their job.

• I am as concerned with efficiency as with effectiveness. It is not enough to be able to find more bugs. You must find more bugs per unit time, and you must do the best job you can in the time allowed. Even when the time allowed is nowhere near what you really need. Even when the time you thought you had shrinks drastically halfway through the project.

• I am careful to stay aware of the things I don't know. For example, I know that inspections are important. I do not have the personal experience to teach inspections well, or even to talk in great detail about how to do them right. I have, however, watched closely as organizations failed to adopt them. I can speak usefully about why that happened and about what not to do.

Training

I provide one off-the-shelf course, Developer Testing Techniques. (Click here for a PDF brochure.) I also develop custom courses to meet specific needs.

Developer Testing Techniques is one of the few testing courses targeted to developers. Most such courses seem to be repackaged general-purpose testing courses. I believe my course to be the most pragmatic one, because I teach it from the point of view of a developer.

My off-the-shelf and custom courses have these features:

• They emphasize gradual adoption of techniques, rather than assuming people will immediately put everything into practice.

• They are particularly strong on test design. Since I limit them to two days, they are correspondingly weak on some organizational issues, such as the project lifecycle (but see my paper "New Models for Test Development", which I can present in a workshop format). To fill in my gaps, I recommend courses from the consultants on my Links page.

• I supplement courses with consulting. I find that nothing solidifies lessons of test design like sitting down with someone and designing some tests for the code they're working on.

Contract testing and programming

As a contractor, I stop talking about testing and sit down to actually do it. I deliberately vary the type of contract work I do. In one job, I might do purely manual product-level testing through the user interface ("black box testing"). In another, I might pair up with a programmer and write test programs to exercise some internal module ("white box testing"). In yet another, I might add code to the product that makes the black box tester's job easier ("testability code"). I lower my fees if a contract gives me the opportunity to learn new things.

Here is why I believe I am worth your consideration:

• As a consultant, a regular speaker at conferences like STAR and Quality Week, and an attendee at workshops like LAWST, I am forced to both learn new things and also discover solutions to new problems. These get applied to my contracting work. I find that consulting and contracting form a virtuous feedback loop.

• You get a certain amount of mentoring and consulting along with the contracting. I am particularly fond of sitting down with novice testers and tackling a testing task together. (No extra charge!)

Resume

You can find my resume here.