Most of the time it's just not necessary. What does it add to the report? If anything, it shows laziness. There may be situations where you need a short snippet of output to help you tell your story but for the most part no it should not be in the report.

ok so without those detail we just need to put a story about server's vulns lol

Creating a good report is one of the hardest things to do so here is the format I use.

Executive Summary: Introduction, Summary of Results, Summary of Recommendation, Conclusion
This part I try to write as clear as possible avoiding most tech speak. I try to add some pictures or graphs that help to explain the issues found and recommended mitigations.

Project Scope, Rules of Engagement and Methodology
General information about what is and is not allowed + overview of the system/ip's we did use to conduct our audit.

Technical Attack Narrative
This is written for the tech guys and details any attack we carried out (succes AND failure). Discovery/enumeration is kept basic.

Vulnerability Mitigation Techniques
Here we calculate the risk of each vulnerability and they ways it could be mitigated. By calculating the risk we help the company to prioritize the fixes.

Appendix A - Toolkit
This lists all tools we have used in the audit.

Appendix B - Cleanup
This lists all files that were created and deleted during the test.

I like to have a video record of my tests and archive them offsite together with a digital copy of the report (encrypted of course). This way we can always show proof of what we have done in case the customer claims any damage or misconduct.

I use Camtasia Studio for this as I run most audits of my Windows box (I have backtrack in VM or just use a SSH connection).

The client does not mind it but of course I have to store it securely and can not disclose it without their approval. Nothing beats a live demo but a recorded video also makes a lasting impression if it is a spectacular hack

It depends on the client's motives: most common is to find holes and weaknesses (or management to bash a techie....). But it's not uncommon for a business (or IT team) to look for validation that their defenses are working as expected.

In a well defended network a report that states the pentesters couldn't get in is meaningless in business terms, a report that states they couldn't get in, but they tried attacks X,Y & Z which the environment withstood has value, from both the 'look at the benefit we're providing from the resources utilised for defense' and a 'we protect your data against X'.

It also helps prove the negative of no flaws; did the testers fail because the environment is secure? or because the testing team is incompetent?

Reports showing holes with mitigations are/can be the most satisfying and impacting to the business, but from the otherside being able to show that you defended against the most common threats is also of value from a business politics aspect.

There's always more to a pentest report than missing patches and 0day.

Thanks for the informative response. It's a posistion I'd never really considered till now, and can now clearly see why this would be beneficial.

What few reports and guides I've been able to find to try and learn report writing from, have all focused on the break it/fix it approach.

You also get a lot of client who want pass things drive you made by trying get you to reduce inpack of issue or remove them all together.

lol thats is crazy them making changes to the report it only come back to hit them.