There are a few reasons for estimating:
- To work out how much the team can commit to doing, each Sprint, in order to manage stakeholder expectations
- To plan releases based on how much work the team can do
- To see if there are any discrepancies in understanding of the work that needs doing.
With respect to the discrepancies, there are plenty of other ways to uncover this without estimating. I like to use Behavior-Driven Development's scenarios in conversation for this; if you can decide which scenarios are in and out of scope, and ask questions designed to find missing or unclear scenarios, you'll usually find out if there are misunderstandings or work that could be descoped for another story.
With respect to how much the team can do, and planning releases, you can think of the team as a pipeline. At any point, there will be one role whose time is constrained, and which represents the narrowest part of the pipe. By considering how fast that constrained role can work, you can see how fast the work can flow through the system.
It's usually the case that developers can help overworked testers, but testers can't always help developers as easily. For that reason, frequently developers are the constrained role, and if that's the case in your team then I would suggest worrying about the development effort rather than the test effort. Including complexity and doubt in the estimate is a great idea. If the constraint ever moves away from the developers, you can change the role that does the estimation.
It's still worth talking through the test effort as this may impact how much work will fall to the devs. Note that developers and testers have very different mindsets, even when their skills are similar, so while they can collaborate effectively it's not always the case that they can take on each other's roles with flexibility.
As a final note, story points are meant to be a lightweight way of planning and setting expectations. Teams that worry too much about accuracy tend to inflate stories so that points become worth less and less, and there are more of them, and also tend to spend more time on their process when they could actually be getting work done.
For this reason I prefer Kanban, which makes the constraints in flow very apparent and explicit, while providing more flexibility than Scrum's sprint cycle. Cumulative Flow Diagrams are also a great way of spotting constraints in either framework.