Into ALM, Agile, .NET, Software QA, team management
After using Posterous for a while now, I decided to move all my articles to a personal domain. I also made the switch to Wordpress..
My new blog can be found on http://www.alexandervanwynsberghe.be/ and new posts will be added there. You can update your RSS readers if you want.
Thanks!
Alexander
In a previous article, I walked through the process of installing and using Team Explorer Everywhere on an Eclipse environment. That way, you can use TFS for your Java development. In this article, I will cover the process of how you can use the Team Foundation Build Automation to automate your Java builds using Ant. I'll guide you through all the necessary steps and give you some personal experiences.
First of all, you need to have Team Explorer Everywhere installed (more about that in my previous post). If you have this, you're ready to go.
Getting started with Java and Ant
To start, let me explain you what Ant is and how you can use it.
Apache Ant is a software tool for automating software build processes. It is similar to Make but is implemented using the Java language, requires the Java platform, and is best suited to building Java projects. Ant stands for 'Another neat tool' and was released at first in 2000.
The Ant build definitions are declared in a build.xml file. The root node of a build.xml file is 'project', where you define the name of the project and the default 'target'. This target will be executed when you build your project. The child-nodes of a project are those 'target' definitions. You can define as many targets as you want. For example 'clean', 'compile', 'jar',.. Each target can have its dependencies. You can define that the 'jar' target depends on the 'clean' and 'compile' target. That way, you have a sequence of executing. Let me give you a really basic example:
<?xml version="1.0"?>
<project name="Project1" default="compile">
<target name="clean" description="remove intermediate files">
<delete dir="classes"/>
</target>
<target name="compile" description="compile the Java source code">
<javac srcdir="." destdir="output"/>
</target>
<target name="jar" depends="compile" description="create a Jar file">
<jar destfile="project.jar"/>
</target>
</project>When you use Eclipse, you can use the Ant window to visualize the Targets of your build.xml file. (Link your build.xml file using the 'add build files' button) Using this window, you can also execute a specific Target by double-clicking on it. Be sure that you do a check-in of your build.xml file!
Now you have Ant up and running, we can define our TFS build definition. This build definition will take care of the build process on our TFS build controller. If you want to learn more about build controllers and build agents on TFS, take a look at this article.
1. Open the Team Foundation Server Explorer in Eclipse (using the Team Foundation Server Explorer perspective). Select Builds node, right click and select 'New Build Definition'
2. In the new window, the first thing you have to do is provide a build definition name and a description
3. The next step is to define the build trigger. Choose the option that suits you the best. In my case, I selected a Continuous Integration Build.
4. The following step is the definition of your working folders. This is the mapping that the build server will use. (If you defined a custom workspace mapping on your local machine, you can also copy this using the 'Copy Existing Workspace' button.
5. Select your build controller and the place where to output your files. Note that even on Linux, if you use a network location, use '\\location' and not 'smb://' (which you would normally use on a linux machine to access a Windows share). That's because the build-controller is running on a windows machine, and this controller uses the network path you define there.
6. On the 'project file' section, you can define which 'build' you want to use. Click on the 'Create' button to start a new wizard. The first step in this wizard is to select which build file you currently have. In our case this is an Ant build file. Select this an click next.
7. The next step is to select your build.xml file, which is already in your project. Click finish to close this wizard.
8. As you can see now, the wizard tells you that there was a MSBuild project file found. That file was automatically created by the previous wizard. Note that this file is located in a folder called 'TeamBuildTypes'. If you want to understand what's in that TFSBuild.proj file, take a look at this document.
8. The last step is to define your Retention policy. There you can select some numbers of how many files are kept when a build succeeds, fails,..
9. Click Ok to create your Build Definition. You Should now see your new build definition in the list.
Build server changes
To summarize: We have a Java project, an Ant build.xml, a TFS build definition based on the Ant build file. The next step is to prepare our TFS Build server so it will be able to build Java projects based on Ant/Maven2. For that, you will need the Team Foundation Server Build Extensions Power Tools. They can be download here. This extensions provide the ability to execute Ant or Maven 2 builds from Team Foundation Server and publish the results of the build along with any associated JUnit test results back to TFS.
After you have installed this on your build server, be sure that you have the correct JDK and Apache Ant installed. Next thing you may not forget is set the correct environment variables to your (build) system. I spend quite a while looking for the correct one, so here they are:
Add a system variable 'ANT_HOME' with value 'C:\Program Files\WinAnt' (or where Ant is installed). Next add a system variable 'JAVA_HOME' with value 'C:\Program Files\Java\jdk1.6.0_25' (or again where your jdk is installed). The last step is to edit your system variable called 'Path'. At the end of this value (it should already contain a bunch of other settings) you add ';%JAVA_HOME%\bin;%ANT_HOME%\bin'.
Now you're ready to go. The build server can now execute Ant builds.
Ant build usage with TFS
The nice thing about using Ant with TFS is that the TFS build will provide some extra parameters that can be used in your build. For example you have BinariesRoot, BuildDefinitionName, BuildDirectory,... You can use this parameters in your Ant build definition.
I'll combine the previous explanation with the fact that you also have 'conditional' parameters in your Ant build file. What I mean is that you can declare variables, depending on the fact that the variable is or isn't defined. For example, if you run your Ant build inside your Eclipse, you have no 'BinariesRoot' variable available. That's because this is provided, additionally, by our TFS build script. What we can do is the following:
<condition property="dir.output" value="${BinariesRoot}">
<isset property="BinariesRoot" />
</condition>
<property name="dir.output" value="${basedir}/output" />
So if the 'BinariesRoot' variable exists, then use it, otherwise use the 'basedir' instead. That way, you can create your Ant build so that it does run local, but also on the build server.
Run your build
Now you have all the parts completed, it's time to execute your build. Using your Team Explorer in Eclipse, right-click on your build definition and click 'Queue new build' (or do a code check-in if you defined a CI build). Now you should see the build running in the 'Build Explorer Window'. Double-click on the build to see the results. You also have a log, containing the output of the Ant-build. If you go to the drop folder, you should see your output files.
Now it's up to you to change your Ant build file, and play with some targets. In a next post, I will explain how you can define JUnit-tests in your Java application, and also link the results to your TFS build, and even watch the results in Visual Studio.
Thanks for reading!
Today, I want to talk a little bit more about what exploratory testing is, and especially how you can do exploratory testing with the new Microsoft Test Manager 11.
Last month, I followed an ISTQB training where I got some lessons about Fundamentals of testing, Test design techniques and Test management. One part of the course was about exploratory testing, why use it, and mostly why not use it. I didn't really agree about the fact that they discourage the use of exploratory testing, and definitely not agree if you use MTM11 to do exploratory testing. I'll show you why.
What is exploratory testing?
According to Wikipedia:
Exploratory testing seeks to find out how the software actually works, and to ask questions about how it will handle difficult and easy cases. The quality of the testing is dependent on the tester's skill of inventing test cases and finding defects. The more the tester knows about the product and different test methods, the better the testing will be.
Exploratory testing is all about simultaneous learning, test design and test execution. It's a powerful and a fun approach to testing as you don't have to follow a formal test plan, and you can use the system like an end customer should do. Like Anu Bharadwaj said in her ALM summit session, exploratory testing is about focusing on customer and business value. You have to ask yourself the questions: Does the software do what I want it to do? Does it act like it has to act? Those are the things a customer will also look at. They are not interested in how many bugs are fixed, which scripts you use,..
Microsoft Test Manager 11
Microsoft Test Manager 11 is the new to be released version in the ALM suite of Microsoft. MTM 11 will allow you to run exploratory tests on your software. The nice thing is that exploratory test sessions might be associated with user stories. That way, you can verify that the user story behaves correctly. It also provides an easy way to create manual test cases based on the action steps during your ET session. If you create a manual test based on the action steps that are recorded, the manual test case is automatically associated with your user story and all bugs that you file during this session will also be automatically linked to that story. The bug will also have some rich diagnostics attached.
Starting an exploratory test session
In this example, let's start with creating new test plan in MTM
Executing an exploratory test
Create test case from your exploratory test
In MTM11, there is a possibility to file a bug or create a test case while you are running your exploratory test.
Now you got an overview of how you can define and run exploratory tests with MTM11. In a next post, I will talk a little bit more about session based test management and testing tours. Thanks for reading!
Note: I also found a little issue when using MTM11 in combination with tfspreview. When you add some screenshots to your test, you see a 'missing image' error when you look at the test afterwards. More info here
A while ago, I made a blog post about how to access TFS2010 with Eclipse. Now the cool thing is that there is also a new version of Team Explorer Everywhere 11 (TEE11) to be used with Visual Studio Team Foundation Server 11 Developer Preview, so this also includes the hosted TFS version (tfspreview.com, where I still have one invite left).
As I have an account on the hosted TFS preview, I definitely wanted to connect my brand new Ubuntu 11.10 distro with my brand new Eclipse 3.7 IDE. I will not explain each step of the installation process, as they are described in my previous post.
You can get the TEE11 download here, or using your TFS preview (Administration -> 3. Download software). You will need the 'TFSEclipsePlugin-UpdateSiteArchive-11.0.0-CTP1.zip' file.
Once the bits are downloaded, install the Eclipse plugin (Help -> Install New Software). After the plugin is installed, go to Window -> Show View -> Other -> Team Explorer and select the TFS specific windows you need.
The next thing you want to do off course is connect to your shiny hosted TFS. In the Team Explorer, click on plus-sign and on the server window, click on the add button. In this window, add the URL of you TFS server in the correct format. If you want to connect to your hosted TFS, enter 'https://yourname.tfspreview.com'. This will automatically disable the connection details window. Next step, click on OK.
If you're using Ubuntu 11.10, you will get a nice error window.. Auch..?
I was not really sure what the problem was. Something about 'XULRunner', but I never heard about that before. So I posted an issue on the MSDN forum. Because I really wanted to know what was wrong and I started a quick wiki-search:
XULRunner is a runtime environment developed by the Mozilla Foundation to provide a common back-end for XUL-based applications. It replaced the Gecko Runtime Environment, a stalled project with a similar purpose. All XUL-based applications like Mozilla Firefox, Mozilla Thunderbird, Songbird, ...run on XULRunner.
So from what I understand is that XULRunner is a runtime environment where you can render things, like Firefox uses it to render webpages. The error I had was indeed when the plugin wants to open a windows to show the Windows Live login screen. Ok, but how to solve my problem, as Ubuntu 11.10 has XULRunner by default?
After some google work, I found out that TEE11 requires xulrunner-1.9.2, which is not installed anymore on Ubunutu 11.10. I will tell you how to install this, as it's not just "apt-get install xulrunner-1.9.2", which will not work by default.
The first thing you have to do is adding a line to your /etc/apt/sources.list
Go to your terminal, and enter:
sudo gedit /etc/apt/sources.list
After entering your password, it will open the gedit texteditor. Just add the following line to the end of the file:
deb http://security.ubuntu.com/ubuntu lucid-security main
This line will allow you to apt-get on the security repositories of Ubuntu. Now you can open your terminal, and simply type:
apt-get install xulrunner-1.9.2
This will install the package on your machine. If this doesn't work, you can also download the package as .deb file and install it by double clicking on the package, and follow the steps of the Ubuntu software center.
All right, mission accomplished! Now you can do whatever you want with TEE11 like source control, workitems, builds,..
Just wanted to say thanks to Shaw Terwilliger who gave me the following explanation about the issue:
I'm glad you figured this out quickly, I was just about to post the same work around. We finished our TEE 11 CTP before Ubuntu 11.10 was released, and we depend on the Mozilla browser via xulrunner for this control. Shortly after Ubuntu 11.10 was released, xulrunner wasn't available in the repositories but the xulrunner-1.9.2 from 11.04 installed cleanly and works.
We're investigating Ubuntu's plans to continue shipping xulrunner in future releases, and may make some changes in our next release to work with the Webkit browser (the default in Eclipse 3.7 on Linux/GTK).
As everyone knows, the TFS 2010 Version Control System (VCS) is Centralized. That's a good thing, but if you ever used a Distributed Version Control System (like Git) you might encounter some shortcomings and feel a little bit frustrated about some annoying things.
The biggest advantages to use DVCS (for me) are the advanced merging possibilities and the offline repo access. When I'm working at home, I can see the full history of the project, every single checkin, without starting up my VPN connection to work and can work like I were at work: checkin, checkout, branch, merge,..
Note that with TFS11, there will be local workspaces (as described in Brian Harry's blogpost). In local workspaces, TFS assumes that your client is master and TFS needs to understand the changes that you make there.
So.. will TFS11 be a DVCS then? No, as Brian Keller mentioned:
I’m certain that about this time, I bunch of people are asking “but, did you implement DVCS”. The answer is no, not yet. You still can’t checkin while you are offline. And you can’t do history or branch merges, etc. Certain operations do still require you to be online. You won’t get big long hangs – but rather nice error messages that tell you you need to be online. DVCS is definitely in our future and this is a step in that direction but there’s another step yet to take.
Ok, back to the essentials of this post: What if you want to use the power a DVCS system like Git and combine it with source control on TFS? You can, using GIT-TFS. This is a Git extension acting as a two-way bridge between TFS and Git. It lets you treat TFS source control as a remote repo. Basically all it does is provide you some Git commands that let Git work against your TFS source control. I'll show you some possibilities:
Getting started
First of all, you need a version of Git on your machine. I use Git For Windows and this works very well (it also gives you a GUI to visualize changes and merges). The next step is to download Git-TFS (a .zip file). After the download, unzip it to specific location (for example C:/GitTfs/) and add this location as an evironment path of your machine. That way you can use the Git-TFS commands in the commandline.
System Properties -> Advanced -> Environment Variables and edit the path variable. Add the Git-TFS path to the Variable value
To check if your Git-TFS will work, just open a commandline window, and enter 'git tfs'. You should see a list of the available commands. Type 'git-tfs help [command]' to get some information about a specific command.
Get your source from a TFS repository
Getting your repo sources from TFS is extremely easy using:
git tfs clone http://tfs_server:8080/Collection $/your_project destination
In my example, I cloned a test project
Make some changes and check-in on TFS
The next thing we can do is change some code. After the change has been saved, we have to commit to our Git repository using:
git commit -am "My checkin"
(Be sure to do this on the correct folder level, otherwise Git will not find your .git repo). This is a general commit command for Git. For more information about Git command, check this link.
Now that the changes are commited to Git, they need to be pushed to our TFS Source Control. Do this with:
git tfs ct
You will see the check in dialog so you can check-in your changes because you supplied the "ct command" (checkintool).
Once the check-in is completed, git-tfs automatically pulls the changeset from the TFS server and merges the change locally in your repository. This is how it looks like:
You can see the changes in the source control history from TFS.
Get changes from TFS in our Git repository
The next thing we want to do is the opposite: Get some changes from TFS in our local Git repo. First change some source code directly from TFS, and do a check-in. All we have to do now is:
git tfs pull
This does an update of your local Git repository with the latest version from TFS.
Conclusion
Git-tfs is really easy to use, and if you're an advanced Git user but forced to use TFS source control it's the way to go! I'll also give you some interesting links:
Git workflows with git-tfs:
http://lostechies.com/jimmybogard/2011/09/20/git-workflows-with-git-tfs/
Git-tfs recent improvements
http://www.richard-banks.org/2011/03/git-tfs-recent-improvements.html
Thanks for reading!
One of the cool things about using Team Foundation Server is the fact that it's not technology bounded. What I mean about that, is the fact that you're not tight to Visual Studio as IDE and that TFS can also be used to build non-microsoft solutions like Java. In this blogpost, I would like to describe how you can use Eclipse to manage your TFS environment.
Last year, Microsoft released a plug-in for Eclipse, originally called TeamPrise but now it's 'Team Explorer Everywhere' (TEE). Using this plug-in you have access to TFS 2010 from Eclipse, which is a very popular IDE. Projects using Java/PHP/.. can now also leverage the benefits like workitem tracking, source control, build automation, reporting and web-portals.
This is a quick overview of how to install TEE. First of all, I will use Eclipe on a Ubuntu environment (just to show that it also work on Linux machine). I downloaded the latest Ubuntu release (which is really cool, btw) and created a Virtual Machine to install Ubuntu. After installation of the OS, you get this nice welcome screen:
Next step is to install Eclipse. Very simple, just download the Eclipse (3.7-Indigo) environment you want (for Java, classic, PHP). In linux, this will be a tar.gz and in Windows a normal .zip file. All you have to do after downloading is unzip/untar the file and put it in C:/eclipse or /home/.. (whatever you want). The next thing that you have to check is that you have a JRE/JDK installed. (download on oracle.com). Now it's time to run Eclipse:
The next thing we want to do is install TEE SP1 (SP1 is a full package, there is no need for the non SP1 version).You can download the connector using your MSDN subscription, or using the public download url. You can download all 3 files, but actually you only need the file TFSEclipsePlugin-UpdateSiteArchive-10.1.0.zip. When the download is finished, go to Eclipse and select 'Help -> Install New Software'. This opens a dialog where you can install additional plugins/connectors.
Click on the 'Add..' button to add a new repository. Enter a name, like 'TFS connector' and click 'Archive' to select the downloaded zip file. Select the new item you've just downloaded and click next. Follow the wizard, accept the license and click on the 'Restart Now' button.
When Eclipse is restarted, you don't see many changes. The TFS related windows are more or less hidden by default. You can show them by selecting 'Window -> Show View -> Other -> Team Foundation Server'. There you can select the windows you want.
Now we have TEE installed in Eclipse, we can start using it. Create new project and add some awesome codefiles to it (yes I use PHP in my examples :$). If you did that, we can add the project to our Team Foundation Server. Right-click on your project and select 'Team -> Share Project'. There you get a dialog asking you for the TFS settings (Url & credentials). Supply them correctly and click Next.
Note: If you use Active Directory to connect, enter the correct domain and complete the username with your windows username. Also be aware that if you check 'Save password', the password will be saved in plain text on your system!
Then you get a list with your team projects, select the team project you need and click Next. In the list you see now, click the Team Foundation Server workspace to which your project will be connected, and then click Next. (You can offcourse also change the default values from your workpace). The last step is to select the folder for you shared projects (the project folder path). Click Next. In the last dialog, you have an overview of your selected settings, and now just click Finish
Now that the project is added, we can do a check-in using the 'pending changes' window. If you look there you will see that all files associated with your project are marked as 'add'. Now add some comments and click 'Check In'.
Ok, so now we can do (allmost) all things we can do with the 'normal' Visual Studio Team Explorer. We have our team explorer, we can manage our sourcecontrol, manage our build, our workitems, merge files on update conflicts,... The only restriction I found was that there is no possibility to use the braching/merging actions/overview like you can in the regular TE. Other than that, I think it's quite similar to the Team Explorer from Visual Studio. Some screenshots:
This was an overview about how to install TEE on Eclipse. In a next blogpost, I'll cover how you can build a JAVA project using ANT/MAVEN with the TFS buildserver (using the Microsoft Team Foundation Server 2010 Build Extensions). Stay tuned!Some reading material:
Five Hidden Features in Team Explorer Everywhere 2010 SP1
Team Explorer Everywhere 2010 SP1 is Available
If you are using Team Foundation Server, you definately have been in the situation that you want to delete a Team Project. Perhaps because it's obsolete because you moved all branches to another Team Project.
To delete a Team project, you have two possibilities. The manual command-line way, or using the TFS Administration Console.
1. The command-line way
You can delete a Team Project using the TFSDeleteProject command. To use this command, open your Visual Studio Command Prompt, enter this: 'TFSDeleteProject' and press enter. If you see the information about the command, you're good!
First of all, keep the following in mind
TFSDeleteproject [/q] [/force] [/excludewss] /collection:URL TeamProjectName
Ok, let us assume that we want to delete 'ProjectToRemove'.
TFSDeleteproject /force /collection:http://luna:8080/tfs/Cognistreamer ProjectToRemove
In my case, the team project is located in the CogniStreamer collection. If you execute this action, you will be warned about the fact that this is an irrecoverable operation. Enter 'Y' to continue.
2. TFS Administration Console
The next possibility is to use the TFS Administration Console. You can open the console using 'Start - All Programs - Microsoft Team Foundation Server 2010'
Open the Application Tier node and select Team Project Collections. Select the correct collection, en select the team project you want to delete. Next step is to click 'delete'.
In the next dialog, you can select to delete all external artifacts (like SQL Server reporting services, labmanagement) and to delete all workspaces related to this team projects.
This should do the trick!
Ony one remark, from what I experienced, you can only delete the sharepoint site using the command line approach (or exclude the removal using /excludewss). But in the TFS Administrator console, you can only delete the external artifacts and workspaces, but NOT the Project Portals..
A while ago, I made a presentation about 'Improved software testing using Visual Studio and TFS2010'. I thought it would be interesting to put it on my blog too.
A while ago, I asked a question on Stack Exchange Project Management about how to use the Kanban board for very small tasks. Let me explain what I mean about small tasks:
We do development of some products (web-applications) which are used by our clients. Some clients use our generic products, and some others have a customized version. Mostly in the -week before release- we get several test-run remarks from our client. Those are (mostly) some small things like some CSS tweaks, some formatting, changes in the list-orders and so on.. Nothing big..
I was struggeling about how to translate those issues to our Kanban board. Do I have to create a 'post-it' for every issue? If yes, I suppose it will take longer to create a post-it, attach it to the right column, let the dev fix the issue and then let him move it to the testing/done column. Another thing is the board overload.. Ok, you have the WIP limit some columns, but in the end all the done items are there, and the board will look very overcrowded. Also the WIP of the 'selected' column is less than the number of items to fix.
So, how to handle situations like this? As I really want to visualize the issues and have a reference to the Kanban board.
I found the answer on Joakim Sunden's blog. (Thanks to Pawel Brodzinski for the link). The concept he explains is to have a dedicated log for such tasks. The only thing in this log is an issue ID (wich can be the TFS workitem number, or a task-management/bug tracking tool ID). The ID is crossed out once the issue is fixed. If you keep this log close to your Kanban board, you have a clear overview of the open and fixed issues. The other nice thing is that you can easily move items to the Kanban board which do need more work than initially thought.
Personally, we did choose for a project approach to group our issues. Each project has a column, and this colum does only contain a list of issue ID's. You could also create columns for each individual person in the team. It's up to you to decide. If someone is working on one of the issues, you can add a sticky to the correct column on your Kanban board with some information about issue fixing of product X/Y/Z
We are using this approach for a while now and it seems to be working well! I'll keep you posted about the evolutions we make with our Kanban board and the issue list! Thanks for reading!
Now that we are using our Kanban board for a while, it's time to do some analytics with the visualized information on the whiteboard. Kanban is not only about visualizing your process with a bunch of post-it's, you can actually do a lot with those "post-it's". What I will try to explain in this post is how you can define the lead & cycle time of your items on the board. That way, we can provide some time-related information to our customers about how long it will take to make a particular feature and how long it will take from 'request' till 'delivery'.
When you use the Scrum methodology to deliver new features to your client, it's clear that your feature will be ready by the end of a sprint (in normal circumstances). That's because it uses a time-boxed approach. Using Kanban however, you don't have any time-boxed iteration. That way it's quite hard to tell the client when the request will be accomplished.
First of all, what's the defintion of a lead time and a cycle time? And also, what's difference anyway?
Lead time
This is the time needed to get your feature ready. In Kanban, this is the time from when your item is added to the backlog till your item is live. So the clock starts when the request is made and ends at delivery.
Cycle time
The difference?
Conclusion
Using these 4 measurements, I will be able to determine the lead and cycle time of our board.
Note: I'm not quite sure about the time as when the item is ready. Is it really ready when the feature has passed the acceptance phase? Or is it really ready when the feature is 'live'? Any feedback is really appreciated!
In a next post, I will try to explain how you can improve the lead and cycle time using my personal experiences. Thanks for reading!
