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 have found useful for helping testers I have 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 is borrowed from Ford Motor Company.
Testing, also known as Quality Control, exists to implement an organization’s 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 to 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 organization’s 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 product’s features, 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 breathe data. They consume data and they create data.
Data provided from other teams is used to make intelligent decisions regarding:
-
- 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 the principle having to do with avoiding ambiguity, test teams must never make assumptions; 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
Innovations 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 does 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 in time of 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 or 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 it provides the highest ROI (Return on Investment).
Identify Priorities
Make “First Things First” (Steven Covey)
Unless you are absolutely clear on 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.
To see the original post:
https://www.linkedin.com/pulse/software-testing-guiding-principles-scott-acker?trk=prof-post