Don't do it
Short answer is do not sign off a release.
As the tester, it is your job to gather more information about the system or the product at hand and present your findings to allow the decision makers (product manager, project manager) to sign off a release.
What you should do instead
You might be the only person to have tested the product and everyone else is confident that you've worked together as a team to have ensured and agreed upon that the critical components of the system are still working and you've written your tests after talks with other stakeholders in the company such as the developers and the wider business team. Great job!
Before you sign off the release, make it clear that you have signed it in an email sent to the appropriate people with the following checklist (you can remove and add as you please):
- Test scenarios took into account discussions with the wider business team
- Test scenarios were agreed upon by the development team
- Test approach maximises alot of scenario testing
- Automated smoke tests have passed
- Automated tests (if any) have ran and there are no failing tests
- You have tested the product adequately (in your opinion)
- Effective testing was done in the alloted time
- Release blocking bugs have been fixed
- Product manager has agreed that open bugs are not release blockers
With our recent discussions on the approval of the release of Feature X, I agree that the feature works to my satisfaction with the following items to bear in mind:
- I have spoken to X and Y from the wider business team and have taken into account their point of view in how they would perceive this product when they are released
- Development team discussion was done to increase confidence that test scenarios and the test approach is as effective as can be
- Automated tests have ran and resulted in no failures
- Bugs have been fixed
- Open bugs in the bug tracker are not release blockers as agreed upon with Product Manager
This piece of writing was inspired by a part of the book that I keep rereading - Lessons Learned in Software Testing: A Context-Driven Approach