Latest

  • .NET Testing & ALM

    Top 4 Challenges for Agile Planning

    Despite trying to achieve simplicity, Agile teams may still run across difficult issues. In this section some of the more common challenges are explored. HANDLING INCOMPLETE WORK AT THE END OF AN ITERATION It is not uncommon for a team to have incomplete work at the end of an iteration. Unfinished work is an important issue to identify as it signals a potential problem with one or more aspects of the team. When an iteration is planned, the team sets an expectation with the customer. When those expectations are not met, the customer could lose faith in the team’s ability ...
    October 09, 2013
  • .NET Testing & ALM

    New Solutions for Scheduling Issues and More

    This week there are several new solutions for scheduling issues in Test Studio 2013 R1, as well as some tweaks to old docs that may help you out. The new scheduling architecture is simpler and more reliable than ever before, but you can still run into some complications. In some scenarios—for example, if you delete a test project on disk before removing the scheduled test runs in the Results view—you might have scheduled test runs that you can't remove or edit. If you run into this issue, you can remove the scheduled test run on disk. Also, if you ...
    October 07, 2013
  • Testing & ALM

    30 Days of TDD – Day 12 – Working with Stubs

    “Mocking” is one of those magical concepts derived from OOP that makes TDD possible. But as you saw in the last post, there are many different kind of mocks and each has its own strengths, weaknesses and purposes. We’ll discuss most of these types of mocks at some point in this series. But in this post I’m going to demonstrate one of the most common type of mocks you’ll use; the Stub.
    October 07, 2013
  • .NET Testing & ALM

    It's All About the Data

    We collect a lot of data during the testing process, but whether we put it to good use is a different story.  We run individual tests of test cases, and determine if they pass or fail.  If they fail, we determine at what point they fail, and provide the steps necessary to replicate that failure. We look for performance of individual transactions early on in the testing process, then when our goal turns toward deployment, we add virtual users to determine the behavior characteristics of the application and servers under stress, as well as whether it can successfully handle the ...
    October 04, 2013