All effective test teams typically have well defined processes, appropriate tools and resources with a variety of skills. However, teams cannot be successful if they place 100% dependency on the documented processes, as doing so leads to conflicts. Especially when testers use these processes as ‘shields’ or ‘crutches’.
To be successful, test teams need to leverage their processes as tools towards becoming “IT” teams. And by “IT” I do not mean Internet Technology.
IT (Intelligent Testing) teams apply guiding
principles to ensure that the most cost effective
test solution is provided at all times
This posting provides a look into the “guiding principles” I’ve found useful at helping testers I’ve worked with to become highly effective and valued as part of a product development organization.
Attitude is Everything
The success you experience as a tester depends 100% on your attitude.
A non-collaborative attitude will lead to
conflict, limit the success of the test team and
ultimately undermine the success of the
entire organization.
Testers must:
- Learn to recognize challenges being faced by the team and to work collaboratively to solve problems
- As stated by Steve Covey – “Think Win-Win“
- Lead by example and inspire others. A collaborative attitude will pay dividends and improve the working relationship for the entire organization, especially when the team is stressed and under pressure.
Quality is Job # 1
This one borrowed from Ford Motor Company.
Testing, also known as Quality Control, exists to implement an organizations Quality Assurance Program. As such, testers are seen as the “last line of defense” and play a vital role in the success of the business.
Poor quality leads to unhappy customers and eventually the loss of those customers, which then adversely impacts business revenue.
Testers are ultimately focused on ensuring the
positive experience of the customer using the
product or service.
Communication is King
Testers should strive to be superior communicators, as ineffective communications leads to confusion and reflects poorly on the entire team.
The test team will be judged by the quality of their work, which comes in the form of:
- Test Plans
- Test Cases
- Defect Reports
- Status Reports
- Emails
- Presentations
Learn how to communicate clearly, concisely
and completely.
Know Your Customer
Like it, or not, testing is ‘service based’ and delivers services related to the organizations Quality Assurance Program. For example: test planning, preparation and execution services on behalf of an R&D team (i.e. internal customer).
Understanding the needs and priorities of the
internal customer will help to ensure a positive
and successful test engagement.
Test Engineering also represents the external customer (i.e. user of the product / service being developed). Understanding the external customer will help to improve the quality of the testing and, ultimately, quality of the product.
Without understanding the external customer
it is not possible to effectively plan and implement
a cost effective testing program.
Ambiguity is Our Enemy
This basically means “Never Assume” and clarify whenever there is uncertainty.
Making assumptions about how a products features / functionality, schedules, etc function will lead to a variety of issues:
- Missed expectations
- Test escapes – Customer Reported Defects
- Reflect poorly on the professionalism of the Test Engineering team
Testers must avoid ambiguity in the documentation that they create so as to not confuse others.
Data! Data! Data!
Test teams ‘live and breath’ data. They consume data and they create data.
Data provided from other teams is used to make intelligent decisions:
- Requirements
- Specifications
- Schemas
- Schedules
- Etc
Data generated by the test program is used to assist with making decisions on the quality of the product:
- Requirements coverage
- Testing progress
- Defect status
- Defect arrival / closure rates
The fidelity and timeliness of the data collected
is critical to the success of the entire
organization.
Trust Facts – Question Assumptions
Related to principle having to do with avoiding ambiguity, test teams must never make assumptions. As doing so can have a significant impact on the entire business.
Testers must:
- Work with the cross-functional team to address issues with requirements, user stories, etc
- Clarify schedules / expectations when in doubt
- Leverage test documentation (e.g. Test Plan) to articulate and set expectations with respect to the test program
- Track / manage outstanding issues until they are resolved
Be as ‘surgical’ as necessary to ensure quality
issues are not propagated to later phases of
the product life-cycle
Think Innovation
Regardless of the role you play, every member of the test team can make a difference.
- Improvement ideas should be socialized, shared and investigated
- Small changes can make a huge difference to the team and the organization
Innovation that can benefit the Test or Quality Assurance Program are always welcome.
- Tweaks to processes, templates, workflows
- Enhancements to tools
- Advancements in automation techniques, tools, etc
Remember, the team is always looking for ways to increase effectiveness and make the most out of the limited Test Engineering budget
Strive to be “Solution Oriented”
Process for Structure – Not Restrictions
Some will say “What do you mean process do not restrict”. On the surface it may appear as if process does in fact restrict the team; however, if you dig deeper you will discover that documented processes help by:
- Improving communications through establishing consistency between deliverables and interactions between teams
- Making it clear to all ‘stakeholders’ what to expect at any given point of time in the product life-cycle
- Providing tools that can be used to train new members of the team
Documented process are not intended to limit
creativity. If the process is not working –
Change the Process
- Augment existing templates if it will enhance the value of the testing program; however, be sure to follow appropriate Change Management processes when introducing an update that may impact large numbers of people.
- Document and obtain approvals for deviations/exceptions if the value of completing certain aspects of the process has been assessed as non-essential for a program / project.
Plan Wisely
A well thought out and documented plan is worth its weight in gold. The documented plan is the primary tool used to set expectations by all the stakeholders.
“If you fail to plan you plan to fail”
Plan as if the money you are spending is your own. There is a limited budget for testing and it is your responsibility to ensure the effectiveness of the Test Program such that is provides the highest ROI (Return on Investment).
Identify Priorities
Make “First Things First” (Steven Covey)
Unless you are absolutely clear on the the priorities it will not be possible to effectively plan and / or execute a successful Test Program.
It is not possible for an individual, or team, to have two number one priorities. Although it is possible to make progress on multiple initiatives it is not possible for an individual to complete multiple initiatives at the exact same time. Schedules, milestones, capacity plans, etc should all reflect the priorities.
Always ensure priorities are in alignment with
the expectations of all stakeholders
At the end of the day the most important Software Test Principle is “If you do not know – ASK”. Testers are expected to ask questions until they are confident that they have the information needed to effectively plan, prepare and execute an effective Test Program.
Just remember, unanswered questions contribute to ambiguity and add risk to the business.
