4
« on: March 19, 2009, 03:12:08 am »
Hi!
I am working in a group of system developers and system testers that have just started to try to use an analysis diagram as a communication link between a developer and a tester. I would like to have comments and suggestions regarding this, because we are not at all sure that this is the best way to do it.
We connect an analysis diagram to the use case that is to be implemented, which means that this diagram resides in the Primary Use Cases package.
When drawing the diagram, we are trying to capture the developer's idea of how the use case is going to be implemented. We want to visualize required input, expected output and also all possible error states. Actions that may trigger the error states should also be included somehow.
Our intention is to make the diagram possible to read directly as a test plan for the tester, which means that the tester should be comfortable with looking at it as a replacement for a document saying "do this, then do this, then the system should respond like this". The testers should somehow be able to mark the diagram as "tested", just like in a test report written in words.
Unfortunately, our testers are not at all comfortable with this replacement yet, and we feel that we have a long way to go before the diagram could take the form we want it to have.
Do you have any comments on this? Is this possible at all? Is it good or bad to try to use an analysis diagram? I know that sequence diagrams should be used to describe details of a use case, but how could you read a sequence diagram as a test plan? How do you capture error states, for instance.
You may have noticed that I am not an UML or a process expert. I guess that we are quite a few in this world that try to use EA without learning the process properly first. I just hope we will get better along the way...
Thank you very much in advance, everyone!
Best regards,
Fredrik