You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I have more of a software engineering question in regards to JIRA.
I find that Atlassian JIRA has "resolution" field and it can be as invalid.
Sometimes bad practices use these without any reason and that leads to many open questions.
Is there any way more details broad category of "invalid" sub states be defined?
Please help if you have experienced this and what can be better ???
I came up with below sub-states, so test and developer can work in harmony --
INVALID - USER ERROR
instances, where the user has totally goofed up in sending the command itself
INVALID - SETUP ERROR
user commands are good, but the setup is totally in a bad state
INVALID - CONFIG ERROR.
user is good, setup is good, but the feature configuration is totally messed up
INVALID - FEATURE LIMITATION
user is good, setup is good, but the feature configuration is good, but there is known issue or limitation
INVALID - OTHER DETAILED REASON
Something the developer/tester needs to agree upon.