Our Agile/Scrum team follows the Fibonacci sequence for story point estimation. However, it is not clear whether we should have any zero point stories at all. Even though a story may have minimal development effort, it still needs to be tested, regressed, documented, and deployed. So, there is always some overhead associated with any change.
This is an area of debate within the agile community, and I think that reasonable people can disagree. However, you're quite correct when you say:
Even though a story may have minimal development effort, it still needs to be tested, regressed, documented, and deployed. So, there is always some overhead associated with any change.
Because every story has overhead, whether it's task-switching, preparing its demo for the Sprint Review, or integration testing, no story truly requires zero work effort.
Alternatives to Zero-Point Stories
Since the work isn't "free"—and therefore non-zero—you have a few options:
Use half-or quarter-points.
Remember, a story point is a unit of measure relative to a one-point baseline story. So, a minor tweak that you can do with minimal effort might be 1/2 or 1/4 of the effort required for a typical story, and should be counted as such.
Roll up small stories into a mini-epic.
While I'm not a fan of this approach, I consider it valid. You could take any number of small stories, and roll them up into a single one- or two-point story. For example, rather than having eight quarter-point stories for adding individual users to a system, perhaps you can have a single two-point story to handle all of them.
The benefit of the first approach is that it ensures that all tasks are captured, and that stories can be done or not-done independently of one another. The benefit of the second approach is that it simplifies bookkeeping, but at the cost of causing the entire story to be failed if any one sub-task is incomplete at the end of the sprint.
Pick whichever method works best for your team. Your mileage will vary.
Zero point for Defect card
Some companies (including mine) are using zero point for "defect" card. We agree that defect card is not the thing customer want so we estimate it as zero even we have to put the effort to fix it. The velocity of that sprint will be lower than others because we have to take time to fix this zero story point thing. This will be shown at the end of sprint that we had defect card(s) to work on and this can show the quality of work in the team (it could be human defect or requirement defect).