Skip to content

Latest commit

 

History

History
102 lines (72 loc) · 7.97 KB

H01-Why-do-we-need-this-tool.md

File metadata and controls

102 lines (72 loc) · 7.97 KB
Raw

H1 Why do we need this tool?

◄ Go back

Theme: WHY?

Quick start:

  • Heuristic Question: Why do we need this tool?
  • Why the tool is needed, what goals it supports, and what goals it doesn't support.
  • What problem the tool is intended to solve, and if a tool is the best option for solving the problem.
  • Why is this heuristic useful? We found nearly a third of comments made about challenges with implementing tools successfully were management and organizational in origin, and were often about conflicting goals across the organization. A mutual understanding across stakeholders of why the tool is needed, what goals it supports, and importantly what goals it doesn't - or cannot - support is vital.
  • Quality in Use Attributes: Freedom from Risk
  • Product Quality Attributes: User goals, Appropriateness
  • Mapping Heuristics to Quality Attributes

Explanation and sub-questions

Click for further explanation

You've embarked on designing, building, or choosing a new tool to help support testing.
Think about:

  • what problem the tool is intended to solve, and whether a tool is the best option for solving that problem.
  • the people who are testing and the organization, and how their (different) goals need supporting.
  • enablers and blockers to meeting those goals.
  • both the testers and the organization have motivations to adopt or to resist a new tool, and these may be the same or may conflict.

If you are tool designer or vendor, especially if you will not use the tool yourselves, you also ask this question as: ``Why do they need this tool?'' They might be different users, different customers, and other stakeholders.

Also ask ``Why else?''

Key questions to ask yourself:

  • Is there a problem to solve?
  • Is it organizational or technical or something else?
  • Can you design to increase productivity?
  • Can you design to reduce risk and increase value?
  • Can you design to improve the reach and certainty of people’s work?
  • Will this tool support what we are doing/want to achieve?
  • Does use of this tool cause any breach of ethical goals?
  • What is missing from the existing toolset?
  • Why does the tester need the tool?
  • Why does the organization want the tool?
  • Are there contradicting goals from different parts of the organization?
  • What happens if (part of) the tool is not used?
  • Should we use the tool at all?
Research Points and Quotes

Research Point: In the research leading to the design of these heuristics, we found there are often conflicting goals and expectations for the tools, and different perceptions of what problems needed resolving to enable improvement in working practices. Conflicting or unclear goals mean tool acquisition may be done in a short-term mindset. Tools may not even be the solution to the problem you are trying to address.

``There may be several organizations - even within one organization - with conflicting goals for the same tool [example given of password control tool] Audit versus Dev may have different views about how that might be used''

``muddling through - don't have a goal ... just want to do things ... get things done''

``change always comes with some resistance, Discussing and setting a clear, shared goal we got a better understanding and purpose to find energy and time and money to finish the transition''

`` I would suggest we stop seeing tools as our main goal that will save us, or do the job for us''

mini usage case: sometimes asking Why? is hard...

In one usage, the heuristics started to be introduced late and the participant identified that asking H01 Why? can be difficult as it might force a change of mind set or a change of direction, by acknowledging different people will have different goals. While that could be exactly what is needed, it is also difficult to do because people are reluctant to change: 'In later stages, however, this question may need to be adapted. Once discussions shift toward solutions, it can be challenging to steer back to the broader "why." Different personas appear at different stages with a unique perspective on the purpose of the tool. For instance, the buyer persona’s "why" may differ significantly from that of the tool's end users. To fully understand why the tool is needed, it’s essential to ask about challenges and goals from multiple stakeholders.' In this scenario, the participant decided to go with the Why? and Which tool? decisions as they were in place, and use the heuristics to guide their own work in planning future workshops.

Activities, tools and techniques to help answer the questions

Back to Top

Click for activities

How will you go about answering heuristic question H01? To understand why you are building the tool, you need to consider goals for different stakeholders – including yourself.

You will need to iterate between H01 “Why?” and H02 “Who?” as you identify stakeholders and their goals.

We have tabulated the Quality in Use and Product Quality Attributes in a priority order based on the input from industry practitioners during our research. Use that data to help you focus on the optimal product attributes to meet the QiU/UX goals for your tool. We've included quotes from practitioners that you can use to help you understand your own goals, stakeholders, and contexts, plus a cross reference between the heuristics and the quality attributes.

There are many activities you might find useful to help you understand Why you need this tool and here are some links to typical activities, which include:

  • SWOT analysis

  • Gap Analysis helps understand what is missing and what's needed to get where we want to be: See Wikipedia Gap Analysis page for an overview, and Techtarget have a page on Gap Analysis

  • Contextual Inquiry is the study of people working in context to understand what they do and why. See Wikipedia Contextual Inquiry page for an overview, and Think Design have a page on Contextual Inquiry

  • Make an initial business case for the tool, including a ROI calculation, for one example see the Test Automation Patterns wiki on Test Automation Business Case.

    • You may find it useful to consider your budget and a return on investment (ROI) calculation at this point, and include whether the costs will be treated as Capital Expenditure (CapEx) or Operational Expenditure (OpEx) as stakeholders may require specific expenditure types.
    • For example, if you are evaluating whether to use a tool, an early question might be to consider whether the cost of the tool is in line with budget constraints and savings goals.
    • Alternatively if you are a tool supplier (in-house, open-source or vendor) and you are reviewing how to respond to a user change request, you might need to look at the ROI for the effort to make the change, and the benefit to the users.
    • Research point: One participant working on updates to a tool said that they have to think about ``do I get payback for the amount of effort to make this change?'' when considering change requests.
    • Research point: in one case study, the participants used the heuristics to decide whether to evaluate a particular tool at all - the licencing cost for the tool was not in line with the department's financial savings goal, but the heuristics allowed them to identify alternative ways of meeting their goals.
    • Research point: one participant commented that their organization favoured tooling expenses that could be Capital Expenditure rather than Operational Expenditure.