you know that the files and data that are part of a completed build can delete?
you know that the data deleted cannot be recovered?
you know by default Test Results from any automated tests run against the build
are deleted by default?
If you have the right permissions you can right-click in Build Explorer
on a completed build and select delete. When you do that by default all the
items associated with that completed build are deleted.
Details: Information about the completed build that
is displayed in Build Explorer. This information includes build steps,
requestor, and date and time queued.
Drop: File and folders output by the build and
copied to the drop location.
Test Results: Results of any automated tests
executed during the build process or results of any test published against this
Label: The version control marker associated with
the specific file versions used by the build process.
Symbols: The debugging symbols published to a
symbol server during the build.
You can also configure the retention policy and set auto deletion rules
. Nothing wrong with that however is the person responsible for the “Build”
setup and maintenance deleting could be deleting Test Results?
There is an option that can be set to stop the deletion of your Test
Make sure your teams understands what happens when deleting completed
builds. Set that option to keep your test results, unless you don’t want them!
Typemock is presenting a webcast “Introduction to Unit Testing” if your a tester this will be a good intro into unit testing. Pass this onto your developers even if they unit test.
Software testing isn’t just a task for QA. In order to prevent bugs and release quality code to market, you also need developer testing, including unit testing. Discover why you should start unit testing, and how you can get started with automated tests quickly.
Click below to register
Introduction to Unit Testing
Harry Baran from Thoughtworks posted a blog that I think is very much worth sharing. Harry outlines in his posting some of the difference between unit testing in Agile to the Traditional approach.
Unit testing in any process needs to be getting the attention it deserves, if done right it can be an early quality indicator for the solution under development. Test teams need to get involved in unit testing to some capacity no matter what process/methodology being followed. Pair up your developers and testers, offer training to your testers in unit testing and coding, hire testers with coding skills, let your testers see and understand what is being unit tested.
To quote Harry Baran: “Unit tests are foundations of an agile project. They enable fast feedback, continuous testing, continuous integration and refactoring.”
As children we were taught to share, for some reason one of the most important aspects of developing an application has not been shared. Time to change that, isn’t it?
Unit Testing: Agile vs. Traditional Approach
Great write up Hari, thanks,
In the blog Functional/System testing with Visual Studio/Test Manager we talked about unit testing. Testers in the near future are going to need unit testing skills. Now that is a very scary statement given 70% of testing is done manually. Now is the time to start learning by taking programming courses, unit testing courses, pairing with developers to learn and searching the web.
In the Visual Studio magazine Jeff Levinson article Take Unit Testing to the Next Level talks about how to add unit tests to requirements to show test coverage. Jeff supplies code you can download and instructions on creating simple unit tests then how to link them to requirements. If you have Visual Studio give it a try.
At TechEd 2011 in Atlanta Microsoft showcased some of the new features coming in the next release code named vNext. Check it out by clicking the different links below:
VNext – click the link to the vNext demo.
New Features are:
Storyboarding– A plug-in for PowerPoint that connects the creation and review of story boards with the rest of the team.
Backlog & Sprint Planning– New web based product backlog, sprint planning and task board.
Client Feedback –New tooling support to invite and receive feedback from stakeholders during development.
Team Navigator– More time ‘in the zone’, through improved experiences for day-to-day tasks.
Continuous Testing – A new unit test runner continuously running unit tests in the background
Agile Quality Assurance – Increased code quality with code review support, enhanced unit testing frameworks and new exploratory testing support.
Aligning Development with Operations (Intellitrace in Production) – Increased connections and insight between the operations and development teams lowering the time it takes to fix a bug in production.
SCOM & TFS Integration – Software Centre Operations Management now integrated with TFS.
Channel 9 - The Future of Microsoft Visual Studio Application Lifecycle Management Cameron Skinner talk at TechEd 2011
Whitepaper: PDF whitepaper which reinforces the value propositions for what we’re delivering in vNext.
If you have never been to Toronto here is your chance plus while here you can learn about Microsoft Test Manager, Coded UI testing, Web & Load testing, the new Bug, Fast Forwarded Manual Testing, and all you need to know about TFS2010 the communicator. Here is your chance. Check out our 3 day course offering being held March 9th to 11th and get 10% off.
Tell them Testa send you …
Do you recall the Test List editor (the file in the Test Project .vsmdi) that was constantly causing the team headaches,? In VS2010 Test Categories has come to the rescue. Test Categories allow us to grouping our tests together which then can be run and reported by category.
Test Categories are set up through the Test Viewer in Visual Studio 2010.
1. Open Test View window (Test –> Windows –> Test View)
2. Select a Test and open the test properties (right-click on test and select Properties)
3. Find Test Categories then click the dropdown arrow to the right
4. Test Category window opens where you can:
- Add new Category
- See Available Categories
- Assign Categories
Microsoft recommends using Test Categories instead of the Test List functionality, however if your using the Test Check-in Policy you will still require the test list. You can use both the test list, for your check-in policy and then test categories for all other tasks.
If created a Build Verification Test list using the Test Editor list no problem, create a Test Category named BVT and instead add this to your Build definition.
Under the Basic section, in the automated tests section open the Test Assembly then click and select a Category Filter. The test category filter consists of one or more test category names separated by the logical operators '&', '|', '!', '&!'. For example, TestCategory1&TestCategory2 will run all tests with a test category of TestCategory1 and TestCategory2 . Or you can just select all tests in one category by entering TestCategory3. (The logical operators '&' and '|' cannot be used together to create a test category filter.)
Share your usages of Test Categories by adding comments to this blog, I will publish them.
Test Category for Smoke or Regression tests, a portion of an application …
Andre King & I presented “Never Test Alone” at TASSQ in Toronto yesterday evening. After the presentation Joe Larizza (TASSQ President) addressed the group saying that with the economy businesses are looking for ways to reduce costs. Outsourcing testing will be one of them. People need to be proactive in finding ways to reduce cost and produce quicker. Joe encouraged people to talk to their management teams, present the concept outlines in “Never Test Alone” and volunteer to give it a try. See how it works, what it saves and in the end you may be saving more then you expect.
In Never Test Alone testers are involved in the Requirements & Design reviews and validations. This allows the test team to prepare for testing early, creating test cases, test scenario's and other documentation at the start of the project. Plus testers add value to the process from their experience and perspective. This reduces the cost of the test group weeding through requirements later to get an understanding that may not even be a correct one of the system. Enhancements that testers log during testing will come out during the requirement review phase. If deemed required can save money by being incorporated before development starts versus later.
Team up testers with developers during the creation of unit tests, the more tested at this stage the less cost in fixing, less bugs later, and we can reduce the duplication of testing being done between the two groups. Testers now know what has been tested therefore will not have to retest later. A testers perspective in what needs tested will differ from a developers so the combination of the two creates very rigorous unit tests.
If you are doing continuous builds (http://en.wikipedia.org/wiki/Build_automation) the unit tests are run against each build becoming regression tests. So we now have during unit testing, the functional testing and automated regression testing happening very early in the project.
Unit tests can be used in load testing. One example is login where UserID and Password are entered. The unit test can be build to retrieve from a listing of many UserID/Password combinations to execute login many times. What is the savings in knowing during development that the system is not going to have problems with 1,000 concurrent logins? Add this test to the build regression tests and you know throughout your project how well it is standing up to load. Why leave load testing to the end, do it early and save time, money and possibly the project.
Andre demonstrated a tool for automated white box testing, Microsoft Research PEX (http://research.microsoft.com/en-us/projects/Pex/). Very impressive and it can be run against code by testers saving development time for development. Check out the link above for a white paper on PEX. Maybe Microsoft will make a version of PEX that testing can use which does not require us to have access to the actual source code.
This is a list of some effects from following this presentation:
testing a lot earlier
saving money on bug management
saving money on system changes late in the project
building a team relationship
- great feeling of accomplishment
And you are not testing alone, it is a group effort and it is the route to success.
Link to TASSQ