How is this your biggest problem? Emailing an annotated screenshot or attaching to a JIRA seems better because it's more consistent and blends with other processes. What should happen when webpages content changes or goes defunct? Now you're also creating an archive.org... and on and on. Don't get stuck and sink your time into a local maxima. Maybe you'll find a market [of fools] willing to invest time into this exact locally optimal solution, but I predict it will be disappointingly small. The problem it solves isn't broadly substantial enough to warrant a specialized solution. Only one way t
Actually, this an ecosystem of visual bug reporting tools that already exists and it's very useful when your other testers/stakeholders are time constrained. These days people talk about user experience, well, this is the equivalent of that for tester experience. It makes it a lot easier to submit useful big reports. When you mandate jira (which is slow even on its fastest day) you then a big report from a 2 second click in an on page tool to like a 10 minute process, filling out all the fields, cropping the screenshot, copying over the url and console log and any network errors and all that.
What if the element moves or is replaced in the next design iteration ? I’m not sure you want to be merging and splitting tickets on individual DOM elements to keep the comment history sane.. Though I would be interested in tooling that allows clients to simply create issues by clicking an element and then saving full context (dom, screenshot, url, form state, browser and session) with that issue. Something important is too often missing from a bug report. But then the problem is getting the client to actually use that tool.
社區原聲 · 熱門評論
打開原帖核對