The goals of quality assurance testing  are not always immediately obvious, and taking time before the development process starts to list these goals will contribute greatly to a quality product that meets the expectations of every stakeholder.
The process of actually performing quality assurance testing on software as it is being developed and during post-development relies upon the availability of clearly stated goals. The testers must be able to determine what they are testing for—obviously, quality assurance testing for coding flaws is a given, but other types of testing may not be so obvious. The tests must include analysis to determine whether the software is meeting softer goals of the various end-users that may relate to issues such as usability or cost.
Quality assurance testing must take into account business goals when analyzing the final product. For example, a business goal may be to increase productivity or efficiency in very specific ways. A stated goal may be to reduce the time it takes to execute a process from two days to one day, for example. In general, these goals should be as specific as possible. A statement that indicates a goal to “improve productivity in the operations department” is fairly useless because it contains no solid information as to the process or the specific metrics. On the other hand, a goal of improving the billing process and reducing the amount of time it takes to create an invoice by half, can be clearly understood and measured against.
Separate from business goals are performance goals that specifically relate to the operation of the software. These goals may for example, specify a desired transaction time or level of responsiveness, or specify an access time for a database query.
Unlike a business goal, which is broader in nature, a performance goal relates to the actual operation, performance and responsiveness of the software itself, under a varying set of conditions. Performance goals may revolve around a wide variety of application issues or database issues. Identifying these performance goals prior to actual coding does add some time to the development lifecycle up front, although it results in higher quality software on the back end and ultimately, less expense overall because design flaws are avoided.
It is incumbent on the project manager to compile these goals in written form, and this requires participation from multiple individuals or departments within the organization. Business goals for example, cannot be determined by the developers; rather, these may be more appropriately determined by management. Performance goals, while the developers may have some insight into what is required, will also be better established by end-user stakeholders and clients, rather than the developers themselves.