Whether you are building a brand new product or evolving an existing system, understanding the business needs of your customers is the foundation of a marketable product or valuable internal application. Few of us are experts in interviewing techniques, and few customers talk about their tasks, needs, and context in neat, concise statements about requirements. Hone your elicitation skills and learn what it takes to get beneath the surface and understand your customers: their world, how they work, and what really bothers them. With effective interviewing techniques and skills, you will get inside their heads and better understand their needs within their context.
As a decision-making framework, a test strategy outlines the vision and values that drive the project and keeps you on a clear path in times of change or uncertainty. A good test strategy makes you more resilient to inevitable changes as the project progresses. However, each test
project needs its own strategy depending on the business and risk profiles of the applications, technology in use, development methods, and even the experience and culture of the test group. In this interactive session with James Lyndsay, you will learn about a wide range of test strategy
These days, we hear a lot about unit testing, testing for programmers, test-first programming, and the like. Design techniques for such tests and for improving system testing are often called white box test designs. Join Rex Black as he explains the basics of white box testing and compares
white box with other types of testing. Find out how the metaphor of "boxes" can inform-and confuse-us. Rex discusses the basis path tests, including cyclomatic number as a measure of complexity and a way to determine the number of tests necessary to cover all paths. He walks
As software professionals, we all care about quality. We focus our efforts on building quality into the code and testing to assess quality and find errors before our customers do. However, there is an important element of quality that comes before all that and is critical to delivering reliable software: quality working relationships and quality interactions. Esther Derby covers pragmatic strategies for building, strengthening, and maintaining working relationships with all stakeholders-managers, customers, team members, and peers. The first step is to build a foundation of trust and respect. Then, we must focus on interests rather than positions and seek joint solutions to problems. We should use the richest communication channel available for our interactions and make a generous interpretation of others’ actions.
Acceptance testing is a vital and specific form of testing whether you are tasked with rolling out an enterprise application package, releasing a major system enhancement, or developing acceptance tests in an agile development project. In addition, acceptance tests can give some teeth to service level agreements and software acquisition contracts. However, most treat acceptance testing as the same activity as system testing-but done by different staff. That is wrong! Because acceptance testing is not about bug hunting and breaking the software, you need a different strategy. With over 25 years of experience covering acceptance testing for all types of systems from safety critical control systems to standard financial applications, Geoff Quentin shares his views on how to do acceptance testing correctly.
Beta testing is an industry standard practice to obtain user feedback prior to general availability of software. Have you ever considered that the Beta release can be used to validate the software's value to customers and application users? Extending the Beta concept will result in higher customer satisfaction (and higher revenue for commercial products). Also, you can employ Beta testing to evaluate not only the software product, but the distribution (and sales) process, training, customer support, and usage within your customers' environments. Far beyond just finding defects in the product, you can focus Beta testing on how well the software is meeting your customers' needs. What does that mean to the Development team and the organization as a whole? What are the risks and challenges that we face? What are the rewards?
Continuous integration is the process of performing a fully automated build, run often, usually daily, during software development. How do you develop a robust platform architecture to automatically integrate your software into builds? How can open source tools fill the gaps in your platform architecture? After examining the benefits of continuous integration, Paul Duvall discusses techniques, such as architectural validation, configuration management, automated unit testing, and report generation within the process. From a working reference implementation in Java, learn the attributes of an effective platform architecture for continuous integration. Additionally, Paul will introduce you to open source tools, such as Ant, Maven, CruiseControl, Eclipse, xUnit, and others that can help you implement a continuous integration architecture in your environment.
eXtreme programming emphasizes test-first coding-you write the tests before writing the implementation code. You can apply the same approach in design when developing a complex system, including an architecture to support testing. To be successful, systems developed with agile methods must support a high level of testability and test automation. For large distributed systems, more sophisticated testing is needed to help determine which components may be contributing to failures. For such complex systems, you should architect the system for testing rather than add testing functionality as an afterthought. Ken Pugh presents a framework that employs polymorphic-style internal and external interface patterns to ease the work of testing and debugging. He also covers adding test-only functionality, test-only outputs, and test-only logging to interfaces.
Using a challenging client engagement as a case study, Rex Black shows you how he and a team of test engineers created an integrated, automated unit, component, and integration testing harness, and a lightweight process for using it. The test harness supported both static and dynamic testing of a product that ran on multiple platforms. The test process allowed system development teams spread across three continents to test their own units before checking them into the code repository, while the capture of the tests provided automated integration testing and component regression going forward. He'll also explain the tools available to build such a testing harness and why his team chose the ones they did.
Examine the benefits-and challenges-of implementing an integrated, automated component and integration testing process in a Java/EJB development environment
Testing is a never-ending series of trade-off decisions, what to test and what not to test; when to stop testing and release the product; how to budget your testing resources for automated vs. manual testing; how much code coverage is good enough; and much more. To make these difficult judgement calls, we often turn to the "best practices" recommended by testing experts and others who have encountered similar problems. The key to successful implementation is matching their "best practices" to your own context (team make-up, company culture, market
environment, etc.). Barry Preppernau shares his insights gathered from over 20 years of testing experience at Microsoft. You'll learn about the tools and processes that have been successful within Microsoft and ways for you to identify, adapt, and implement successful test improvement
initiatives within your organization.