VS2010 Modeling; Create Lifeline from Component
From the VS2010 MSDN sequence diagram documentation…
Relationship to other diagrams
You can use UML sequence diagrams together with other diagrams in several ways.
Lifelines and types
The lifelines you draw in a sequence diagram can represent typical instances of the components or classes in your system. You can create lifelines from types, and types from lifelines, and show the types on UML class diagrams and UML component diagrams. For more information, see Classes and Lifelines.
Beside we can create lifelines from/for classes we also can create lifelines for/from components… which is actually a very interesting feature.
Context menu on a component shows the create lifeline option [not available when clicking on a part ]
After the creation of several lifelines, you can draw the interactions between the components. There isn’t functionality like the bi-directional method creation in the class-sequence diagram interaction for the component-sequence diagram. Kind of logic, a component only has interfaces.
Why would you want to do this, create sequence diagrams for components?
While the component diagram 
is a static view of your system the sequence diagram is dynamic, it visualizes the flow in your application, the sequence of actions that occur in the system. So, you could use sequence diagrams to validate your system, your component design. Take a scenario, a requirement scenario, and create a sequence of actions from in a sequence diagram 
. By doing this you create a kind of simulated behavior of the component structure, which you can check on correctness and consistency.
The scenarios used for this can be found in the use case diagrams 
, which describe the actions that take place on/in the system. Now describes a use case diagram not really a scenario, you better can use an activity diagram for that 
, which can be based on the use case diagram as a kind of use case realization. Now the interesting thing is, testers use activity diagrams to create test cases, they have specific technologies to extract the right amount and type of scenarios [see http://robkuijt.nl/index.php?entry=entry080423-135750 ], these scenarios we can use to validate our component design which actually closes the loop.
It would be even more interesting and powerful if we not only could link sequence and component diagrams but also use case and activity diagrams making notification when an activity changes and a scenario can’t be run anymore on the purposed component… hard to accomplish, but interesting, versioning would be hard…
Microsoft Test and Lab Manager and security and permission settings
Within TFS you can set permissions, what people are aloud to do within projects and with 2010 in place also within project collections and within Microsoft Test and Lab Manager.
In some situations, project settings, you want to set these permissions. For example in the TMap process template there are different rolls responsible for different tasks. The Test Manager is responsible for the Master test plan, the Test infrastructure coordinator for the test infrastructure and tools, the test coordinator for the test plans, the runs and reports and the tester for creating and execution of the tests cases.
These rolls/ groups you also can find in the TMap Process Template.
All rolls have there specific restrictions. For example a Test Infrastructure Coordinator is aloud to setup lab environments but a Tester isn’t, and a test coordinator can create a test plan but a tester isn’t. A test manager and coordinator can edit test runs results. A tester can execute test cases but a developer can’t, a developer can change sources but a tester can’t… etc, etc… A frequent ask question by test organizations is: how can a set this restrictions…. the answer is it is easy but you need to have project edit permissions :-)
On several places you can set security permissions.
In the Team Foundation Admin Console, the same settings can be set within Visual Studio menu Team—> Team Project Collections Setting
You only can set project collection and TFS specific setting at this level, not that interesting for test management.
Within Visual Studio, right mouse click on within Team Explorer or by using the Team menu.
This is a more interesting place to set permissions for the test organization. For example in this setting a test coordinator is aloud to create test runs, but can’t change configurations and environments.
This results in the fact that he must contact the test infrastructure coordinator to maintain the test infrastructure. And he got a message when he tries to change a setting in Lab Center.
A hidden security setting [I call it hidden because its hard to find in my opinion and I had to search for the projectplan permissions] is a the Area and Iteration menu item, just below the ‘Group Membership’ item.
When clicking the ‘Areas and Iteration’ menu item and click on the bottom right of the dialog what appears you can set permissions for the selected Area node or Iteration node. For the test organization important manage test plan permissions can be set.
When you set this permission so a tester isn’t aloud to manage test plans he gets nice an clean messages when he tries to save one.
But, it gets even more interesting. When a tester isn’t aloud to manage test plans he also can’t add test cases to a test plan. So, the create new test case in the plan tab of MTLM also will result in a ‘Not Aloud Message’. While the tester is aloud to create test cases he isn’t aloud to add them to a test plan, within MTLM he has to create test cases in the ‘organize’ tab –> test case manager. So a test coordinator, or some one else who has the manage test plan permission can add it to the test plan.
I have spoken with test organizations who prefer this way of restrictions also have spoken with who don’t want this. Within the TMap Process Template, you will find a light weight implementation of these permissions settings. [not yet in the download ]
To mention all the permission settings locations, right click on the source control treeview and select properties, you can set permissions for source control in that dialog [ you also have to maintain the reporting server and the SharePoint server separately]. ping me if I forgot a security settings location…
VS2010 Sharing Models and Diagrams
What is the use of models when you can’t share them. In a previous post [Copy-Past Modeling Diagrams and Modeling Elements within VSTS 2010] I already talked about the copy past capabilities of the models within team architect. Now beta 2 is out, I have to say VS 2010 Ultimate. So, it is possible to copy past elements and save them XPS-files..
But, what if you are the only one in the team with an Ultimate edition…
Lucky team-members, they still can open en view. See the [viewer] and believe me this is VS 2010 Premium.
A nice thing they can re-organize them. See the * and save it, opening this model in the ultimate edition will show the changes.
Beside the UML diagram’s also DGML and the layer diagram got this behavior.
Quick reference poster--the VSTS Rangers “scrumified“ process
from: Certified Scrum Developer course … we can finally remove the duck tape :)
The Accentient Scrum Developer course is an intensive five day experience for whole teams of developers. The course teaches teams how to turn product requirements into potentially shippable increments of software using the Scrum framework, Visual Studio 2010, and modern software engineering practices. Attendees will work in self-organizing, self-managing teams using a common instance of Visual Studio Team Foundation Server 2010 to achieve this goal.
VSTS 2010 TMap process templates infographic
Been playing a bit with the creation of infograpics, this is one I created about VSTS 2010 and TMap, what are the benifits of using them together and how are they connected.
This one isn’t finisched / approved yet (so not donwloadable in full format:-), need to change the screenshots and text in several places. But, the idea is to have them printed on a placemat with on the back contact information and to make notes.
VSTS 2010 Test Edition at the TMap® Dag 2009 [Dutch]
Theorie en praktijk wisselen elkaar af met onderwerpen als TMap NEXT®, ketentesten, security testen, Agile testen en nog veel meer actuele onderwerpen.
Tijdens de TMap® Dag 2009 wordt het nieuwe boek TPI® NEXT gelanceerd! Een compleet herziene versie van het TPI® model waarin voor het eerst de business doelen écht een ssentiële rol spelen.
WS8 -- De TMap NEXT® Proces template voor Visual Studio Team System
Gerard van der Pol, Microsoft
Visual Studio Team System ondersteunt uw procesbenadering voor software ontwikkeling door het gebruik van Proces Templates. De guidance en werkwijze kunnen hierdoor transparant worden ondersteund door de in het project gebruikte tooling. Voor de nieuwe 2010 release
van Visual Studio Team System is er een proces template in de maak rondom TMap NEXT®.
Deze sessie introduceert de TMap NEXT® proces template en laat zien welke voordelen er te verwachten zijn door deze te hanteren. Tevens zullen we laten zien op welke wijze de template aansluit op de bestaande en nieuwe test functionaliteit in Team System.
Programma [pdf]
Datum: 17 november 2009
Locatie: Hotel van der Valk, Vianen
Aanmelden: www.sogeti.nl
02: Management, preserving and organization of manual test cases within VSTS 2010.
- Part 00: Agile Testing with VSTS 2010 and TMap
- Part 01: User Stories
- [current post, removed the Agile Testing blablabla and part pre-fix]
This post belongs to the series of “Agile Testing with VSTS 2010 and TMap” although this topic has a wider scope, in used software delivery methodology you have to think about test case management.
A small introduction.
First a small introduction to give some direction on the needs of test case management.
The drawing below I made during a discussion with several TMap experts and explains how test cases are created and executed in a simple situation.
From top to bottom and left to right.
 | Teams start brainstorm over user needs, create stories and write these down on cards together with acceptance criteria.
Within VSTS 2010 this can be done in the work item type ‘user story’ [see previous post]. |
 | After prioritizing the stories, teams start the iterations by brainstorm on implementation tasks and test tasks.
Again, within VSTS 2010 this can be done in the work item type ‘user story’ [see previous post]. |
  | Next, the sources and test case are going to be created, developed. Within VSTS 2010 source files in the IDE and than added to version control. Test cases are added as work item to TFS. |
 | The source files are build, unit tested, labeled, packaged and finally deployed on a test environment where the manual test cases are executed against this deployment |
All the artifacts created by tasks are under version control, except test cases.
All the sources and corresponding automated tests like, unit tests, load tests, web tests and codedui tests are under version control. Getting the latest version of the sources also gets the latest version of these tests. But, also when using the more sophisticated capabilities of version control, like branching and merging, the tests also have this characteristics.
Manual test cases different, they are work items and aren’t under version control they have a history. Belong [often] to a user story. So, it gets interesting when making the above scenario more real live with sources and automated tests under version control with branching and merging. See drawing below…
- User stories, sources and test case are created [top left].
- [red line] A branch is made from the first version to start the development of an other version.
- User story 2 [center] is added to this branch [new/ added user needs], also sources are added to this branch and test cases are created.
- Finally version 2 is build and the test case of user story 2 are executed [bottom right].
Dotted red line; while there was a branch created from the sources, no branch was created from the test cases of user story 1 [top left], resulting in a version 2 with only partial tested functionality.
This branching scenario is very simple, there are some more complicated ones as you can read in Microsoft Team Foundation Server Branching. This 2006 MSDN story has also some nice branching and merging strategies.
The need for test case management within VSTS 2010.
This branching, merging and the decoupled characteristic of test cases is one of the reasons why we need test case management. We manually need to organize and manage our test cases in such a way that every iteration, version, service pack, hot fix and release is sufficient tested and to prove that its well tested.
As described in the paper Test Cube principle [pdf]:
A good test set (= collection of test cases) is of priceless value. During the realization of an application it is the basis for the reporting concerning test coverage and progress. In a maintenance situation it is a source of knowledge concerning the application and a source of ready-made test cases for regression tests.
In the next post we will have a look / deep dive in the capabilities of TFS 2010, MTLM [Test and Lab manager] how they fulfil the needs of test case management and in what way the TMap process template helps this process.
One part of the solution and even an agile one: automate the manual test cases as quick as possible and put them under version control. Next post more…
Enrich VSTA 2010 Use case diagram with SketchFlow Screens
A use case diagram visualizes the interaction of an external user with your system. So, you can say that in many situations [cases] that there is a need for an user interface, a screen.
Not that strange that RUP connects the user interface designer to use cases. [see image below at the bottom]
UML Type: Artifact
Something every diagram has in VSTS 2010 is the UML type ‘Artifact’. With this type we can attach physical pieces of information to or diagrams.
For example in this diagram below, I defined an artifact which points to a class file. [don’t think it very useful to associate C# class files with use cases.. but as an example]
Some nice functionality of this ‘artifact’ shapes gives us the capability to double click the shape and jumps to this file. More useful, what you also can do is point to a Word document with some additional information according to this use case diagram, double clicking will open the file in Word [or you’re preferred text editor].
Microsoft Expression Blend 3
SketchFlow is a visual tool for prototyping desktop and web applications [WPF/ Silverlight].You can download the trail here. The image below, is a prototype of an application made with SketchFlow. A bit sketching, playing with colors real designers work... :-)
Smashing Magazine had a nice overview of sketch techniques last week “35 Excellent Wireframing Resources” and I made some several weeks ago for this post Storyboard: Architectural Inspections - VSTA2010 – AppArchGuid.
Now, the interesting piece is that SketchFlow, Blend solutions have the same structure as Visual Studio solutions. So, we can open or sketch in Visual Studio. as you can see in the image below, it’s just a normal Silverlight 3.0 project. [installing Expression Studio gives VSTS the ability to open Silverlight 3 projects].
From this point it’s very easy to add the ‘XAML’ screens as an artifact link to our Use Case Diagrams.
The small challenge at this point is that double clicking on the artifact opens the XAML file of your prototype in ‘your preferred XAML viewer’ your internet browser, showing nothing. A small tweak [replace the full path property value with a batch file with one command “devenv.exe /edit filetoopen.xaml”, the /edit opens the file in the current open environment] makes it possible to open the XAML file in the currently open Visual Studio edition.
Finally the result is a Use Case Diagram with several artifacts referring to user interface screens. Which gives the user interface designer, the system specialist, the customer actually everybody who is involved in this software project an overview of the solution, which results in better understanding and the user interface designer still can work in SketchFlow.
final note: there are still a few integration problems, but I do think this is a valuable scenario….
Agile Testing with VSTS 2010 and TMap: Part 01-User stories
Previous post:
- Part 00: Agile Testing with VSTS 2010 and TMap
- … [current post]
User stories breakdown...
This post is about the work breakdown of user stories during the planning phase of an iteration.
[image from the documentation about VSTS 2010 on MSDN, this page]
During the planning phase of the project, also called iteration 0 [first blue piece], user stories are collected / brainstormed / defined /… in VSTS this information is collected in the new work item type ‘user story’ [image below].
During the planning of the iteration developers the team start to breakdown the user stories [which are selected for that iteration] in implementation tasks. Within VSTS this is done in the implementation tab. The new 2010 functionality of hierarchies between work items is used for this.
Another task also executed during this phase is the creation of test cases. Within the TMap methodology this is described in the planning phase. Where you create the test plan for that iteration, based on the risk class [see user story work item] and discussion with the customer the necessary test techniques are allocated for the user story and functional area. See the initial work items for iteration 1 in the image below, added during the unfolding of the TMap process template.
So, not only the implementation tasks needs to be determined also the test tasks needs to be allocated during the planning phase of an iteration. These test tasks are specific to testers like ‘create test cases for area …. based on the test technique <… decide based on risk and customer contact>’
List of different test techniques…
- Data combination test (DCoT)
- Data cycle test (DCyT)
- Decision table test (DTT)
- Elementary comparison test (ECT)
- Error guessing (EG)
- Error testing (ET)
- Process cycle test (PCT)
- Real life test (RLT)
- Semantic test (SEM)
- Syntactic test (SYN)
- Use case test (UCT)
So, just like the implementation tasks also the test tasks are a link type, have hierarchy with, the user story. [this is TMap process template specific]
We end up with a list of tasks for a user story, implementation tasks and test tasks… testers and developers are going to execute these tasks together in parallel, during the iteration we have: implemented sources for the user story and test cases which are ready for execution. This user story is finished when: every implementation task is fulfilled, all test cases are successful executed and … the tester hasn’t got any open tasks, so all test cases are created.
When giving the tester/ the team a place where they can record their testing tasks, testing is really going to be a first class citizen of the lifecycle. beside this benefit the connection between test activities, risk, user story and test cases gives a great opportunity for reports based on test effort, risks and implementation, later on more on this…
With this this lightweight addition to the user story work item we got a closer to several Agile Testing key characteristics, for example:
Customer involvement in writing tests. –> just like the developers, testers breakdown there work discusing it with the customer An iteration is ready when the tests succeed. –> and all tests are created..!
Agile Testing with VSTS 2010 and TMap: Part 00
Part, because I’m planning several posts around this topic.
00, because this is the ‘setting the stage’ post…
While in the Agile manifesto is written: “Individuals and interactions over processes and tools” I will cover in the coming posts information how individuals and there interactions are supported by tools and processes.
Several characteristics of agile testing [in random order].
- Lightweight implementation of tools and processes.
- Find bugs as early as possible.
- Don’t do things twice, just enough testing.
- Short feedback loops to the team.
- Customer involvement in writing tests.
- An iteration is ready when the tests succeed.
- There needs to be space for exploratory testing.
- Focus on automation.
- Repeatability is a key success factor, frequent testing.
- Pair testing.
Tool and processes support should focus on these characteristics. At this moment the tool support with VSTS 2010 for the tester is getting really mature [see this post]. So, beside the agile support for the developer like TDD, refactoring, continuous builds, guidance and many other things [see this post and image below].
Also the tester wants / needs this kind of support, beside an easy connection with all the capabilities developers have he needs the capabilities to execute his work in an agile team…
So, what practices needs to be in place for the tester within a VSTS 2010 agile project? just randomly start using the offered tools isn’t the right direction. In the coming posts I will capture some thoughts, practices and lessons learned from around the world…
As a start some useful agile testing links: