软件测试报告是对QA的工作成果、贡献的体现，除此之外它还有别的用途，来看：
测试报告除了能告诉老板QA存在的必要性，还有什么用处呢？
测试报告是QA工作中的重要一环，通常在一个项目结束或者一个sprint结束时发出，一个好的测试报告，不仅仅可以述说QA到底做了哪些工作，而且可以看出整个项目生命周期运行的平稳与否，软件的质量如何。甚至可以说出哪个开发做的工作重要，哪个开发的工作量多，哪个开发技术最烂。
举个例子
我们以agile scrum模式运行的一个sprint为例，详细解释测试报告究竟能告诉我们哪些事：
Sprint总体信息:
包括sprint名称，范围，测试方法，测试内容，测试人员，测试共plan了多少story，一共多少story points，实际完成了多少points。
常规bug信息：
当前sprint发现的Bug列表，ps：包括bug个数，当前状态，严重程度，AssignTo， Reporter等。
按照Bug严重度划分的Bug饼图；
按照Bug优先级划分的Bug饼图；
按照Bug产生的原因划分的饼图。
测试团队存在的问题：
测试用例的完善度，ps：按照发现Bug的测试用例划分的Bug饼图；
测试人员发现bug的能力，ps：按照发现人划分的Bug饼图。
注：此点在某一个sprint仅能供参考，但在多个sprint这个维度上，一定程度可以看出测试人员发现bug的能力.这点也是定点培养或者定点打击的利器哦。
开发团队存在的问题：
整个开发团队对问题的修复能力，ps：Bug修复的平均时间；
开发团队对问题根源的把控能力，ps：Bug reopen的比例；
哪个模块的代码质量最差(也可能这模块最复杂)，ps：按照功能模块或者story划分的Bug饼图；
哪个开发者技能最差，ps：按照Bug所属模块的开发者划分的Bug饼图。
注：同样单个sprint不说明问题，多个sprint的横向比较可以说明开发者的技能水平。
哪些模块的引入引发了原有的功能缺陷，ps：按照Regression测试来划分的Bug饼图。
注：此类问题越多，说明系统耦合性太强/开发太弱，这也说明开发给的impact scope 不准确或者测试的case有遗漏。
Scrum master， PO对项目的把控能力能力。
整个sprint中Change Request的发起数目，占整体Bug的比例。
整个Sprint中，unplanned的task的数目，story points数，与plan的task的占比。
整个sprint中Live Defect的发现数码，占整体Bug的比例。
注：在sprint成功的前提下，上述问题越多，说明响应越及时，但同时说明团队原有工作不饱和，SCM/PO缺乏规划能力，缺乏对外界干扰说不的勇气，不能有效使团队focus在plan的tasks上。