How to keep you fingers on the keyboard within VSTS 2010 Architecture Edition
Keyboard junkies have a hard time with all that dragging and dropping of shapes and connectors around within VSTS 2010. So here are some tips for these junkies how to keep you fingers on the keyboard.
New default DSL Tools behavior…
Adding shapes to the design surface allows you to directly start typing, for example after adding a class shape to the design surface lets you start typing the class name. Hitting 'Enter’ will confirm the value and F2 lets you edit it again.
More interesting, in the compartments of the class shape hitting Enter twice adds an attribute or operation. So, type a name for an attribute, hit Enter to confirm the value and hit Enter again for adding a new attribute.
Very simple and also very quick for the creation of classes.
Fast diagram editing with shortcuts…
With the default behavior you still have to drag and drop class shapes on the design surface. To eliminated this piece of mouse handling you can create your own keyboard shortcuts. Cameron pointed me to this environment settings in Options dialog screen. The architecture team has created a very nice an clean overview of all the actions you can execute in this dialog. So, adding your own shortcut keys is very easy. Below I added the shortcut key “Alt-C” in the context of the Logical Class Diagram for adding Class shapes to my design surface.
I also added the shortcut keys for adding Attributes and operations, just because setting the focus to the compartments isn’t that easy with shortcuts…
And when this is still to hard for you, you can buy a drawing tablet.. with a nice tablet overlay.
and you will look as happy as this guy…
although it just looks like he isn’t that comfortable with it…
SDL ‘Merged’ Process Template White Paper.
The SDL group just released a paper which describes the steps [seven easy steps] you need to take to merge the SDL specific process items with your existing process template.
Two New Security Tools for your SDL tool belt (Bonus: a “7-easy-steps” whitepaper)
Very nice work… Hopeful we get in the future the possibilities to merge process templates in a less manual way, but this works.
The steps described in this paper are based on unfold process template so you have to take this steps for every new project you create. An other way to merge template is by providing the XML and manually merge it with your existing template. A possibility described in this post “VSTS 2010 TMap Process Template 1,2 and 3”.
03: Agile Testing Business Whitepaper.
My colleague's in Ireland wrote a great paper about Agile Testing practices…
‘ At its heart, agile is all about quality and focusing on the customer. Testing therefore has a significant role to play within an agile development environment and can actually strengthen the output of the process.’
Part 00: Agile Testing with VSTS 2010 and TMap Part 01: User Stories 02: Management, preserving and organization of manual test cases within VSTS 2010. 03: … this post 04: … [probably] 2.1 test case management practices
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..!