Research in Progress-Model Based Test Planning and UML
I am working on learning UML right now. I naturally speak in models in my head and have even devised a "roadmap" way to express how I envision the functionality layout in my head. The issue I find is other people can't understand it. For that reason, I am working on gaining a deeper understanding of UML so that I can experiment in model based test planning. I mean applying workflow testing and exploratory testing based on models. I am less interested in the uses for creating automation based on the models. I see my role in creatively coming up with a better way to plan and communicate using models, a better way to reduce existing test cases and create new ones and communicate risk and coverage using the overall picture in models rather than words and statistics. I've done some research to see what exists, but it seems to me that this area is largely unexplored in terms of large scale software projects like the Creative Suite.
How do you currently use models for planning testing? Do you use them to plan when things are testable? How about just to organize your thoughts on risk and importance and communicate with other people?
Can a set of models be used with any sort of consistent results as an overall map to organize collaborative testing? I'd like to try.
I think my team must at this point roll their eyes every single time I want to try another cooky idea to improve our collaborative testing documentation. I have really only a few traits that make me a good tester. Above average curiosity, above average enthusiasm, and a passion for ranting and seeing things improve. Basically, I'm meddlesome and problematic. I think that my drive to always improve is what makes me useful in quality, but can be an absolute pain in terms of romance.
How do you currently use models for planning testing? Do you use them to plan when things are testable? How about just to organize your thoughts on risk and importance and communicate with other people?
Can a set of models be used with any sort of consistent results as an overall map to organize collaborative testing? I'd like to try.
I think my team must at this point roll their eyes every single time I want to try another cooky idea to improve our collaborative testing documentation. I have really only a few traits that make me a good tester. Above average curiosity, above average enthusiasm, and a passion for ranting and seeing things improve. Basically, I'm meddlesome and problematic. I think that my drive to always improve is what makes me useful in quality, but can be an absolute pain in terms of romance.


Comments