|
|
Futility-based Test Automation Developers and other project stakeholders are paying increased attention to test automation because of its promise to speed development and reduce the costs of systems over their complete lifecycle. Unfortunately, flawed test automation efforts have prevented many teams from achieving the productivity and savings that their organizations expect and demand. Clint Sprauve shares his real-world experiences, exposing the most common bad habits that test automation teams practice. He reveals the common misconceptions about keyword-driven testing, test-driven development, behavior-driven development, and methodologies that can lead to futility-based test automation. Regardless of your test automation methodology or whether you operate in a traditional or agile development environment, Clint offers a solution on how to avoid the “crazy cycle” of script maintenance and ways to incrementally improve your test automation practices.
|
Clinton Sprauve, Borland (a Micro Focus company)
|
|
|
Testing the System's Architecture The architecture is a key foundation for developing and maintaining flexible, powerful, and sustainable products and systems. Experience has shown that deficiencies in the architecture cause too many project failures. Who is responsible for adequately validating that the architecture meets the objectives for a system? And how does architecture testing differ from unit testing and component testing? Even in the ISTQB glossary, architecture testing is not defined. Peter Zimmerer describes what architecture testing is all about and shares a list of practices to implement this type of testing within test and development organizations. Peter offers practical advice on the required tasks and activities as well as the roles, contributions, and responsibilities of software architects and others in the organization. Learn what architecture testing really means and how to establish and lead it in your projects.
|
Peter Zimmerer, Siemens AG
|
|
|
Grassroots Quality: Changing the Organization One Person at a Time Throughout its history, SAS has valued innovation and agility over formal processes. Attempts to impose corporate-wide policies have been viewed with suspicion and skepticism. For quality analysts and test groups with a quality mission, the challenge is to marry innovation with the structures expected from a quality-managed development process. Frank Lassiter shares the experiences of his group’s working within the corporate culture rather than struggling against it. He describes the services his group provides to individual contributors-mentoring, facilitating meetings, exploring best practices, and technical writing support. With a reputation for adding real, immediate value to the daily tasks of individuals on R&D teams, Frank’s group is enthusiastically invited into projects.
|
Frank Lassiter, SAS Institute Inc
|
|
|
Testing with Emotional Intelligence Our profession can have an enormous emotional impact-on others as well as on us. We're constantly dealing with fragile egos, highly charged situations, and pressured people playing a high stakes game under conditions of massive uncertainty. On top of this, we're often the bearers of bad news and are sometimes perceived as the "critics", activating people's primal fear of being judged. Emotional Intelligence (EI), the concept popularised by Harvard psychologist and science writer Daniel Goleman, has much to offer our profession. Key EI skills include self awareness, self-management, social awareness, and relationship management. Explore the concept of EI, assess your own levels of EI, and look at ways in which EI can help in areas including anger management, controlling negative thoughts, constructive criticism, and dealing with conflict, all discussed within the context of the testing profession.
|
Thomas McCoy, Department of FaHCSIA
|
|
|
Testing Embedded Software Using an Error Taxonomy Just like the rest of the software world, embedded software has defects. Today, embedded software is pervasive-built into automobiles, medical diagnostic devices, telephones, airplanes, spacecraft, and really almost everything. Because defects in embedded software can cause constant customer frustration, complete product failure, and even death, it would seem critical to collect and categorize the types of errors that are typically found in embedded software. Jon Hagar describes the few error studies that have been done in the embedded domain and the work he has done to turn that data into a valuable error taxonomy. After explaining the concept of a taxonomy and how you can use it to guide test planning for embedded software, he discusses ways to design tests to exploit the taxonomy and find important defects in your embedded system.
|
Jon Hagar, Consultant
|
|
|
Requirements Based Testing on Agile Projects If your agile project requires documented test case specifications and automated regression testing, this session is for you. Cause-effect graphing-a technique for modeling requirements to confirm that they are consistent, complete, and accurate-can be a valuable tool for testers within agile environments. Whether the source material is story cards, use cases, or lightly documented discussions, you can use cause-effect graphing to confirm user requirements and automatically generate robust test cases. Dick Bender explains how to deal with short delivery times, rapid iterations, and the way requirements are documented and communicated on agile projects. By updating the cause-effect graphic models from sprint to sprint as requirements emerge, you can immediately regenerate the related test cases. This approach is far more workable than attempting to maintain the test specifications manually.
|
Richard Bender, Bender RBT, Inc.
|
|
|
Operational Testing: Walking a Mile in the User's Boots Often, it is a long way from the system’s written requirements to what the end user really needs. When testing is based on the requirements and focuses solely on the features being implemented, one critical perspective may be forgotten-whether or not the system is fit for its intended purpose and does what the users need it to do. Gitte Ottosen rediscovered this fact when participating in the development of a command and control system for the army, leading the test team to take testing to the trenches and implement operational testing-also called scenario-based testing. Although her team had used domain advisors extensively when designing the system and developing requirements, they decided to design and execute large operational scenarios with real users doing the testing. Early on, they were able to see and experience the system in action from the trenches and give developers needed feedback.
|
Gitte Ottosen, Systematic Software Engineering
|
|
|
Don't Be the Quality Gatekeeper: Just Hold Up the Mirror One of the greatest temptations of test managers and their teams is to be the quality gatekeeper-the ones who raise the gate when testing reveals little and keep it closed when they believe that defects (found and unfound) risk the project. Invariably, this role creates an expectation from stakeholders that if the release fails or a major flaw occurs in production, the test team is at fault. Based on his sometimes-painful experiences, Mfundo Nkosi shares his insights on how testing teams can maintain credibility and increase their influence by holding a mirror up to the project rather than becoming the quality police. Mfundo describes the process of maintaining a risks and issues log, writing an informative test closure report, and clearly communicating status-the good and the bad-in a non-threatening way.
|
Mfundo Nkosi, Micro to Mainframe
|
|
|
Patterns for Test Asset Reusability Typically, testers write a test case for the one component and sub-system they are testing, thus limiting its value. What if you could repurpose and reuse previously developed test assets across several components and sub-systems? Vishal Chowdhary shares three test patterns he has encountered many times while testing various .NET Framework components at Microsoft. The “Test One, Get One Free” pattern describes how to test features that are layered-where a feature enhances an inner core feature. The “Features Get Tested Alike” pattern describes how to test similar features that are exposed via different interfaces to the user (e.g., through an API vs. the user interface). The “Standing on the Shoulders of Giants” pattern lays down design guidelines to optimally build reusable components that can be leveraged between feature teams testing large software products.
|
Vishal Chowdhary, Microsoft Corporation
|
|
|
The Power of the Crowd: Mobile Testing for Scale and Global Coverage Crowdsourced testing of mobile applications, a middle ground between in-house and outsourced testing, has many advantages: scale, speed, coverage, lower capital costs, reduced staffing costs, and no long-term commitments. However, crowdsourced testing of any application-mobile or not-should augment your professional testing resources, not replace them. Most importantly, crowdsourced testing has to be done well or it’s a waste of time and money. John Carpenter reviews the applications and ways he’s outsourced testing to the crowd. Focusing on adopting crowdsourcing for both functional and usability testing in mobile applications, John describes scenarios in which you can leverage the crowd to lower costs and increase product quality, including scaling the application to large populations of global users.
|
John Carpenter, Mob4Hire, Inc.
|
