Shmuel's Software Stuff

Annotations from day 24/06/2008 of the Sigist conference on Software Testing.

When not from a lecture focus, then from a side comment or explanation. Below you’ll find some insights I gained from today’s lecture. When not from a lecture focus, the ideas come from a side comment or explanation:

1. Map everything.
   Vipul’s “I have a dream” talk described an utopic system, in which every single bit of information is not only saved, but mapped and related to relevant bits. In this dream, every single information is mapped, and you can traverse all info and predict taks efforts and chain-reactions.
   As he said, all the technology needed for such a system exists, it just have to be done (in an efficient way).    

   As such, we can start to gain the benefits of the systems by implementing easy thing. Like, for example, Requirements mapping to code. Why is that everybody talks about mapping the test-cases to the requirements, but no one mentions the Requirement to Source Code mapping?
   Such mapping would be very good to:

   • Prevent Gold Plating (number #30 here) (and see a programmer’s rant here);
   • Show the risks (for the application) of changing a requirement (and estimate the change effort);
   • Show the risks (for the requirements) of changing the application (due to a bug fix, for example).

   A Requirement mapping effort is not complete by merely mapping test-cases.

2. 
   Combine testing components.
   If two components are codependent (as in one’s functionality affects the other’s and vice versa), most of the times it is better to think of them as one (although composed) component.
   Whenever you have to do something in one, include the other. It sounds obvious when you speak about testing tasks, like doing a regression and/or a specific test. But it can also be true when you are dividing any ownership and resources. Keep close things close.
3. 
   Combine tests.
   Combine tests into composed scenarios. Run a number of tests – but do them sequencially as part of of a use-case. Instead of testing the find feature, do a combo hit: Open a document, find a text, replace it, save it again under the same name – 4 tests in 1!
   You still got to do all the tests, but the scenario combinations increase incidental complexity ,which usually causes smarter bugs.
4. 
   Software security does not end in the software.
   Business are made of software and data. Be it a collection of different software by different company, or one single solution by one company, the business workflow has a lot of stops and transitions. It is not enough to have a software adequately tested for security, if the workflow (wich is made of people) allows security problems. Authentication, authorization, configuration and more are problems that need to be dealt on the workflow level. This business process needs to be built with a security mindset since the beginning. As Vipul said a day before: “Security is not supposed to be tested, it is supposed to be tested for. And the same is true for performance and usability”.
5. 
   Models always lie.
   I am afraid of models. Since I discovered that many problems with requirements come from people thinking this representation is the real thing (instead of just a reflecting image with imperfections), I am afraid of models. In todays’ Test-Cases from UML lecture by Ofer Prat, he gave a wonderful example about modeling:
   London’s Underground was always mapped in it’s geographical form, it was a model drawn as close to reality as possible. Such a model was complex and almost unusable. Over the time, it evolved in a simpler and easy to follow model, but by then it was not accurate anymore – see this page for a graphical history.  

   So, models (and requirements) are meant to be straightforward directions. As such, they may lack from the accuracy and/or truth that reality presents.  If software is behaving in a bad way, and this bad way fits the requirements, it is time to re-tune the model.

More to come tomorrow! 🙂