Are you satisfied with the test tools that are available to you today?

[rosie (Rosie Sherry)]

I’d love a vibe check!

Are you satisfied with the test tools that are available to you today?

• Yes
• No

And bonus points for diving deeper:

• Do we have enough tools?
• Are they more of a distaction?
• What is missing?
• What do we find painful that would actually solve our challenges?
• How do our tools compare to what developer and designers have access to?

[sebastian_solidwork (Sebastian Stautz)]

@rosie

What do we find painful that would actually solve our challenges?

Getting budget to buy/try some tools.
Buy-in on collaborative work.
Not getting tools forced onto us. Especial those about test case management, specifically because they enforce a certain workflow instead of having the freedom to find your context-specific one.

@rosie

Do we have enough tools?

Without the constraints above I would in general say: yes
There are many available, but we do not have that often easily access to them.

I also develop many by myself as they are specific for my context.
Having a tool smith good to have.

@rosie

Are they more of a distaction?

A few are. I mentioned one above.

@rosie

How do our tools compare to what developer and designers have access to?

Aside automation they are not so much about pure technology, but being often about creativity, communication and collaboration.

[sarah.teugels (Sarah)]

@rosie

• Do we have enough tools?

I am always interested in learning about new tools: everything that can help me during testing, is of great benefit to me.

@rosie

• Are they more of a distraction?

Some of them are: test case management tools focus on preparing work so it can be planned, while in testing most of the actual work can be planned for but cannot be “scripted”/prepared => you can plan for finding/isolating/reporting issues, but you cannot prepare where/when/how/… you will find the issue.

@rosie

• What is missing?

A tool that combines note taking (like OneNote/Evernote) with planning & reporting. While those note-taking tools are great for documenting the actual testing, they do not help in any way with reporting the results of the testing, and they don’t help with the planning (but you can organize the notes in a way that helps with that).

@rosie

• What do we find painful that would actually solve our challenges?

• An easy to use planning extension to prepare the note-taking tool’s structure in a way that informs people in a team where & how to document their test results (this might lessen the risk of people “doing it differently than what we agreed upon”)
• Aggregating test results of test documented in a note-taking tool
  In current “test management tools”:
• A good way of documenting what we are currently testing, as opposed to “green/red flagging” of previously documented expectations, which also takes into account that many expectations are implicit

@rosie

• How do our tools compare to what developer and designers have access to?

Tools that developers and designers have access to try to alleviate work that is useful or necessary, but which is not those people’s main focus. Some examples:

• code repository tools help manage versions of the code, which helps the developers with clean code (don’t comment out old code, just delete it), with working in a team without constantly having to check if you can change a certain piece of code (check-in/check-out code, code review mechanisms, code merging, …), debugging (compare the last working version of the software with the current version so you only need to check the changed code), and probably many other benefits
• design tools make linking screens together easier, and help to indicate in a visually clear way what the action (e.g. button click, or select item in list) results in which visualization (which variation of which screen opens)

This allows developers & designers to focus on respectively coding and designing

The tools that are currently marketed as “test tools” don’t help the tester by making it easier to report, or easier to plan, testing. They make it so the focus is on the things that are easy to report or plan, instead of trying to help on reporting or planning the actual expected work. This causes the tester to have to do this kind of “administration”, in addition to having to do the actual testing, planning, and reporting (trying to make sure the test report includes the actual status of the functionalities, for instance by adding test cases after you tested which point to the bug).

[sebastian_solidwork (Sebastian Stautz)]

Sarah, you have many great/sad points here which I share with you !

@sarah.teugels

A good way of documenting what we are currently testing, as opposed to “green/red flagging” of previously documented expectations, which also takes into account that many expectations are implicit

At least for this I have a recommendation:
The Low Tech Testing Dashboard from James Bach.

@sarah.teugels

Aggregating test results of test documented in a note-taking tool

Maybe also for that, in combination with the dashboard:
Manual Test case management with Confluence, when you can use Confluence (or can do it with other software)
Don’t let yourself get distracted by “Manual Test Case” and read what tech they use here, the Page Properties Macro and its Report counterpart.
I can imagine that for different approaches aside classic test case management.
e.g. lines from the dashboard being imported from dedicated pages where the details note-taking happens.

[sarah.teugels (Sarah)]

@sebastian_solidwork

At least for this I have a recommendation:
The Low Tech Testing Dashboard from James Bach.

I mostly use a simplified version of this, as I very regularly am in situations where a full functional scope is not defined.
I usually report on:

• What have I tested/automated & What did I want to test/automate, but was not able to
• What seem to be the most important issues where the team should focus on for analysis and/or fixing
• What do I plan to test/automate next

But this is usually done from memory (with help of notes taken during testing). Like I said, the note-taking tools I use don’t tend to lend themselves to easy reporting on results & planning.

@sebastian_solidwork

Maybe also for that, in combination with the dashboard:
Manual Test case management with Confluence, when you can use Confluence (or can do it with other software)
Don’t let yourself get distracted by “Manual Test Case” and read what tech they use here, the Page Properties Macro and its Report counterpart.
I can imagine that for different approaches aside classic test case management.
e.g. lines from the dashboard being imported from dedicated pages where the details note-taking happens.

This is maybe something I can keep in mind for a future project where Confluence is used. It will still require a lot of setup to properly do it, though (even if I want to do proper session-based test management for instance). In addition, I find Confluence to be more difficult for taking notes as for instance OneNote or Evernote.
But thank you for the links

[alanmbarr (Alan)]

Yes, for now I am satisfied with the testing tools of today. Simple tools like Virtual Whiteboard, Wiki, API Documentation/Postman Tests are enough. My work is all backend and a massive portfolio and it works.

Don’t think about one tool. Think about one skill you need to understand. Write, use a structural argument, apply information architecture techniques and teach.

As a software tester our work is going to get harder and confusing. Take for example this quote.

… as a PM, your task is to discover the optimal labor distribution
between AI and humans that allows your users to contribute their feedback, control
risks, and benefit from the process. - Dr. Janna Lipenkova - The Art of AI Product Development

Take control of your testing. Explain and teach others what testing is today. As any other training wheel, use tools to structure your thinking and make quick progress. Take off the wheels.