Solutions Workshop Notes for Building Effective Measurement Solutions
Facilitator: Molly Byer
Co-Facilitators: Bob Crews and Shalla Hyderi Goyal
TOPIC 1 - TOOL SELECTION
How do I select the "right" tool? Is there a checklist or set of evaluation criteria?
- Perform a Proof of Concept as a part of tool selection.
- Create unique requirements for the proof of concept - Set up to 10 scenarios for the vendor to prove they can setup and check if they can do it satisfactorily. During that process, change the requirements and see how they are handled.
- Know the future technology roadmap of the company.
- Make sure that the tool is scalable. Get a list of Must Have's vs. Nice To Have.
- Look into the support agreements from vendor including tech support.
- Validate that the data/template are compatible across vendors and adhere to industry standards for long term maintenance.
- Find if different kinds of data can be used. Ask the vendor what platform they support.
- Check if there is any available freeware to gain additional opportunities. List all tools and select the one that matches close to your needs.
- Staffing and usability of tool - Weigh in and get feedback if the testers are comfortable using the tool.
- Look to see if a common tool set can be setup ie. If it can address load test, UI test, performance test etc.
- Know the language, or nearest equivalent, that the tool uses, such as C or VBScript.
Back to Top
TOPIC 2 - AGILE
What are the suggestions on the best approach to maintain automation scripts (artifacts) in an agile environment?
- Most of the (Happy path + negative path) regression testing can be automated in agile. Look for low hanging fruits.
- Keep it small and simple.
- Use modular approach. Identify repetitive modules used across build.
- Prioritize the test cases. 60% development is okay during early phases and don't have to be 100% to attain quick efficiencies and avoid rework. The testing during the early phases can be addressed with appropriate level of automated in conjunction with the manual testing.
- Present Return on Investment. Find if the automation is feasible for the phase as the project evolves.
- Automation scripts have to find some defects to show benefits.
Back to Top
TOPIC 3 - MAINTENANCE
How do you plan for and manage the high cost of maintenance in test automation?
- Use Regular Expressions/ functions for objects if these objects are expected to change. ( QTP 9.5 can generate RegEx pattern matching strings automatically in Maintenance Run mode.)
- Use Descriptive Programming to develop Object oriented test scripts, and not based on mouse/keyboard clicks/screen locations.
- Breakdown scripts into functional modules.
- In QTP, don't attempt a single script library full of Actions. Drive towards one reusable action/one script, and include a non-reusable unit test action.
- Parameterize values to keep hard coded data out of scripts and increase scalability.
- Identify automation test data with additional characters so that test data is not "stepped on" by other manual testers. If possible, create test scripts that, as a prerequisite, generate their own test data.
- Tighter Change management, especially in an agile environment.
- Ask your developers to uniquely name each object, and to define which property will be used for each object type.
Back to Top
TOPIC 4 - VALUE
How do you realize rapid and continued value in test automation? What specific measures/metrics have proven successful in showing value and how do you collect data and calculate?
- Look for risk exposure from the business point of view to assess value.
- Record times when you were able to identify a problem which would not have been found otherwise or the probability of finding that would have been low. Convert the value to cost if that defect had made it to production there by increasing the overall cost of quality.
- Also recognize the times when testing could not have been completed by just manual testing based on time constraints.
- Get metrics to present cost estimates.
- Avoid tracking 'Number of Defects Found' and 'Number of Test Cases Passed'. Focus on 'Defect Severity' as well as 'Hours of Execution Time' multiplied by an average billing rate. Factor in overtime pay if tests run over 8 consecutive hours in a day, or over 40 hours in a seven day week.
Back to Top
TOPIC 5- ORGANIZATION ADOPTION
What steps should be taken to ensure organization adoption and education at individual/teams/management levels?
- Assumption: Management buy-in complete for automation effort. Tool has been identified. Identified stakeholders from different areas of the organization and identified their expectations based on the importance.
- Demonstrate a sample of automation along with their benefits to the identified stakeholders.
- Educate and create awareness of the benefits of automation to the organization to gain support. Few activities could to be quantify the power of automation in terms of output size pre-automation and post-automation, early defect identification benefits etc.
- Ability of automation to address more scenarios for regression purpose leading to less stress on workers. Leads to a culture where work life balance is enhanced.
- Get co-worker's buy-in by automating the tedious time-consuming tests. In addition, automate any time consuming prerequisite steps.
- Get developer's buy-in by initially repeating subtle defects manually on a system without the automation tool installed. Ask for their input in automation code reviews. Ask them what areas could be tested deeper. Ask if they have considered automated unit testing.
- Maintain Management buy-in in terms of revenue: Potential cost to the company for each defect identified, cost equivalent of automated testing performed manually to identify defects, as well as increased testing depth and scope.
- Identify a team member who is comfortable with public speaking to present your progress. Join a speaking group such as Toastmasters, if necessary.
Back to Top
TOPIC 6 - CHANGING REQUIREMENTS
What are the recommendations on when to start automation when requirements are still evolving? What should be the first steps?
- Identify more stable requirements vs dynamic requirements. Go with stable requirements first and also get better insight to the nature of the dynamic change. Overall, understand that planning is an integral part of automation effort.
- Determine features of automation tools which assist in rapidly revising scripts (ie QTP has descriptive programming), however, the issue is this requires appropriate skill set.
- Identify areas that can be automated and can be reused though requirements are still changing. This can be done by creating framework in modular fashion.
- Involve QA in requirement process to gain better insight. Also peer review test plans to gather feedback from other groups.
Back to Top
Workshops & Panel: Test Management | Measurement | Solutions Workshop
Agile Panel Discussion [Cox] [Rinko-Gay]