Tickets

The thing we work on every day.

We ❤️ our QA team

We really appreciate your hard work. This conversation is not about teaching anyone how to do their job, but about making our interaction more comfortable and productive.

Developer's process

• QA happens
• QA engineer find bugs
• QA engineer list them in a ticket
• Ticket moved to has feedback
• Developer validates feedback
• Developer try to fix feedback
• Developer answer to feedback
• Dev and QA discuss feedback

What goes next? (1/3)

• QA happens
• QA engineer find bugs
• QA engineer list them in a ticket
• Ticket moved to has feedback
• Developer validates feedback
• Developer try to fix feedback
• Developer answer to feedback
• Dev and QA discuss feedback
• _repeat as much as needed_

What goes next? (2/3)

• QA happens
• QA approves ticket
• QA creates tickets for issues that are out-of-scope of that ticket
• Developer merge ticket to stage ->prod
• QA checks ticket on prod

What goes next? (3/3)

Environment

- OS (Linux, macOS, Windows)

- Browser (Chrome, Safari, FF, Edge)
- Third-party tools (browser extensions, third-party programs for interacting with the screen and website).

- The computer itself (hardware)

How we can get rid of point 2?

We can’t build a website that works equally well in both a normal and a broken environment — just as a film, no matter its quality, cannot be shown perfectly on a screen with hundreds of dead pixels.

We develop our app using web standards that is agreement between Browser companies and app developers.
Browser companies commit that they would support css rules, html tags and so on.
And devs use only supported features.
Some well known bugs or limitations exists, that are not fixed for years and we create solutions to manage this things. Broken browsers that do not follow standarts, or teprorary broken in intermediate upgrade step - is not something we can or should manage.

Browsers:

The OS is also code, which can also have bugs and be broken. The OS + Browser combination can also have integration issues, which can lead to non-compliance with web standards.

Such problems are usually unexpected and occur during the release of new major versions. For “long-lived problems” of this level, we sometimes come up with “workarounds.” But if it is a release issue and will be fixed in the next patch version, building the workaround and testing it may take longer than the OS patch release with the fix.

OS:

While we “display JSON beautifully on pages,” third-party tools are designed to work with the HTML of our pages, embedding their code into our application. If the code of some third-party extension has a bug that deletes all <p> tags (or that is the essence of this application/feature), how can we deal with it? How can we know what problems each of the 138,000 extensions might add?

Extensions for engineers interact most with web pages and, accordingly, may have the most bugs.

At the same time, ordinary people rarely use such extensions.

Third-party tools:

No, they obviously do not and we should do our best to provide best UX. But in the same time, we should accept that in some circumstances (browser in broken state, third-party apps affect code) we can't do / shouldn't do something. And in that case: yes, they should fix their PC.

So what's the point of testing in an invalid environment if we clearly can't do anything about it?
Moreover, the presence of environment “bugs” can hide/distort real problems, thereby allowing them to pass QA testing

NO and YES

I'm not talking about a sterile environment.

We can simply be attentive and keep an eye on the obvious things:

• The browser is not updating right now
• Third-party code do not affect an app*
• Our computer is not obviously broken
•  There are no obvious signs of incorrect application operation (irrelevant things do not work)

* Apart the one's third-party we agreed to support.

• update Chrome to the latest stable version (if prompted)
• Disable browser extensions and 3rd party tools, or remove them and make sure they do not affect the browser in any way, and restart your computer.
• Open the site in an incognito tab
• QA without "recording" first, to make sure that issues are not caused by recording tools.

• Compare whether it works where it should work 100% (staging, another working app's area, another app)

My "baseline" suggestions:

Check if it works on staging first

Let's only send tickets to Has Feedback if bugs relevant to the ticket are found. And let's discuss the need to create separate tickets with the product right away (during the first round of QA) if the problems are present in both the Preview and Staging environments.
This simple action will allow us to save 16-48 hours on feedback loop and eliminate any potential scope creep.

How we can get rid of point 3 (report only relevant issues)?

What happens if QA would not do that

1. QA would describe an issue in a ticket.

2. Developer would switch context and stop working on his current task (next working day)

3. Developer would spend time to debug issue that is out of scope of ticket and maybe find a solution.
4. On some step dev would check staging and see that it is irrelevant.
5. Dev start conversation with product, get approval to skip that, QA create a ticket for issue.
6. If that was the only issue, ticket goes to To Be Deployed.

What happens if sompare first

1. You would describe an issue in a ticket, start conversation with product, get approval to skip that and create a ticket for issue.

2. If that was the only issue, ticket goes to To Be Deployed

• Would save QA time
• Would save Dev time
• Would inprove ticket delivery speed
• Would prevent scope creep 
• Would remove a need to extend cycle with a "new" tickets for irrelevant issues, that was fixes during debuggind
• Would allow product to know about problems earlier

So doing all this:

Thank You!

Let's discuss!