Testing & ALM

Decomposition into Tasks Your backlog is normally comprised of requirements in the form of User Stories which depict the resulting value required by the users of the system. During iteration planning, teams take the highest value requirements and assign them to the current or next iteration, filling the iteration to capacity. Agile teams typically do not decompose requirements into work tasks until they are assigned to an iteration. Agile teams spend the first few hours of each iteration going through iteration planning, and a part of that process is the decomposition of requirements into work that can be completed by ...

A goal of well written unit tests is to keep your test isolated. This means that even if your code under test relies on or is dependent on another class or external service you should be able to write your tests to exclude these dependencies and test only what’s in your current class or method. Sound impossible? It’s not, in fact if you’ve read my previous posts on Dependency Injection you already know half the answer to this problem. The other half of the solution is mocking.

Now that we have a new Load Testing architecture, we're re-organizing the troubleshooting articles to bring everything up to speed. Most of the old issues with load have been resolved. For those that remain, we're creating new articles to help you resolve them more easily. First, if you don't get any load traffic when making requests to localhost, use the machine name or IP address. Simple. Next, some load tests still record duplicate dynamic targets. While there's no way to avoid this, you can make sure to select the repeated variable in all steps it is used ...

Updated: Fixed a few formatting and badly positioned graphics. No tool can ever possibly meet every team’s needs out of the box. It’s crucial to select tools that are extendable or customizable to handle things specific to you and your team. Test Studio gives you the ability to customize a number of things under the hood. One great feature is tying into events for test lists in order to handle setup or teardown steps. This lets you do things like load baseline datasets, clear out test-generated data, or perform configuration actions. The post below is written by Ivaylo Angelov, a ...

In the last post I showed you how from time to time it is necessary to change our code to enhance readability, make maintenance easier or to optimize the codes performance. This practice is called “Refactoring.” Normally making these kinds of changes can be a nerve-wracking experience for developers as they can’t be certain that their changes aren’t breaking something else. However, having a suite of unit tests the exercise your business code enables you to refactor your code without worry; as long as your tests pass you know that your code still satisfies your business needs. In addition to our code, sometimes our unit tests themselves need some refactoring. This post explains how to refactor your unit tests and demonstrates a few NUnit features that will help us with this endeavor.