Test Design

.NET is a multi-tiered approach to developing applications for Windows OS and Web applications. While these are new development tools, many testing requirements remain the same, yet require additional emphasis by a QA organization. Plus, with .NET's extra layers of abstraction, even more developers enter the programming arena with fewer technical skills than previously needed for standard Windows development. For instance, if a bug is found "in the depths" there's now more likely to be a work-around to the issue instead of a true fix. In other words, treating the symptoms instead of finding a cure will now become the norm. This presentation introduces you to the big picture of .NET and what you need to be aware of as your employer moves in this new direction.

This paper describes the way that a UK company controlled and improved ad-hoc testing, and was able to use the knowledge gained as a basis for ongoing, product sustained improvement. It details the session-based methods initially proposed, and notes problems, solutions and
improvements found in their implementation. It also covers the ways that the improved test results helped put the case for change throughout development, and ways in which the team has since built on the initial processes to arrive at a better testing overall. Session-based testing can be used to introduce measurement and control to an immature test process, and can form a foundation for significant improvements in productivity and error
detection.

Several jokes about consultants revolve around the idea that they answer most questions by saying "It depends." The context-driven school of testing accepts the "It depends" reality but then asks, "Depends on what?" Rather than talking about best practices, this approach asks when and why a given practice would be beneficial; what risks and benefits are associated with it; what skills, documents, development processes, and other resources are required to enable the process; and so on. Rather than dismissing an unpopular testing technique or test documentation method as useless, you should ask these questions to determine possible uses. The appropriate context might be narrow, but you'll learn a lot more about the technique and its alternatives by becoming aware of the context variables rather than ignoring them.

When processes include several applications, the testing process is complicated in many ways. Possible complications include: organizational issues because of the multitude of test teams and their interdependencies; processes and transactions that span the chain which require new test scenarios; integral design, information analysis, and process design documents that aren't fit for the purpose of chain testing; and test execution that demands integral knowledge of the chain. This session gives you a list of all the variables that need to be considered, then offers solutions for successfully organizing chain testing.