Lesson 7 - Testing in C# - Quality Assurance, CAN PIG RIDE, and ISTQB

In the previous lesson, Acceptance Tests of Real Applications in C# .NET, we showed sample codes of acceptance tests from real-world commercial applications. At the very beginning of the course, we explained the reason why to write tests at the first place, what kind of tests there are and what extra value they mean to us. My goal was to motivate you to test your applications and give you a competitive advantage over development teams managed by someone who doesn't understand software development (in practice, managers with just economic education, unfortunately, often manage such teams).

Until now, we have been very practical. But there are still some theories and terminology around testing that we should know and you're probably going to encounter it in your business. These are best practices, well-known documents, standards, and procedures. We also haven't mentioned the user interface testing. In the next two lessons, we're going to introduce this information to make your knowledge set complete. At the end of the course, we'll also try to stress test our C# application.

SLA

Service Level Agreement (SLA) is usually one of the documents between the software supplier (us) and the customer. Here we define how the software should work, how we guarantee it, and how flexible we intend to respond to events of downtime and failures in general. The bigger the project and the more money it cost, the more money is blown up when it stops working and the more pressure there will be on you putting it back into operation.

It always makes sense to define the SLA, no matter it's just a template e-shop for thousands or a government funded application for millions. Defines at least what you're responsible for, in what time-frame you're willing to fix errors (for example, 2 years since the delivery), and how much money you'll add new features for. Because the customer doesn't understand IT, they think, that