Around six weeks ago I wrote about the RRápido methodology. I had presented RRápido internally (to the Torrenegra Labs) two weeks prior. On the version of RRápido I presented, we had documented that the developer was in charge of writing the test case matrix. The test case matrix is a type of traceability matrix that we create for each use case. The test case matrix determines which test cases (columns) will be testing which triggers and extensions (rows). On that meeting German made a suggestion. “I think the product developer should write, or at least suggest, how the test case matrix should look like for each use case”, he said. He argued that by doing that, the developer would be less anxious and, thus, more productive. I took note of the suggestion, applied to the RRápido methodology, and then released RRápido to the public.
Only last week, though, is that I, as product developer, got to experience this tip first hand. All I can say is that it works great! On top of German’s prediction, it also offers an additional advantage: It is a wonderful reality check. When the product developer creates the test case matrices, it is forced to think how something should be tested in the browser. In some cases, as it happened to me last week, it will drive the product developer to reconsider how some of the triggers and extensions were born. Creating a test case matrix is very quick (five to ten minutes) and it can save hours and days of work to the developers. Why? Because they would have been the ones finding the errors while coding, or, even worst, when recording the Selenium test cases. Changing the documentation at this stage is doable, but, most of the times, expensive in terms of money and time.
Thank you German for the idea!
Alexander is LetMeGo's co-founder and jefe. Here is his LetMeGo 