What is be the focus of QA testing compared and UAT? Is it fair to say that QA testing is primarily about catching bugs or errors, while UAT is for validating that the business processes work appropriately?
QA and UAT have different goals.
From a commercial stand point QA is there to make sure the clients will accept the version during UAT. After UAT, taking it into production and making sure the client does not run into (too many) critical issues.
Client UAT is there to verify clients do not take a version into production that does not meet their minimal required workflow and make sure that they can continue working even when running into minor issues, not spotted at first.
From a personal standpoint the QA assists on the development teams side and the UAT is only on the client side. Both want the be able to assure the best product as possible. The client just should not trust the dev team's QA. The QA teams often focuses on general needs of multiple clients and issues that have arisen in the past. Where clients could be using the product in ways that are not specified and need to make sure these "workaround" features still work in newer versions.
QA helps the dev team in having a fast feedback (quality) cycle for new features and to safeguard older features with automated or manual test cases.
UAT makes sure the client teams can work with newer version.
Also, they are different phases in the DTAP model, where QA is the T(est) phase and UAT is the A(cceptance) phase.
As a rule of thumb you can think of it as the following:
- UAT is the QA for people who request the software to make sure the request is fulfilled.
- QA team is usually more technical and can troubleshoot issues that go past the enhancement request and how it affects the system overall. This may involve 3rd party data warehousing, reporting, communication with other 3rd party systems, whereas UAT will usually not deal with other systems (unless requests are explicit for those).
The meaning unfortunately depends on the company you are working for and on the methodology you are following.
Referring to the testing in the scope of software development I'd say that:
- QAT is the verification performed by the supplier on the product or service under development. It can be composed by simple manual testing or it could be an entire framework of different tests.
- UAT is the test suite that the final user will perform to accept the product, service. The UAT should be stated together with the customer before the project kick off, so that the development and qa team can have a clear idea about (independently from the user requirements specification) the customer needs and expectations.
QA (Quality Assurance Testing)
- Technology Oriented Tester
- Functional Component
- Integrated features
- Requirements specification
- Design Specification
- Interface level entry points
- Analysis testing tools
- UI end to end features
- Prior to UAT
UAT (user acceptance testing)
- Business Oriented Testers
- Business Scenarios
- Real World business needs
- UI end to end features
- Final and Integrated
- Prior to signoff/prod deployment
Quality assurance and UAT have different goals. Quality assurance is a type of static testing wherein you verify the documents like BRD and FRS documents to make sure that you are following the correct practices as laid down by your organization to enure a quality product. QA involves inspections,code review, walk through, feed-back etc. A more formal approach would be wherein a moderator is engaged and meeting between tester and developers takes place to make sure everything is on track.
UAT-User acceptance testing is a dynamic testing and by that we mean executing the code to check whether the product build is according to the user requirements or not.It involves testing the product from users perspective to make sure the product which has been build would be accepted by the users.
There are a lot of good points here - especially that every development company will use these terms slightly different based on their own models.
I'm a QA Analyst, and I primarily perform unit and system testing in line with new code during a given sprint (Agile development). As code changes or is added, I test the units and corresponding systems to verify functionality based on design document and business needs.
When we prepare to launch a major version of the product, we do beta testing as a form of UAT where the clients will test based on how they use the software day-to-day. This is both a technology and a business testing situation.
When our software is installed with a new client or upgraded at an existing client, UAT comes into play making sure the new version (or new software) works as the client expects, and this couples with training to ensure they understand how the software is supposed to function.
Your statement is correct. Yes, QA testing is more detailed in comparison to UAT. I will explain with an example: For example, there might be performance related requirements that might have been defined for a website that you are testing. So, during QA testing, you must adhere to the performance numbers specified for you website. Whereas during UAT, the users might be satisfied by just browsing the website since they feel that webpages "appear" to be loading fast so they can pass the UAT.
Apart from this, test cases written during QA testing are more detailed covering each and every requirement. Whereas during UAT, high level business scenarios are covered, making sure that the most commonly used flows/scenarios are working as expected.
So, coming back to your question. QA testing is more strict testing where you ensure that the system adheres to the requirements specified in SRS or FRS. I don't think that we should directly relate the QA testing with raising bugs. Raising bugs is not the purpose of QA testing but a by product of QA testing. You simply record the points where you find that the system is not behaving as per the requirements specified. You record such discrepancies as bugs and assign them to development team, so that they can work on the issues reported by you.
So all the discrepancies/deviations from actual requirements (which are reported in the form of bugs) are fixed by the development team and verified by the QA.
The software is handed over to the users for UAT once QA is satisfied that all the reported issues have been fixed (or at least most of the issues, such that they satisfy the acceptance criteria mentioned in the test plan). The purpose of UAT is to make sure that most of the commonly used business scenarios are working. If the users report any issue in a commonly used business scenario then that is a high priority issue for the users that should be immediately fixed. However, if there is an issue with a scenario that is very rarely used, then user might be lenient and can give you some time to fix that issue since that scenario is not going to be frequently used.
So, in short, whatever is specified in SRS/FRS is important during the QA testing and has to be verified during QA testing. Whereas in UAT, commonly used business scenarios are priority and should be working fine. Issue reported in such scenarios are important and must be fixed on priority.
I hope that answers your question. Let me know in case you have any follow up question.