nus-pe-bot
commented
4 years ago Team's Response
Tester provided vague metrics for complexity (i.e. "commands that need a lot of slashes") that the team does not agree with. The team felt that subjective interpretation of user experience as reported by the tester does not amount to a feature flaw. Furthermore, the tester included suggestions of features not found in this application, and used that as a justification for the comparative basis, which is not a factor the team should be penalised for.
Severity lowered to low as even if general user experience were to be accepted as a component, the examples given by the tester would likely only impact a small set of users, and even then only those who are first starting out on the application.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: I understand that it may be harsh to reject the design of such a major part of the entire application, but I wholeheartedly believe that the commands chosen for the CLI are especially not appropriate for the use case of the application. I think it's clear, and we all agree, that response time and speed is crucial for this application's usefulness. The CLI has not been optimised at all, and this wholly kills the usefulness or completeness of the application.
This may indeed be a subjective thing, but I can only offer a subjective opinion within the confines of a testing situation. I am certain that if user testing were to be performed, users would find the application difficult and frustrating to use. If there were any other issues submitted relating to the same issue in the dry run or in the actual PE, then I am sure this is not simply a subjective thing. If no other issues were submitted relating to this same issue, then I concede. But I genuinely have doubt.
Let me respond to points your team made in your response to fully explain why I disagree.
1) "Tester provided vague metrics for complexity (i.e. “commands that need a lot of slashes”)". Fair enough that they are vague, as they were written in a timed and stressful setting. But just look at a random snippet from your command summary:
Inputs require hyphens and slashes, which are not commonly used punctuation in normal writing. I am sure data can be found on this to make this an objective claim. These will definitely slow down the input of the commands. And many of these slashes have to be input because there are many arguments.
You said, "the team does not agree with [the judgement of the commands as complex/difficult to input]" So, are you suggesting that these commands are not difficult to input? Perhaps they may not be impossibly hard to input, but let's say we took out all the slashes and hyphens. That's undeniably easier to input! A more complex parser should have been implemented to make your app more useful.
2) "The team felt that subjective interpretation of user experience as reported by the tester does not amount to a feature flaw." How exactly do you intend to get a fully objective interpretation of user experience? This is an unfair dismissal of a fair point made. Your rejection here uses the word "felt" as well! I feel that your rejection is a subjective interpretation of my report...see how we don't get anywhere?
Ultimately, you admit that the application has poor user experience, and poor user experience is a feature flaw.
3) "Furthermore, the tester included suggestions of features not found in this application, and used that as a justification for the comparative basis." Fair enough, but I wasn't intending to use that as a comparative basis, just providing suggestions for possible further improvements to the program in v2.0. An easy fix, as mentioned, would be simpler commands and better command parsing. Commands and command parsing are features already found in the application.
"FeatureFlaw: Some functionality missing from a feature delivered in v1.4 in a way that the feature becomes less useful to the intended target user for normal usage."
I argue that functionality of easy command input is missing from the feature CLI input in a way that the application as a whole becomes nearly useless to the intended target user for normal usage.
From your user guide: "That’s because, in an emergency, every second counts."
This isn't something your application offers. Because of the difficulty of inputting commands, i.e. doing anything at all, especially for emergency call operators, the app is slow and frustrating to use in time-sensitive and stressful periods, which goes against the very point of the app.
You said, "which is not a factor the team should be penalised for". But I personally feel this shouldn't be about "penalising". This isn't punitive. The user/tester and the team is on the same side here, we all just want to see the application succeed. And so, I believe the CLI necessarily HAS to be optimised, or otherwise the application will be useless.
4) "Severity lowered to low as even if general user experience were to be accepted as a component" General user experience should be accepted as a component of every application. I believe we are agreeing here that the user experience of your application is poor, i.e. your application is not useful.
"the examples given by the tester would likely only impact a small set of users" I wish you had identified this small set of users. Is it users who input commands, i.e. everyone? Or users who are not used to typing many slashes and hyphens, i.e. I would say nearly everyone? Your claims are hazy because I don't think there's any real substance behind them.
"even then only those who are first starting out on the application." That is a serious issue though! Pickup of your application should be simple because no mistakes can be made in an emergency situation. And what emergency operator will want to introduce a new application that demonstrably is difficult to pick up, especially when improving to more standard technologies is already difficult?
So on the whole, although I appreciate your team's unconventional/creative choice of application, I don't think you carefully thought about the most important feature, i.e. the command line interface. It is intimately tied with speed and lack of making mistakes which should have been the focus of your application. Yet, no changes or improvements were made to it, and this feature is flawed.
:question: Issue severity
Team chose [severity.Low].
Originally [severity.High].
- [x] I disagree
Reason for disagreement: Reasons are stated as above in disagreeing with the rejection, in particular point 4.
Briefly put,
- It affects all users.
- It is tied to the core usability of the entire application.
Even as a tester, I find it a struggle to key in the complex commands that need a lot of slashes and many keywords. I even have the user guide right beside me.
For a stressed, sleep-deprived person who doesn't have the user guide using this app for its intended purpose, won't it be even harder to follow the commands and use the app? And it will be an urgent situation. I genuinely feel like it's way harder to use this app than to do it manually.
I feel that more optimisation of keying in the commands should have been implemented, e.g. autocorrect or autocomplete, or at least simpler commands that don't need me to type so many / and -.