People involved in developing, testing, and delivering hardware, software, or internet based applications must be able to ensure those solutions meet customer and user expectations… The question that follows – Exactly what are those expectations and how do you ensure they are being met?

WOPR11 will explore the topic of reliability with seasoned professionals, including architects, designers and performance and reliability testers.

WOPR10: Call For Proposals(CFP)

Theme: How can we teach performance testing?

Every aspect of performance testing from problem awareness to systematic modeling, performance testing experiments, result analysis to problem reporting and getting the darn system actually working involves a rich an complex set of interrelated skills coupled with a blend of detailed technical knowledge and rich context sensitivity.  What are these skills?  How can we teach them?

Click to watch: Using Fit: An Open-Source Testing Framework

Description: Google TechTalks February 9, 2006 Rick Mugridge Rick Mugridge is the lead author of the first book on storytests: "Fit for Developing Software". He has developed and is evolving FitLibrary to better support storytest driven development. He is a leading thinker and inventor in this area, and consults and coaches internationally in storytesting, executable specifications, and agile software development. ABSTRACT We raise four software development issues and show how Fit can be used to address them. The issues are as follows: (1) How can we improve test coverage on a legacy system without discouraging its evolution? (2) Now that we have a successful product with a great UI, how do we provide program access, such as through SOAP? (3) How can QA be involved earlier and more effectively? (4) How can product managers better utilise their expertise? Each of these issues can be addressed with Fit storytests. Storytests satisfy the demands of both requirements and quality assurance, in an amalgam that initially looks weird and counter-intuitive. Storytests are concrete examples that express important things about the business domain and about the system. They are matched and generalised in the code, using the same "ubiquitous language". Week by week, as thinking and understanding grow and change, the storytests grow and change. And so the code evolves.