Having problems "selling" software QA/QC to your organization? Do people not understand the true value of QA/QC? If you say yes to these questions then you should attend this presentation. This presentation will show:

• What is Business Value from a Business Management Perspective
• The Business Management Catalyst for the Increased Value of Software Quality
• Selling QA/QC to Management: The Business Value of Software QA/QC

Everyone who works in the software QA/QC field should understand how QA/QC creates value and be able to communicate it. After attending this presentation you will be able to improve your ability to communicate the business value of software QA/QC to your organization.

The topic of Software Quality Management: Goals and Objectives, as described in the CSQE Body of Knowledge, comprises:

1. Quality Goals and Objectives
   Describe, analyze, and evaluate quality goals and objectives for programs, projects, and products. (Evaluation)
2. Outsourced Services
   Define, analyze, and evaluate the impact of acquisitions, subcontractor services, and other external resources on the organization's goals and objectives. (Evaluation)
3. Planning
   Identify, apply, and evaluate scheduling and resource requirements necessary to achieve quality goals and objectives. (Evaluation)
4. Software Quality Management (SQM) Systems Documentation
   Identify and describe various elements related to SQM system documentation. (Comprehension)
5. Customer Requirements
   Analyze and evaluate customer requirements and their effect on programs, projects, and products. (Evaluation)
   [NOTE: Changes in requirements are covered in III.B.3. The focus in this section is to ensure that customer requirements are evaluated properly.]

We all joke and complain a lot about what's wrong with our SQA environments. But what if you could set up a SQA environment any way you liked? What if you could design your own management structure, procedures, standards, physical environment, equipment setup, etc. any way you wanted without regard to cost, office politics, or any other factor?

We have so little encouragement to dream in this culture that most of us have forgotten how. As you ponder that perfect SQA environment, notice how often the "committee in your head" uses barrier words like "not, but, kind of, sort of, more of, less of, better, etc.". How often do we speak of what we don't want rather than what we do want? Hey, this is a vision - spell it out exactly the way you want it. For instance, in the perfect vision, we don't just get "less obscure" or "better" feedback from testers, we always get "timely, crystal clear reports."

As the quote below suggests, when you have a clear vision of where you want to go, it is much easier to get there. It's hard to believe until you've been there, but once we get a vision clear, it often seems to come true all by itself. We'll be taking a look at the mechanics behind that apparent magic.

This session will be highly interactive, so come prepared to participate in some fun and games with the serious goal of moving us all closer to that perfect SQA environment.

"You've got to have a dream. If you don't have a dream, how you going to have a dream come true?" - Song from South Pacific.

Mercury Interactive will review and discuss why many organizations (30,000 customers worldwide, and over 100 customers in Western Canada) have adopted automated software testing as a way to:

• improve the quality of their software applications
• reduce the number of defects identified
• increase the probability of success

Agile development techniques and their benefits have been widely publicized in the software development world in the last 18 months. Many organizations are now looking at agile approaches, drawn by the claims of improved productivity, higher quality, better ROI and greater customer satisfaction. However many of the "emergent", "light-weight" techniques advocated in agile methods appear contrary to the traditional "plan-based" project management best practices.

Mike Griffiths will provide an overview of agile development techniques from a project management perspective and examine the project circumstances that favour an agile approach. The presentation will make the case that many types of software development projects are sufficiently different from physical engineering based projects that construction inspired project controls are not the most appropriate means for management. Mike will then compare and contrasts elements of the PMBOK against the principles of agile development and suggests alternatives to the traditional project planning, execution and tracking techniques. The explanation of these approaches will be backed up by accounts of their practical use on software development projects and will form the basis for discussion items.

Agile methods have been typically associated with software development. However, considerable growth and maturity of the commercial application marketplace has prompted many organizations to adopt the policy of "package first, custom development second" in fulfilling business application needs. Fitting these commercial systems to customer requirements remains problematic.

Bob Faught will provide an overview of a case study whereby Agile techniques were adapted for package selection and integration of a mission critical system involving multiple business units and stakeholders. The end result was delivery of a quality product that met customer expectations using the values of the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

In this presentation we will explore how the basic elements of Agile methods were adapted to the application solution decision process. We will examine how Agile techniques were applied to discovery, evaluation, selection, configuration and pilot testing.

As we move forward in the commercial software arena with the evolution of component-based software engineering, Agile methods will play an increasing role in selection and adoption of solutions that fit customer use patterns.

What a great opportunity to meet with fellow quality practitioners to partake of some fine vituals, hoist a few and talk about software quality, amongst other things, I'm certain.

We're meeting at the Auburn Saloon this year, a slight change in ambience from our previous outings. This is the new location of the Auburn, on the south side of 9th Avenue, on the west side of the Palliser Square office tower, directly across from the Glenbow Museum.

As always, this is an informal affair. We can start congregating around 5:30 pm and wrap up any time we want. Hors d'oeuvres will be served starting shortly after 6:00.

The success of any software project starts with a sound plan. The software industry has a long history of late delivery and overspent projects. Interestingly enough, very few companies keep this history in a retrievable form. As a result, each project starts without the learnings of the previous. This presentation will first outline the benefit of having history information available for project estimation, describe the inherent complexity of estimating medium to large software projects and then demonstrate a tool that assists in developing estimates. At the conclusion of this presentation, the attendees will discover that software projects are really similar in nature and that a little math with some industry history information can go a long way to developing credible defensible estimates.

Although new tools, technologies, ideas and practices continue to advance the state of the art, the big question for all practitioners is which of these advances will actually turn out to be useful. Sure, some like Extreme Programming style unit testing seem to have a secure future, but so did cleanroom software development. The future of code walkthroughs and design reviews seemed certain, but they never became a mainstream practice.

So what makes some advances stick and makes others disappear seemingly without trace? How we can influence the advances that survive? Are there any obvious things that we are missing? What advances should we be promoting? What should software quality look like in 10 years time? How about in 20 years time?

The topic of Software Testing, as described in the CSQE Body of Knowledge, comprises:

1. Test planning and design
   • Types of tests
     Select, apply, and develop various types of test, including functional, performance, regression, certification, environmental load, stress, worst case, perfective, exploratory, etc. (Synthesis)
   • Test tools
     Define and describe the application and capabilities of commonly used test tools such as acceptance test suites, utilities (for memory, screen capture, string-finding, file viewer, file comparison, etc.), and diagnostics (for hardware, software, configuration, etc.). (Comprehension)
   • Test strategies
     Identify, analyze, and apply various test strategies, including top-down, bottom-up, black-box, white-box, simulation, automation, etc. (Synthesis)
   • Test design
     Identify, describe, and apply various types of test design including fault insertion, fault-error handling, equivalence class partitioning, boundary value, etc. (Application)
   • Test coverage of specifications
     Identify, apply, and develop various test coverage specifications, including functions, states, data and time domains, etc. (Synthesis)
   • Test environments
     Identify various environments and use tools such as test libraries, drivers, stubs, harnesses, etc., in those environments, and describe how simulations can be used in test environments. (Synthesis)
   • Supplier components and products
     Identify the common risks and benefits of incorporating purchased software into other software products. Use various methods to test supplier components and products in the larger system. (Application)
     
   • Test plans
     Identify, describe, and apply methods for creating and evaluating test plans including system, acceptance, validation, etc., to determine whether project objectives are being met. (Application)
2. Test execution and evaluation
   • Test implementation
     Define, describe, and use various implementation elements, including scheduling, freezing, dependencies, V-model, error repair models, acceptance testing, etc. (Application)
   • Test documentation
     Define, describe, and use various documentation procedures, including defect recording and tracking, test report completion metrics, trouble reports, input/output specifications, etc. (Application)
   • Test Reviews
     Describe, develop, and analyze various methods of reviewing test efforts, including technical accomplishments, future planning, risk management, etc. (Synthesis)
   • Code coverage metrics
     Define and apply various metrics including branch-to-branch, condition, domain, McCabe's cyclomatic complexity, boundary, etc. (Application)
   • Customer deliverables
     Identify and select various methods for testing the accuracy of customer deliverables, including packaged or downloaded products, license keys, user documentation, marketing and training materials, etc. (Synthesis)
   • Severity of anomalies
     Identify and select various methods for evaluating severity of anomalies in software operations. (Evaluation)

This will be a facilitated discussion instead of a straight-up presentation. Come prepared to participate, contribute and learn.

As applications have become a more crucial and integral part of everyday business, it has also become more important for these applications to perform at the utmost optimization and economic value.

Applications are also becoming more and more complex and complicated to maintain. IT organizations are being asked to manage these applications, implement solutions, and in some cases develop and customize them. With the mounting pressure and expectations being placed on IT departments to deliver these applications they are often facing shrinking budgets, cuts in human and physical resources.

So how does a Company accomplish this daunting task with increased limitations? The season?s new buzzwords appear. Proactive monitoring, SLA's, baselines, trend analysis, more with less. In the IT world, Application Performance Management is the new black.

As applications and development architectures become more distributed and extensive, there has been a growing need to ensure quality checks are put into process in the early stages of software development. This is no easy task.

Historically the quality process has begun much later in the software development lifecycle. Part of the problem has emerged due to the fact that within most application project guidelines, the development phase has rarely been given much project budget and time to spend on the importance of testing the applications unit functions. Furthermore, the tasks associated within the development and code creation stage are not normally structured to fit well within the quality team?s objective of ensuring proper test coverage. The answer to this problem is that development teams need a solution that does not impede the application creating time, but is integrated into the development cycle to facilitate quality.

Chris will discuss key concepts that assist in integrating the quality process into the development life cycle and provide development and quality teams the ability to ensure the highest level of software test coverage. Some of the areas to be addressed include:

• Software quality from the development perspective
• Considerations of when to start testing
• Techniques and tools for testing within the development environment
• The developers roles in testing
• Facilitating communication between testing and development teams
• Code coverage — achieving 100%, is it possible and how can I tell?
• Application performance — where to start measuring and collection metrics

The Sarbanes-Oxley Act of 2002 was created to restore investor confidence in the public markets. The Act requires management to establish and maintain internal control - and requires the independent auditors to evaluate.

Preparing for compliance is a significant task. Processes need to be identified and controls need to be documented/tested. Current auditor rules require consideration of "IT". Auditors and management are required to document and assess the effectiveness of IT controls over the financial reporting process.

With the dependence on IT for reliable financial reporting processes, IT plays a key role in compliance with Sarbanes-Oxley. Companies should ensure IT has an active role in compliance efforts.

This presentation will explore how privacy laws affect the Canadian software industry.

All organizations in Canada, regardless of size, are subject to privacy legislation. The privacy laws in Canada (and beyond) impose significant restrictions on collecting, using, and disclosing personal information, and require that it be adequately safeguarded, including from unauthorized access within an organization. Non-compliance may result in fines of up to 100,000 per incident, lawsuits, and reputation damage.

IT systems developers, project managers, consultants and auditors now have to consider privacy implications when developing, implementing, or reviewing systems. Independent consulting developers have to be aware of how the privacy laws affect them.

This session will review the Fair Information Practices that the privacy legislation incorporates, discuss their implications for IT security and audit, and provide some practical guidelines to minimize the risk of non-compliance.

Due to the nature of acceptance tests, a number of difficulties may be experienced when automating them that may not be experienced when automating unit tests for the same system.

Direct customer involvement is crucial to the acceptance testing process. It also raises the bar for the usability of automated testing frameworks to ensure the customers can read and potentially write the automated test themselves. There are additional implications for test management, including: maintaining synchronization between the customer test specifications and the automated tests, and maintaining the tests as the user interface and/or workflow evolve over time.

Poor performance of an automated acceptance test suite is often an issue because the tests typically operate on the user interface, and involve all of the application layers and other integrated components. Stubbing out a problematic component is a common solution to performance problems, but unless the application was originally designed for testability, selective stubbing is often impossible.Test data management is another area rife with difficulties.

Acceptance tests are automated to accelerate and standardize regression testing. The key to achieving reliable and repeatable regression tests is the use of unique test-specific data rather than real production data. If the application has not been designed for testability, it is often difficult to create the test data, or to control the execution environment in order to create a specific event.

This presentation will cover:

• Overview of how a particular project overcame the above difficulties, and developed an innovative acceptance testing strategy: generating the code to automate acceptance tests that are specified in a declarative tabular format.
• Discussion of other cases where this approach may be appropriate.
• Discussion of other war stories about difficult-to-test situations, and solutions devised to overcome the barriers.

This is our annual planning session where organizers, volunteers and participants, active or otherwise, get a chance to make their mark on next years sessions. Everything is up for discussion. Bring your ideas and suggestions to make this an even better discussion group next year.

A reprise of our annual planning session where organizers, volunteers and participants, active or otherwise, get a chance to make their mark on next years sessions. Everything is up for discussion. Bring your ideas and suggestions to make this an even better discussion group next year.

Please note that this is a lunch meeting at the Auburn Saloon, downtown, and not the usual Devry venue or time.