First of all I would like to aplogize to everyone who signed up for the email notifications for the ALM User Group. That list was mis-placed and I was not able to add people.
so we will try it one more time with list sign up, or you can subscribe to our blog or sign through codezone.
An now i am proudly announce that we have our first meeting on 4/29/08 at 5:30 pm.
See more details at the site.
Since I have been challenge to respond by my Boss, known in the company as a QUITTER to the moving, here is how I see moving and packing from the TFS point of view:
First of all the shipping boxes would be known as a “Changesets” that may contain many different items. As each item is packed it will get a unique version id. As I move item around I would create new boxes to hold a newly moved item. Interestingly I may actually be able to “clone the item”, since the same item will be part of the different boxes. I may require a Packing Review before any of the packing is committed and the box filled. Once the box is full of the continents an automatic shipping process will kick off to verify that all my packing is done according the shipping standards and that my packing does not break other people packing, the shipping company and all other parties that subscribe to Alerts will be notified of the filled boxes. Not only one shall be able to see the contents and status of the box, but also all the requirements that prompted the filling of the box and how many times it has been re-packed due to the changing shipping/moving rules.
Hypothetically speaking...
Lets assume that one of my "friends" made a big mistake and have checked in the code into TFS, and broke the build, and screw up the code that was frozen & suppose to be ready to go to the production!
So, what can the "friend" do at this point, considering that once the code is checked in into the TFS source control it does become part of the permanent record.
Well the "friend" has found that the easiest thing to do, besides blaming the PM is to do following:
1. Find the Changeset that was preceding the check-in, one can do it by right clicking on the solution/project/file(s) (I think solution or project would be preferred to ensure that all changes will be rolled back) and selecting "Get Specific Version"; from the Type dropdown select "Changeset" and using the Changeset dialog to display all change for the day or person.
2. Once the code for the selected Changeset is loaded, you still have nothing to check-in, so trigger the checking process, select solution/project/file(s) and select "Check Out for Edit".
3. Now one should be able to check-in the back into the source control by selecting "Checkin Pending Changes".
4. Here is where the fun comes, during the check-in process "Conflict" dialog will popup, one should select the file(s) and click on "Resolve" choice and select "Discard Server Changes".
5. Now that all conflicts has been resolved, repeat step 3.
Alternatively, one may download Team Foundation PowerToys (TFPT.exe) and use one of the nifty commands: tfpt rollback /changeset:###; if there are any conflicts detected user is presented with a "Merge" dialog.
Several of my co-workers have run into the problem of exporting work items into the Excel 2007. The problem was/is during the export of HTML type fields (like description) in some cases they have gotten #### instead of actual words.
There is a forms post that have one of the permanent solutions listed, but I found a workaround to the problem or at least temporary solution by formatting the cell/column.
option 1:
I have selected "Format Cells" -> Number -> Custom -> General -> OK
and the final result is:
option 2:
alternative approach, if one knows how to use new Excel ribbon menus would be selecting cell/column and: Home ->Style -> Normal to reset the style and to re-enable wrapping: Alignment -> Wrap Text
So what is the moral of the post? Lets stop blaming TFS and start learning on how to use Excel :)
Key note presentation by Bob Mugila was pretty entertaining, "Back to the Future" skit was great. I like the message presented by Bob, he had mention that IT is a big pendulum that swings from what is the important at this time, and three key pilars of it are: process, quality, and agility.
From my working experience, I can totally see it. When I started to work at one of my old companies it was all about process, it was driven into my head "RUP this and RUP that", we need to have a process in place on how to take a lunch prior to taking it. Shortly after I have started to dream about the process in my sleep, the company took a turn into a new direction, that can be summarise as: "we do not care how you do it, but it must be done with 'high' quality and bug free!"
What I liked about keynote presentation is that for us to succeed, we need to do combination of all three. The idea that if you have a process in place, we can improve the quality of work (simply by doing what we do and examining the history) and of course if the process is flexible we can achieve agility without sacrificing the first two. It totally make sense, that combination of 3 is what will make any company successful. Interesting observation that at my current company we are taking the position that: process, quality, and agility is truly a single driving force/foundation to the success.
Recently, I was given an opportunity to give a presentation on TDD and how one may use VS2005 to accomplish this task. During the presentation I have used a standard Microsoft presentation on TDD and VSTS.
During my presentation I showed several examples on how to author: unit test, manual tests, load tests, web tests, database unit tests (stored procedures), and ordered tests. We have looked closer at: Test Manager, Code Coverage, Code Analysis and how these functionality integrates with TFS. The sample solution containing all the code can be found here.
My final thoughts on testing in VSTS:
1. Visual Studio Team System makes testing easy, great auto-generation tools allow one to generate all the plumbing without any hassle; it also provides a starting point for learning how to create tests.
2. With an exception on Windows Forms UI tests VSTS allows to generate tests that will cover all the aspects of the development and testing.
3. 100% Code Coverage does not mean that the application is bullet prove, it should be used in conjunction with Code Analysis to identify if we are comfortable the number of tests.
4. all written tests should be used in regression testing, once we start to modify existing code.
5. We have "white tests" written usually by developers that deal implementation and technology details; and "black tests" written by testers (QC/QA) that deal functional requirements of the application.
An interesting thought: From the tester's point of view we need to create a "time line". For example users does something in the system, system does something in response and based on the those results user does something else. For example user creates a task, task's work flow/state triggers additional email notifications that may provide user with additional information.
So what is the problem? The problem is that we are violating several rules: Unit Test must be simple and cover small portions of the functionality and all Unit Tests must be independent of each other. My current solution for this problem:
1. use multiple asserts in the test and
2. group relevant tests in Ordered Test.
Any thoughts on it?
subscribe