Let's start with a potentially controversial reminder.
Agile for Agile's sake sucks. - me, an Agile Coach
Don't get me wrong: the Agility mindset and evolving practices will help with conducting frequent feedback loops in product & process, but which experiments you conduct, and what you do with resultant information, are all business decisions. You conduct experiments for frequent feedback loops not because this in itself will have you stay in business. You conduct experiments... to serve your customers well... to stay in business.
So what if there's now a bug?
Ultimate goal is to stay in business.
Ultimate mission is to serve your customers well.
Recognize that the tidy Scrum framework for conducting experiments may become... less tidy.
...Specifically, the Sprint Backlog may become... less tidy.
Bug from Inside the Sprint
This ain't really a bug. (Wait. WAIT! Put your pitchforks down...)
If you're still working on a feature, or an upgrade to one, then you're in the middle of a Sprint, which means you're not at the end of the Sprint, which means it's not done - it's technically Work-In-Progress. If you find an issue with WIP, like from testing this WIP, then subsequent discussion & work is all part of the work of getting it to done.
Finding an issue with WIP is good, and it's definitely cheaper than finding this same issue after it's been released.
Adjust your stance. This ain't really a bug. (See?)
Still have the triaging discussions. Still fix it if it's necessary for the backlog item's acceptance criteria. No Scrum game rules have been broken. The Sprint Backlog remains tidy.
Bug from Outside the Sprint
This is a bug.
Likely activities from this point:
Investigate its frequency of occurrence.
Investigate its severity.
Discuss next actions.
Fix it now, like, in-the-middle-of-the-Sprint now.
Let's compare these activities to what we'd do in a Refining session. In getting a good enough understanding of the backlog item so that y'all are comfy enough to start it, some discussion is likely involved - this is akin to discussing the next actions of the bug. The Sprint Backlog remains tidy. Now, in getting a good enough understanding of the backlog item so that y'all are comfy enough to start it, some investigation may be involved - if this feels small, then it's part of the Refining discussion, but if this feels bigger, then you probably set up a spike, capturing technical investigation effort, and this is akin to investigating the bug.
If you're putting something in a backlog, unless it is a dummy "0-point" placeholder item that overloads your task tracking tool so y'all see certain items each day (like a Kaizen item, or an item where folks log all undue distractions through the Sprint so it can be reviewed at the Retrospective), it has a cost (it takes effort), and thus an opportunity cost (it takes the place of something else you could be doing). Thus, to me, I conclude the following potentially controversial point.
Spikes & bugs get story points. - me, an Agile Coach
Yes, spikes are time-bound, so you're not investigating forever, and that time-boundedness is more important than the points themselves, but I recommend putting a guess at some points here because if you're doing a spike, you're not doing something else.
Also, a bug to be fixed, let alone investigated, means it is getting effort associated with it, so I recommend putting an even bigger guess at some points here. The fact you will likely be 'off' on its estimate is factored into how story points are well used: in Release Planning using average velocity.
So if you are going to at least investigate a bug because it is the level of investigation that would require a spike in a different context, then be transparent with your current efforts and include that with some story points in your Sprint Backlog, which has just become... less tidy.
One last case... an easier one: if you don't need an investigation to determine that y'all need to fix this bug, then throw that in your Sprint Backlog with a guess at some story points, which, again, has your Sprint Backlog become... less tidy.
Bug Now Inside the Sprint
I compare the Daily Scrum to Sprint Planning, where in the latter, I ask, "Do we think we can get all this done?" and in the former, I ask, "Do we still think we can get all this done?"
If the Development Team, after including the bug, still thinks it can accomplish the Sprint Backlog (and / or the Sprint Goal), then there's no big disruption.
If the Development Team, after including the bug, does not think it can get it all done, now there's a disruption. I mean, I guess you could pull the cord and cancel the Sprint, but that is uncommon. Usually, the Product Owner asks which items of the Sprint Backlog are likely to not get done, and then the PO informs corresponding stakeholders to set expectations. The Sprint Backlog is still less tidy, but the effects are mitigated.
Space for Bugs Inside the Sprint
There's a pattern that exists for handling cases like bugs, or other suddenly prioritized work, in environments where you can't seem to maintain a stable Sprint Backlog. Allocate a percentage of your velocity as a Buffer to handle incoming effort without disrupting the rest of the Sprint Backlog, anticipating some untidiness.
Let's say you have a velocity of 40 points. Sprint over Sprint, though, y'all get about 10 points' worth of suddenly prioritized work, constantly disrupting the Sprint. Mitigate this by creating a Buffer of 10 points (25%) at Sprint Planning: plan for 30 points' worth of work, with at least another 10 points' worth at the ready.
If you get through the 30 points of planned work by the end of the Sprint, and there's room in your Buffer, then "pull work in" from the Product Backlog.
If you get through the 10 points of the unplanned work Buffer by the end of the Sprint, and you want to "pull work in" because it's suddenly prioritized, see the discussion above: either cancel the Sprint (ouch), or figure out which stakeholder to disappoint (boooo).
How Tidy is your Sprint Backlog?
Certain parts of your Scrum framework implementation may become untidy. It's OK. As long as you know why you're deviating from the Scrum Guide, and as long as you are still grounded in empiricism's transparency, inspection, and adaptation, then you're deviating thoughtfully. Oh, and having all this Scrum stuff work for you.
Have all this Scrum stuff work for you, even if it means it becomes... less tidy. - me, an Agile Coach
So you serve your customers well.
So you stay in business.