One thing I’ve found with these weekend testing sessions is that there’s always something new to learn. Last Sunday’s session was no different as Marlena introduced us to modeling — not the kind with runways or with strutting involved. Here we had a chance to try out modeling a few suggested applications using state diagrams. Our mission for the session was posted over at Marlena’s blog.
I reckon that as testers, we have this mental picture of how we expect our programs under test to behave. I guess preparing test specs is a way to translate this mental picture into something more tangible, and alternatively, capturing the system into a model does the same thing. In modeling, we get to break things down into bite-sized chunks that are less overwhelming as opposed to dealing with the system as a whole. This activity also potentially allows us to capture gaps in our thinking.
With state diagrams, we try to depict the system in terms of states and trans(actions) with more focus on the former. I came to find out that Anne-Marie tends to think more in terms of transactions than of states. I shared that I did so too and gave out an example of a textual (rather than visual) model that I previously used. Unknowingly, as Vivek had pointed out, I had created some sort of state transition table. 🙂
Takeaways from this session:
- Gliffy – a new tool! It’s a browser-based tool that uses flash for creating diagrams.
- Somewhat similar to what Anne-Marie said… as someone who also focuses on transactions over states, this exercise challenges our traditional way of thinking. It reminded me of Tim Toady (TIMTOWTDI) 🙂
- All the more interested in HWTSAM. I still have a lot of books (and comic books) lined up to read though. [Subtle hint: But if Roy buys me a digital copy, I wouldn’t mind ;)]
- Tim Toady again… aside from taking textual notes, there’s an option to go visual through the use of models.