Stress testing is similar to load testing, except that the test is usually confined to a single operation. The goal is to determine the maximum capacity of a given set of hardware to perform the operation. This type of testing is useful in finding areas of your application that break.
One of my litmus tests for any application is to perform a stress test on a basic feature such as the login. If a simple and widely used operation like logging in fails under stress, you know that the rest of the application will most likely have similar problems.
Finally we get to performance tests. The goal of performance tests is to measure the response time of operations under load. Unacceptable response times have a direct impact on how users perceive your software. If things take too long, then users may get impatient and not want to use your software. The key to measuring performance is to perform the measurement under load. This can be accomplished using both the load and stress tests previously mentioned.
The goal of today’s modern Continuous Integration practices (CI) are to automate the build, test and release of an application. The concept of CI now supports the automation of building the application and running unit tests. The goal is to not check anything into source control that could degrade the quality of the application. For example, if a developer has code that is unable to be built, you don’t want that code to enter source control. Instead, you want that developer to save their changes without checking into source control. Then when they are ready, allow them to check in.
TFS supports a number of build triggers such as manual, CI, rolling builds, gated check-in, and scheduled. For the purpose of improving quality, we look to either CI or gated check-in.
The developer workflow described above is supported using gated check-ins and shelvesets. A gated check-in is a check-in that is honored only if the submitted changes merge and build. This protects the code that resides in source control from getting to an unusable state. When you run into situations where your code does not build, you can use a shelveset.
Shelvesets are great for a few reasons. First, they allow you to save your work in progress and continue with a different task. Second, they allow you to share code that is not ready for check-in. Finally, they allow you to share code for code reviews using the Code Review feature in Visual Studio.
Continuous Delivery (CD) is the process of automating deployment of software so that it can be released at any time. This process works with CI to produce deployments once code is submitted to source control. Tools in this space include Visual Studio Release Management, Octopus Deploy, Atlassian’s Bamboo, and JetBrains’ TeamCity.
CD allows you to deliver your software more frequently to other environments, and it gets the software in the hands of your QA and users earlier. This helps quality assurance and user acceptance testing occur more often.