They hire you to help them with their testing. From the initial analysis gathered in a meeting with them, you recommend a risk-based approach to testing. The major reason for selecting this approach is that they have not budgeted enough time for the testing efforts. One guesses they did not budget enough time partly because they are new to software development and software testing specifically. So, the project is nearly complete with just a couple of months to go, and they still have not started testing. Conclusion: a risk-based approach is our best choice.

Let’s expand the picture to say the solution is huge: three different vendors are bringing in their software packages and they have to integrate so that total solution provides a seamless communication of both vital and non-vital information, as well as some very technical information, necessary to propel this  business into the future growth it desires.

In other words, you come in and see Goliath and know that a risk-based approach will best address this very challenging task: provide a measure of testing and an understanding of the software quality in an incredibly small time frame, considering the size of the solution.

More detailed reasoning for choosing risk-based testing

From our experience, risk-based testing is one of the best methods of documenting a testing approach while cutting costs and staying  extremely agile, which is good for a company just beginning to create testing processes and practices. It is less expensive and it has a faster cycle.  Also, we have found risk-based testing a great way to start if you want higher confidence that you are testing the right things at the right time.

We use the client’s  SMEs (subject matter experts) to define risk areas and then rate them so that we have information to drive the plan. Since you know which areas are critical, you start with the highest risk areas and work your way through the others. As part of this process, you want the project management team to create guidelines for success and completion. For example, the cycles of testing will be complete when you have tested all the high-risk areas three times; the medium-risk areas twice; and have done some analysis on the low-risk areas, based on the testing of the other two areas.

Here again, the time constraints are the driving factor (as well as some other context-driven situations, e.g. lack of written requirements). So we recommended and went with SBTM – Session Based Testing Methodology. This framework allows for a maximum “hands on” testing and a minimum of documentation and management of the process. Based on limited time, the need to maximize testing efforts and minimize documentation and other administrative efforts, we decided this was our best framework for testing.

We often hear “the devil is in the details,” but for us, in this case, the devil was getting to the details, which we just described as learning how to help the company move into testing and do it with the constraints that were given. Our solution was risk-based testing with SBTM.

As for the details, we worked within the time frame allotted and accomplished what we needed to, thanks to our ability to pick the solution that best fit our context. We did lots of testing; covered the areas that were expected to cover; and delivered the needed work and documentation.

The biggest lesson we learned from implementing risk-based testing using a Session Based Testing framework was “never stop asking questions.”

This is a story that does not end here, but continues every day. We like stories.

Some Useful Links
James Bach – http://www.satisfice.com/
Michael Bolton – http://www.developsense.com/
Mike Kelly – http://michaeldkelly.com/

SOUND OFF: Do you have a testing story to share? We’d love to hear it!

There are many questions we may ask ourselves. For example, with today’s fast-paced environment and global connections, we are using email, mobile phones, Skype, and many other forms of communication. So why should we build a face-to-face community? Others may query: How will we do this? And there are many other questions also, but it is the how camp that I too am curious about presently.

I believe from my many years of working on teams and using technology that many of us enjoy and even desire the need for direct human contact. I am one. By actually being in the same room with a group of people, we develop and grow closer relationships. Often the masks we wear in our corporate lives can be removed as we develop into a community of like-minded, focused people. As the comfort levels grow, we can all help each other work on the ever-changing world of technology and software testing (including new landscapes for exploration, e.g., mobile testing).  Other ancillary reasons for building face-to-face relationships are opportunities to actually create friendships and alliances that are able to go beyond our testing interests and challenges. All of these points address a part of the why question.

Which brings us back to the how question? One factor of the how is that we have to establish a group. We do currently have a small group, and I am thankful for a couple of people who have brought this organization together here in Cincinnati—kudos to Brett Leonard and Joe Harter in starting the Software Testers of Cincinnati (SToC).

Another aspect of how is the location, and we have another thank you to the Max Train team and facility in Mason (Cincinnati, OH).

And there is the time/schedule factor. Currently, we meet the last Tuesday of the month (Note: breaking for both June and July).

And an ongoing challenge for the how is creating ideas, programs, speakers, and more.

What else do we need to make this happen? Help. I am asking for help in this blog. Please contact me or just post a remark. It is summer in the Tri-State (Greater Cincinnati business area/region) and traditionally a time for family vacations and lots of other family and personal diversions. So again I mention: following this tradition, our community, SToC, will be taking a small break (June and July). While we have this break, I am asking for help from the global community as well as the local community in building our community of testers.

SOUND OFF: Can you help? Any ideas you’d like to share?