program selection system

Getting Selenium Core up and running is fairly easy. Making it hum in a real-world XP/Agile project requires experience and a heap of tips and tricks. In this tutorial, participants will learn from our hard-earned experience in the trenches, and see code and tests from Industrial Logic’s shipping product. I will describe specific Selenium problems we’ve encountered, technique(s) we employed to solve those problems and what our final test scripts looked like.

In Part I of this tutorial, I’ll cover such issues as:

Domain Specific Testing Languages (DSTLs) express customer requirements as tests with the scope, granularity, and transparency you need. Dynamically extensible DSTLs help you keep the core testing tool simple while creating automated test scripts the customer can easily read, verify, and use as requirements documents. In this session, you’ll get practical tips to foster test code re-use and reduce test maintenance costs, especially on large and long-running projects.

Narrative Testing leverages script-based testing tools and DSTLs to express Story Tests in the user’s own language. Developers and customers cooperate to create customer-readable scripts based on User Stories, which are executed interactively against the application UI. Through Narrative Testing, customers are able to view the executing test, and to experientially tie steps in the test to changes in the application state, increasing customer confidence in testing.

Getting a build system right can set the tone of development for years, and yet teams constantly re-invent wheel over and over. The application of a few key tools, such as Maven and Continuum in a sane ecosystem can provide a solid base for project growth and developer sanity, and can encourage the mature use of Agile practices and processes. Well designed automation of building, testing, and reporting can provide invaluable developer ease and fast feedback to developers and and other stakeholders.

Organizational change is hard, and often teams attempt to implement Agile practices and processes without management support. While a key factor in the success of Agile efforts is adequate process support from senior levels, often agile practices and processes can be used at the grass roots level to improve the culture, which can lead to management buy-in.

Abstract

Performance testing our applications is either neglected or we use expensive and time consuming to learn commercial tools that often produce so many metrics and raw data that it can be difficult to derive meaningful information to improve application performance. What can agile teach us about doing performance analysis? This talk provides an overview of available open source performance testing tools and discusses minimalistic approaches to testing web sites and web services using tools including JMeter, Grinder, WebTest, SoapUI and a Groovy DSL.

Agile Planner for digital tabletop (APDT) is an agile planning tool supporting collocated and distributed agile planning meetings. Utilizing digital tabletop technology, APDT supports group interactions and natural behavior of agile meeting attendees. APDT connects tabletops at different locations, creating a virtual-collocated platform that integrates distributed agile teams into a shared meeting scenario. APDT is a novel planning tool that addresses communication problems found in distributed agile planning meetings.

Agile developers love — and some actually need — to be in a state of flow. For them fast feedback from unit tests and continuous integration tools is not an option. In practice, fast unit tests often lack in coverage and many valuable tests run slow. This may be due to legacy code or the nature of the tests or just the sheer size of the application. Whatever the reason, getting feedback many hours after they submitted the code and the mental model has been blurred is a major impediment to developer’s productivity. To mitigate these issues a variety of strategies and tools have emerged.

With Continuous Integration, the chances rise exponentially with team size that as you fix a build or test problem, the integration of somebody else’s work creates a new build or test problem. Multi Stage CI addresses this problem by extending the practice of temporary individual isolation to features, teams, staging, QA, and release. This demonstration will show how Multi-Stage Continuous Integration works in the real world by drawing on the experiences of three large distributed teams. See changes by hundreds of simulated developers make their way through the system.

In 2007 Kelley Blue Book (KBB) decided to move to a more robust tool to promote agility while keeping up with increasingly challenging product release plans. KBB chose VersionOne to replace SharePoint as the enterprise Scrum Tool. With KBB sharing their experience of this common situation, other companies can learn about and adopt proven techniques to ensure a successful tool migration. This paper will cover KBB’s Scrum implementation, goals of tool migration, the selection process, migration approach, and results.