Make workflow for using bot more understandable for a Tester who has "signed up for a run"

[ChrisC]

(originally requested by @mcking65 in #1513 (comment))

I have a concern about how difficult it is for people to understand the workflow of using the bot. I don't think this has to block deployment, but I think it is a P1 issue.

Let's say I'm a tester and I want to sign up for a test plan and then use the bot to collect responses. To do this, the tester needs to use the following procedure:

Activate "start bot run".
Wait for the run to complete.
Activate "manage bot run".
Activate "assign tester" and choose themself.
Problems:

Steps 1, 2, and 3 are opaque. You have to be trained and remember; the remembering could be difficult for people who don't follow the procedure frequently.
If the tester happens to press the "assign yourself" button, they won't be able to do step 4, and they will not know why.
I think we need a solution, and it needs to avoid the more substantial back-end changes we have discussed. We need something expedient.

For problem 1, it is a matter of helping people get the bot started. Problem 2 is about knowing what to do when it finishes.

Here are some ideas for problem 1:

When you press "assign yourself", ask if the user wants to start a bot run. Here the tricky part is what to do if the bot is not available. We are limited by the fact that the bot can only have one run assignment at a time. If there is a complete bot run, this could be the trigger that auto-assigns the run back to the person who started it. If the bot is busy, we could simply tell the user that the bot is busy and to please try again after the current bot run is complete. If it is not too complex, we could queue the request and when the current job is complete, assign the complete run back to its requester and start the queued run.
Instead of the previous idea, we could ask the user if they want to run the bot the first time they activate the "start testing" button. This still has the same problems of what to do if the bot is not available. It is not quite as good because the user may have been ready to start testing, and now some of their testing time will be used up by waiting on the bot.
Ideas for problem 2, what to do when the bot is done:

As previously mentioned, in the testers column, show who started the bot run.
When the bot run is done, in the testers column, next to the bot run, show a "assign back to me" button.

[ChrisC]

@mcking65
For the first problem you identified ("Helping testers get the bot started"), I like your second solution:

...we could ask the user if they want to run the bot the first time they activate the "start testing" button.

I think we could also extend this new prompt to the "Assign yourself" button in the Testers column as well, so that a tester is always presented with an option to run the bot (if no bot run exists yet), or, if a bot run exists, then assign that bot run to themselves.

For problem 2, "what to do when the bot is done", I like the suggestion of adding an additional "Assign to me" button in clearer view in the Test Queue. (You suggested adding it next to the bot tester in the Testers column, but I think there might be more space for it in the bot status widget in the Status column. We can iterate on the placement, and pick one or both.) We can also give some additional guidance about how to take over the bot run in the Assign Yourself / Start Testing prompt from the solution to problem 1.

In general, I still want to err on the side of keeping this as simple as possible since the bigger goal is to get rid of the "bot tester" concept and allow testers to use bots as a built-in utility within their own test plan runs. I think the two solutions above are the simplest way to improve this workflow for now!

If this sounds good to you, I can clean up the product requirements in the issue description here and we can queue this up for implementation!