Charters help you guide and focus exploratory testing. Well-formed charters help testers find defects that matter and provide vital information to stakeholders about the quality and state of the software under test. Rob Sabourin shares his experiences defining different exploratory testing charters for a diverse group of test projects. For example, reconnaissance charters focus on discovering application features, functions, and capabilities; failure mode charters explore what happens to applications when something goes wrong. In addition, you can base charters on what systems do for users, what users do with systems, or simply the requirements, design, or code. Rob reviews key elements of a well-formed testing charter-its mission, purpose, focus, understanding, and scope. Learn how to evolve a test idea into an exploratory charter using examples from systems testing, Scrum story testing, and developer unit testing.
As a professional test manager or test engineer, you must keep up with the latest test techniques, management practices, and systems technologies. But that is not enough. You also must interact with-and more importantly learn to influence-executive managers and other non-technical project stakeholders. Even today in many companies, testing and test management are not well understood and are under-appreciated by non-technical people. Now is the time for you to take action and do more than simply "get along" in your organization. Join Robert Sabourin for a lively session on developing your interpersonal skills, including the skills of communication, persuasion, problem solving, and teamwork. Discover new ways to work harmoniously with non-technical people while efficiently and effectively getting your important testing job done.
Change, ambiguity, and risk are key issues whether you are running a software project, managing a development team, or leading an entire organization. We learn it over and over again. It's not a matter of "if" change will happen-it's a matter of "when." When a crisis inevitably arrives, how do you respond? As Jerry Weinberg observed in The Secrets of Consulting, "It may look like a crisis, but it's only the end of an illusion." Andy Kaufman looks at key project illusions that threaten success as we lead projects and people in the realm of software development. Whether you're a project team member or a senior executive, Andy provides practical tips you can immediately apply in your organization.
Andy Kaufman, Institute for Leadership Excellence and Development
You've heard of eXtreme Programming (XP) and perhaps Scrum. How about Crystal Clear, Adaptive Software Development, Dynamic Systems Development Method, Rational Unified Process for Agile Development, and Feature Driven Development? These are some of the many variations of Agile development methods. Join Jeff McKenna as he explores the many flavors of Agile development methods and explains the similarities and differences. Find out what aspects of Agile development can help your organization’s development team in its particular environment. If you are considering Agile development and need to decide in which direction to go, this session is for you. Although a one-hour session cannot provide all the information you will need, you can explore what is common-the philosophy, the values, the characteristics-and what is different-the methods, the coverage, the costs-about different Agile approaches.
Many organizations have adopted, or are in the process of adopting, the Unified Process (UP) and, in particular, the Rational Unified Process (RUP). The test process defined within UP/RUP differs from more traditional, structured testing processes such as TMap (Test Management Approach) in Europe and STEP™ (Systematic Test and Evaluation Process) in the US. Tim Koomen, who has operated within these and other development lifecycle and test processes,
describes testing as defined in UP/RUP, maps the processes to those in TMap, and combines them into a "best of both worlds" approach. Learn about the UP/RUP defined practices such as the risk based test strategy, testability, test design, the role of the tester, independent testing,
"QA is the bottleneck” ... "Why does QA take so long?" ... "You need to test faster." Often, key project stakeholders either do not understand QA or have difficulty quantifying the effects that increasing or decreasing test time will have on the project. First American CREDCO found the solution was to turn QA into a full service organization, complete with a "Quality Rainbow" menu of options to be purchased. Want it quicker and willing to accept a higher risk? Then select from Column 1. Want low risk and willing to take the time to ensure the product is pristine? Then select from Column 5. Whether your test team is small or large, you can learn to "in-source" QA services, set time and efforts expectations up front, and measure the value of QA activities so that QA does not become a roadblock to project success.
A method to specify and quantify the services provided by a QA group
Using open source tools in a development and test environment can be a big relief for your budget. However, open source remains a foreign and often frightening concept for many developers and organizations. Today, open source options are available for all types of tools used in the development process. In this session, you will gain a better understanding of the tradeoffs between choosing open source and commercial tools. In addition, you will learn about the wide variety of open source tools available for many operating environments and how to locate the most robust ones. Danny Faught, who has actively evaluated open source tools as they have evolved over the last five years, provides an honest analysis of the benefits and difficulties you may encounter using these tools for development.
Open source tools to consider for you and your team
Design and architecture decisions made early in the project have a profound influence on the testability of an application. Although testing is a necessary and integral part of application development, architecture and design considerations rarely include the impacts of development design decisions on testability. In addition, build vs. buy, third party controls, open source vs. proprietary, and other similar questions can affect greatly the ability of an organization to carry out automated functional and performance testing-both positively and negatively. If the software or service is delivered to a separate set of end-users who then need to perform testing activities, the problems compound. Join Jay Weiser to find out about the important design and architecture decisions that will ensure more efficient and effective testability of your applications.
Managing system performance and reliability has never been as significantx0151or as challengingx0151as it is now. These days, most organizations have multi-technology, multi-vendor, multi-tier environments. In other words, it’s a world rife with 24-hour, alwaysx0151on complexity. Add to this the need for continual changes to react to shifts in business conditions, technology advances, and mixes of demands and you have a recipe that calls for the highest level of performance and reliability possible. But getting there is next to impossible. However, new concepts emerging from research labs are delivering usable products such as flexible computing, autonomous computing, and self-tuning systems. These possibilities have revolutionary potential for performance management.
Examine recommended suites of tools and their limitations
Look at the major innovations and trends, such as self-tuning systems
Taking a test team from a client/server environment to J2EE-based Web technologies and implementing test automation at the same time is a challenge. Introducing an agile test methodology into a traditionally waterfall-oriented organization at the same time is even bigger. In this case study, share Clay Coleman's successes and challenges as he mentored and supported a test group throughout this project. Walk with Clay from the days of early analysis and design; through test strategy development and planning; on to test case design and automation efforts; during all stages of test execution; past system rollout; and, finally, completion of an initial regression test suite. If you think you may go through such an experience, you'll learn some lessons Clay will never forget.
Integrate test automation into the construction phase of a development project