To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
Since I mostly do exploratory testing, for me test case preparation is mostly what I would consider setup work. It's the work that prepares me to design and execute my tests. Even if I wasn't doing exploratory testing, these would all still apply; but likely I'd also have others related to test design and documentation.
My typical preparation work for a project might include:
- Developing a working knowledge of the product, business and changes being made.
- Developing an understanding of the project goals, my testing goals, timelines, methodology, and current team and communication structures.
- Developing an understanding for what risks the project team is most sensitive to, and what types of issues they'd like to see reported first.
- Identifying potential test oracles (requirements, products or tools, etc.) and acquiring or building them.
- Finding, building and/or staging the test data and tools I think I'll need to support my testing.
- General product environment setup and configuration.
Specific to Web-based applications, I'd still have the same activities, but I'd likely focus them a bit more around topics such as understanding how much of my testing should focus on performance, security, scalability or internationalization versus functional testing. For example, I might look at different aspects of those quality criteria from both the product and business perspectives to better understand and balance concerns. Or I might try to get more detail on target technology and configurations so I can better understand the technical risks associated with our implementation choices. For example, I might research common bugs on the chosen platform or technology.
From a process perspective, not much changes when I look at Web applications. The tools and specific techniques might change when you get to design and execution, but I find that most of the differences come from which quality criteria are most important and what technologies are selected.
Based on those preparation steps, when I estimate I look at some of the different activities within each of those steps and try to balance the work I want to do with how much time I have available for preparation. That means that some activities get time-boxed (like my research activities), while others get bottom-up estimates based on the work (like generating test data for load testing). When I'm doing bottom-up estimates, I like to focus those estimates on work products.
For example, if I were estimating how long it would take me to develop my understanding of what risks the project team would like me to focus my testing on, I'd take an approach I learned from Rob Sabourin. Starting with a series of brainstorming sessions, based on my understanding of what we're doing with the project, I'd create a large list of risks and possible issues and/or tests. Then through a series of interviews of both technical and business stakeholders, I'd prioritize those risks and use that to inform my initial test plan for what I'd test first.
This process gives me a risk list and test plan as work products. I can then work backwards from those to estimate the activities and time it might take to produce those artifacts. For example:
- To generate the initial risk list, I might need three brainstorming sessions, each one hour long.
- To clean up those brainstorm results and put them into a document I can manage, I might add another two hours.
- Than to refine that list, I might set up review meetings with various people who are close to the technology or business functions. Here I'm focused on the quality and accuracy of the ideas -- not necessarily priority. That might take a couple more meetings, and a couple more hours.
- Then I have interviews, which I can estimate based on an hour per interview.
- Then I have to document my final findings in my test plan, which might take me three or four hours.
That basic process gets repeated for each area of preparation for my testing. I identify the work products I need to create, and work backwards to identify and estimate the activities that get me those work products.
|
