Why Estimate Testing If You Are Just Given A Box To Work Within?

Posted on May 9, 2010 by Trevor Atkins

Sharing an answer to a couple of recent customer queries in hopes that it is generally useful as well:

Often in discussing the value of estimating test efforts, a comment is made by someone that there is no point in doing so as they will be given only 2 weeks (or some other arbitrary number) for testing anyway.

In such a tightly constrained situation, it will frequently feel that there is no ability for the test team to control or even influence the situation – it is clear to everyone on the team that there is not enough time to do the job, but that is all the time there is, and so… Continue reading →

Posted in  All, Estimation for Testing, Test Planning & Strategy | Tagged , , , | Comments Off on Why Estimate Testing If You Are Just Given A Box To Work Within?

Designing an Effective (Agile) Smoke Test

Posted on February 9, 2010 by Trevor Atkins

Sharing an answer to a couple of recent customer queries in hopes that it is generally useful as well:

The ability to give early feedback during testing is a cornerstone to providing value on a software project. A well designed smoke test is one part of a strategy that can enable that feedback.

How do you determine what to put in your smoke test? First, ask what are the critical behaviours that need to be working. Then consider the types of changes that have occurred since the last test cycle and what you need to check to gain necessary confidence that these things and what they impact are in “working order”. Finally, prioritize which other areas of the system you need to review in more detail than others (eg: what would you do next if you had some extra time). Continue reading →

Posted in  All, Agile Testing, Test Planning & Strategy | Tagged , , | Comments Off on Designing an Effective (Agile) Smoke Test

Test Automation – Building Your Business Case

Posted on October 29, 2009 by Trevor Atkins

I presented “Test Automation – Building Your Business Case” to VANQ.org, the Vancouver Software Quality Assurance User Group. Subsequently I presented it to the Southern Idaho Society for Software Quality Assurance and UBC Continuing Studies (Tech.UBC.ca), and I wanted to share that material with you.

Many teams try to add automation to their projects only to end up frustrated, and annoyed. After one or two failed attempts, they often give up or no longer have the management support to keep trying. To help increase the chance for success, the approach to automation must be from a realistic perspective with a keen awareness that automating testing effectively is not easy.

We will discuss using the exercise of a creating business case as sanity check on where it is most effective to employ automated testing, a “tool assisted” test approach, or stick with manual testing.

You can download the slides here: Test Automation – Building Your Business Case

Posted in  All, Automation & Tools, Business of Testing, Planning for Quality | Tagged , , , , , | Comments Off on Test Automation – Building Your Business Case

Successfully Integrating Test Automation and Agile Projects

Posted on October 7, 2009 by Trevor Atkins

On Oct. 7, 2009, I presented “Successfully Integrating Test Automation and Agile Projects” to Annex Consulting Group CIO Breakfast, and I wanted to share that material with you.

To accelerate your project and specifically the testing of your releases, test automation is typically seen as a critical component. And in the case of Agile or agile-like projects, the requirement for automation is a key aspect of the methodology. However, it is quite common for a project team or an organization to attempt to automate testing one or more times and only gain mediocre results or be forced to abandon the effort all together. In this presentation, we will discuss some of the common goals and challenges of automation, how they translate to an Agile environment, and what can be done to increase the chances for creating an effective test automation solution for your project.

View the full presentation…

Posted in  All, Agile Testing, Automation & Tools, Planning for Quality, Test Planning & Strategy | Tagged , , , | Comments Off on Successfully Integrating Test Automation and Agile Projects

Involve Testing Throughout the SDLC

Posted on September 9, 2009 by Trevor Atkins

Too often a test team is employed only towards the end of a project cycle. This means the test team is not as fully leveraged as they could be and therefore the project is not reaching as high a quality bar as it should.

Silverpath works with our customers’ in-house project teams to integrate our adaptable approach of Thinking Through Testing™ which emphasizes the inclusion of testing activities early in the project lifecycle.

In the following presentation we will review some of the background to the value of this approach and the base principles of the approach itself.

View the full presentation…

Posted in  All, Planning for Quality, Test Planning & Strategy | Tagged , | Comments Off on Involve Testing Throughout the SDLC

Visibility of Value – Testing Within the Organization

Posted on May 9, 2009 by Trevor Atkins

Consider the last time the testing group was involved from the beginning of a project, had an influential voice in the development of the project plan, was able to hire for test planning, and was treated as a strategic competitive differentiator by the company.

Each of the aforementioned items is related to the organization’s perceived value of the testing group. Not only must the testing group be concerned with knowing and performing the activities of software testing to a high standard, but it must also understand how it should participate within the larger activities and priorities of the organization, making visible the value the testing group delivers in that regard.

Testing is typically a substantial portion of any software project, but it is still often an afterthought in many organizations where the testing group is an unequal stakeholder with respect to budget, resources and project planning.

While it is true that the degree of quality doesn’t directly impact market share, the lack of quality, competitively, will certainly have an adverse impact on reputation and revenues.

Investing in testing is expected to help to increase product quality, increase customer satisfaction, and improve the overall organizational profitability. Testing is part of a set of risk mitigation activities where the basic principle is to spend money wisely now in order to avoid greater costs later. Each organization and even each project must find the optimal mix of investment in upfront activities versus potential costs of inefficiency or failures later to minimize the Total Cost of Quality.

Perhaps the most important goal for a testing group within any organization is to move from the perception of being a cost center to being an effective and efficient cost-optimization center. This goal can be readily achieved through making visible the impact and value of the risk mitigation efforts of the testing group to the key stakeholders of each project and across the organization for review and improvement.

Read the full article…

Posted in  All, Business of Testing, Planning for Quality | Tagged , , , , | Comments Off on Visibility of Value – Testing Within the Organization

Metrics – Thinking In N-Dimensions

Posted on February 26, 2009 by Trevor Atkins

I presented “Metrics – Thinking in N-Dimensions” to VANQ.org, the Vancouver Software Quality Assurance User Group, and I wanted to share that material with you.

The biggest challenge in establishing an effective metrics programme is not the formulas, statistics, and complex analysis that are often associated with metrics.  Rather, the difficulty lies in determining which metrics provide valuable information to the project and/or organization and which do not, or worse may be misleading.

In this presentation, we will discuss a straightforward approach for looking at the multiple dimensions of choosing what metrics we should have to make certain decisions and how to get them.

You can download the slides here: Metrics – Thinking in N-Dimensions

Posted in  All, Planning for Quality, Test Planning & Strategy | Tagged , , , , , , | Comments Off on Metrics – Thinking In N-Dimensions

User Acceptance Testing – Finally, Some Validation?

Posted on February 9, 2009 by Trevor Atkins

User acceptance testing (UAT) is the one form of acceptance testing that must involve stakeholders outside of the project team; the users. UAT provides a formal means for validating that a new system actually meets the necessary user requirements from the users’ or customer’s perspective within the users’ environment (or as close as possible) before moving the system into production.

UAT is also another one-last-chance to screen for the issues not found and resolved during unit, integration, and system testing where the vast majority of the functional, error, and boundary tests are executed. Of course, when performing acceptance testing there is much more than functionality to evaluate.

However, the central purpose of UAT is to involve the users and business managers in an actual test cycle to help them to gain the necessary confidence that the system will meet their real world business needs.

It is generally understood that everything cannot be tested as well as it could be if time and money were no object. In the real world of project constraints and concerns of time-to-market, any testing effort needs a strategy that creates an appropriate balance between quality, budget, and schedule.

To accomplish this for user acceptance testing, the contextual challenges faced by the project in regard to this effort must be considered. Without due consideration for these challenges and the risks to the business they imply, the context of the user acceptance test cannot be fully understood. Without this understanding, an appropriate plan of action cannot be defined and agreed to early in the project cycle.

Read the full article…

Posted in  All, Planning for Quality, Test Planning & Strategy | Tagged , , , , | Comments Off on User Acceptance Testing – Finally, Some Validation?

Communicating Requirements To Testing – You’re Going To Be In Pictures!

Posted on November 9, 2008 by Trevor Atkins

How do you know what a system is supposed to do and what it is not supposed to do? Formal requirements are intended to create an easily validated, maintainable and comprehensive set of documents communicating the system’s planned functional scope in terms of tasks and behaviours.

It is well understood that a higher quality product demands a higher upfront investment. However, compromises regarding quality versus cost are made every day and tight project budgets and short timelines often greatly reduce the interest in formalized documentation, requirements or otherwise.

“The communication of functional requirements and specifications is the most difficult, critical, and error-prone task in IT projects. Research has shown that projects that proceed to the construction and coding phase with missing or wrong functional requirements and specifications are almost certain to fail.” – Bill Walton, A Systematic Approach for More Effective Communication of Functional Requirements and Specifications.

In the fast-paced changing world of software development there is a continuous challenge to communicate the expectations for the system and its internally and externally facing behaviours. Formal, documented requirements often suffer because of the challenges of keeping up with short iterative project life-cycles, continually evolving product scope and customer demands, and uncertain or changing screens and interfaces.

Without clearly stated requirements, testing, specifically, is unable to perform its job of both verifying that the system was implemented correctly and validating that the correct system was implemented.

A balanced approach that maximizes the contribution of the organization’s available resources within the project constraints is required. The following proven light-weight solution tailored to your timeframes and resource realities can allow testing to, in the absence of complete formal requirements, capture critical information about the system without slowing development. The resulting artifacts can also serve as a direct input into testing activities.

Read the full article…

Posted in  All, Agile Testing, Automation & Tools, Requirements & Testing, Test Planning & Strategy | Tagged , , , , , , | Comments Off on Communicating Requirements To Testing – You’re Going To Be In Pictures!

Capturing Wild Requirements for Testing

Posted on October 30, 2008 by Trevor Atkins

I presented “Capturing Wild Requirements – For Testing” to VANQ.org, the Vancouver Software Quality Assurance User Group, and I wanted to share that material with you. Later, I developed this material into a 1-day workshop “Requirements Ghostwriting: Filling in the Blanks“.

Compromises regarding quality versus cost are made every day, and tight project budgets and short timelines often greatly reduce the interest in formalized documentation, requirements or otherwise.

This presentation discusses how testing can easily create an validated, maintainable and comprehensive set of critical information describing the system’s planned functional scope of tasks and behaviours without slowing development. The resulting artifacts can be used to directly drive testing as well – avoiding significant duplication of effort and possible confusions.

You can download the slides here: Capturing Wild Requirements – For Testing

Posted in  All, Agile Testing, Automation & Tools, Requirements & Testing | Tagged , , , , , , | Comments Off on Capturing Wild Requirements for Testing