I posted a new article about high level QA concepts posted on the Code Project here.
Excerpt:
Working with QA can often be an adversarial situation, but in reality, it shouldn’t be. The developer, customer, marketing, CTO, CEO, accounting department, and so forth, are all stake holders in delivering a functional, aesthetic, secure, safe, and easy to use product. This article can only scrape the surface of what those six terms:
- functional
- aesthetic
- secure
- safe
- easy to use
- accurate
actually mean. Depending on the product being developed, they will be weighted differently as well. Security may be paramount in a server handling REST requests, where aesthetics is irrelevant because there’s no customer facing UI. Safety may be the priority in a piece of medical equipment or an engine cut off switch on an airplane. Safety may be irrelevant in a mobile game application (unless you want to make sure the person isn’t crossing a street or driving while playing the game.) So, depending on the application, you may be addressing some or all of the above concerns, and the QA process should provide the right balance of coverage based on how those (and things I’ve omitted) are tested.
Ultimately, the QA process is like a mathematical proof – it consists are formal, repeatable processes that validate and verify the application.
Marc Clifton 