I'm an engineer at a company that’s building a SaaS product. We use the product internally as it serves as a productivity tool for some use cases we have. A byproduct of this is that we are always internally testing, like running our own testing sessions for new features/versions or just using it internally to do our work.
When we internally test features we document findings through a Confluence page and then export everything to Jira. If we find an issue in something unrelated to what we are testing then it’s likely we don’t know where it should go. This is the same for when we just use the product ourselves, for example, I end up just not sharing problems because I want to save myself from the hour-long Slack rabbit hole that it puts me in.
I’m keen to know if there’s a way I can make this better for my team or the company as a whole. Or if there are any other ways we can go about assuring quality before releases.
FYI we don’t have QAs, developers are expected to handle that part. We also have automated tests but we still find issues when we take a manual approach, ofc depending on the size of the change.
I would appreciate any and all feedback! Thank you.
When we find something related, a Jira ticket associated with the feature is created with test procedure to reproduce it, and what is expected. This ticket will need to be fixed before release.
When something unrelated is found, a Jira ticket is done with test procedure, but the expected behaviour may be missing. Then this is analysed (every 2weeks usually) to figure out the importance of the bug, or if it is really one (it might be a feature), then a priority is given on the issue. If it is not a bug, we make sure to write down in the ticket why it is not a bug. Chances are that someone else will find it and ask questions, and you will have the argument to counter it.
Our end of the backlog is actually filled with insignificant issues, turns out noone complained about it so no need to spend time on it.
The approach we take is:
- We dogfood our changes by setting up a Trello board with the tasks that need to be done and just work through it.
- Progressively rolling out changes to beta groups until we think we can go to 100%.
Not sure about the internal reporting thing though, that seems like a visibility issue into product ownership. I’m sure someone in support might have a better idea on that as they probably deal with similar problems for external feedback.