Issue report and log information.

  This report is one of the most important output factor from testing team.Hence,it must be clearly and apply more information as we can find.The info should contain the version of issue occur and build number,DB,component is necessary(for some complex system),date,reporter,picture (we can catch a picture,that would be clear at a glance),log information will be better,exhaustive description of isssue,rate of reproduce,reproduce step,precondition,expected result,and actual result or something like that.Certainly,there are some items we can recur to good bug track system(BTS) to implement,like reporter(who found this issue) that's the person who report it,date(this will be generated by BTS),and rate of  reproduce,as sometime tester always communicate with developer to comfirm is that a bug,in order to avoiding duplicate issue.However,this way is not a good way for process.We can hold other method to escape duplicate bug,bug db,I think.

  Ok,back to our topic.Certainly,detail info should base on different project.But,our aim is make developer get enough information to follow,reproduce and settle it base on our issue report.Although,we still always hear from complaination from developer,like the information is too little,second is that many issues are duplicated.These two phenomena are common.Simply said,we can use issue report template to resolve first question.We have talked about some factor should be written down.We could add or delete other item for different system.And,sametime,we can find someone in testing team to spot-check the quanlity of issue report.I think crossing check maybe  a wonderful way.This is not only good use for our report quanlity,also good for studying each other.And this way also can be used to review our test spec.If you have consummate BTS,that'll be different.Hehe!For the second question,error manager maybe can help us.They are not only check if the issue has been reported,but also  consider if it can be ignored.In my point of view,they should possess lots of experience to judge what kind of question is critical or trivial.And,meanwhile,they also need good communication with developer to check issue some extent.