Archive for December, 2013

“Felfelfel” is a new testing book that is filled with interesting articles written by a bunch of known testing peoples in Sweden. It covers a wide range of topics within test. Why not start the new year with some inspiring reading!?

The book is only available in Swedish and is made by TestZonen.

To order the book visit http://www.felfelfel.se/

I attended SAST Öresund Q4 earlier this week and I got to listen to two good presentations that completed each other really well. First out was Johan Hoberg. He talked about risk based testing out of a technical perspective. He talked about selecting test cases based on changes in the code, how to choose what configurations to test when you have thousands of different configuration combinations and about complexity and complicated code. He also had some nice (but not easy) ideas of how to structure everything to get the support you need to do a quick and easy scope selection.

The second speaker, Mårten Mattsson, had another perspective. He talked about risk based testing based on requirements. All requirements are analyzed by different people. Probability and consequence are weighted and will result in a level of test focus. In this case your risk analyze will be more out of a users perspective.

I think it’s really important to cover both views but I also have a third perspective that might be more risk based TESTING than the two examples above that are more risk based TESTS. In one of my projects the whole project made a risk analyze. It was risks like “Team X lack of resources so there is a risk they will be delayed”, “The new envelops from the printing firm might be delayed”, “We might have missed some customer engagements” etc. What I did was to go through this list and tried to figure out whether there was something me and my test team could do to reduce the risk. Most of the time the risk was far from our area and nothing we could do. But sometimes there were things we could do. For example risks like the one above regarding customers’ engagements were easy… test more. But this is still risk based tests. An example of risk based testing is when a development team was delayed we could help them by testing their stuff early, be extra careful when filing bugs (add logs, videos etc) but also plan for late tests in that area. This risk doesn’t only affect what tests to run but also when to test.

If your project is doing a risk analyze on this level, make sure you use it! My team found some important issues early by doing this. You will help the project on a new level and you will focus on things that they think is important and risky.