Yesterday I was looking at a project plan for testing ideas when it occurred to me to share this tip with other testers. I use project plans as a tester which is different than how I use project plans when I’m building, contributing or reviewing estimates.
I’m not sure if other testers do this …
I look through project plans to note any bits of code that are called out distinctly. If a piece of code is large enough to be a line item on a plan, it’s large enough to be complex which increases the likelihood of bugs. I suppose I could do a more sophisticated method of complexity analysis but scanning project plans tells me other things. Here’s a couple more …
I look for what developers are coding what components. If I work with a team long enough, I start to know the types of defects individual developers tend to make. (And yes at an appropriate setting and time, I share this information with developers to help get issues addressed upstream.)
I look where different developers might be coding similar items and look to find the gaps between how they code. For example if one developer is coding search and another is coding reports, will they build the queries the same? Would a search in the application and a report using the same criteria give me the same result set? I have an increased chance of a bug if two different people code those two areas or other areas that should be compatible.
And I note the chunks of code built later in the cycle because in my experience, the end of the project is nearly always crammed for time despite the type of SDLC the project is using and code built fast is more likely to be flawed.
Anywhere I can gain an idea or insight is worth scrounging through. This isn’t a huge tip or a large effort to take on but a 10-15 minute read usually gives me something. I’ve never articulated this thought-path anywhere else but I’ve been doing this for years on all sorts of projects. And I wouldn’t keep doing something unless it brought me some value.