In many projects there is a QA person or persons responsible of ‘assuring’ quality. This is mainly done by testing and writing many reports. I will argue here that this mostly is a waste of time and should not be done anymore. Lets start off by looking at quality assurance and where it comes from. It initially comes from from manufacturing where the QA would ensure that certain properties of a produced product fall within a predefined range of acceptable values. We in the software development industry took that system and adapted it for our purpose. With requirements and specifications which have to be smart so we can assure the quality. This is in essence a wrong approach as software development is a creative process. Quality is an immensely complex thing and assuring it is a myth the only thing we can do is trying to the best quality for the buck. It is therefore not a smart thing to just have QA sit in the back waiting till something can be tested. The role of a tester is 3 fold. First is to find information about the product being developed. This information is mostly bugs, but can also be information developers needs for further development. The method should fit the project, but writing lots of plans and test cases is hardly ever more effective than session based testing. The second role is to be an advocate of quality improvements. An advocate meaning that the tester should actively participate in product planning, both in the planning in terms of the feature set and planning in terms of possible choices of implementations. The tester should promote implementations with reduce complexity, promote technical stories which are aimed to reduce technical debt. In a sprint planning for example a tester could advocate refactoring some piece of code based on testing results the previous sprint or promote a user story which mitigates a potential unstable application behavior or discouraging a story which increases the complexity a lot. In short it should be the aim of the tester to maximize the quality and lead efforts to improve the quality. The third role is to inform stakeholders of the quality so they can make an informed decisions regarding releases etc. How this information is presented has to be agreed, but it should be a holistic picture and not a set of metrics. At the end the tester should present his finding and his opinion of the quality to the product owner. It is up the him or her to say if this is acceptable or not. If the quality in not acceptable, the tester should suggest ways to improve the quality.