Where I work - a team of 6 testers - we use Excel spreadsheets a lot. For bug fixes, there's rarely more than a text file saved with our bug tracking tool (built and maintained by the company). Feature development usually gets a spreadsheet with a listing of test cases and results. The regression automation has a separate shared spreadsheet where the results are logged daily.
A lot depends on the level of detail that's needed: for the regression automation my team has a tab per major release, and a column per test set (usually the test sets are organized around functional areas of the system). The first row lists the expected results for each run - usually something like 0 errors, x warnings and what those warnings are for.
For feature development, the spreadsheet gets organized around feature sets or user stories, depending on which makes more sense in terms of testing and reporting, and wraps to a summary tab with pass/fail results for each major section. The detailed test lists are on a pass/fail basis as well, with space to describe failures and note bug reports created if needed.
What I've found is that the level of detail and structure depends a lot on the complexity of the application(s) under test, the size of the team, the speed of development (if you can tell a developer who's working on a new feature and get a fix in within 24 hours, there may be no need to report a bug), and the amount of overlap between different development teams.