Quality Assurance, Confidence Levels, and Testing

I agree on the 'quality assurance' comment -- semantically and practically it is not a very useful term. 

(a) semantically, any product will have an inherent level of Quality [0 <= Q <= 1] as soon as it is released in whichever environment. A level of Quality is already 'assured' as soon as the software product exits the compiler. 

(b) practically, a 100% assurance of High Quality [a score of 1.00] is impossible, not even on a quantum level -- as soon as we observe something at that level, it changes the specifics of what we were trying to observe.  


However, on the confidence/acceptance scale, it must be agreeable that Testing directly/indirectly ascertains the Confidence level perceived from using the SUT(Subject Under Test). This would be attested to by 'tested' cars, planes, and rockets -- and by extension, software products. These products are not perfect 100% Confidence Level ["C" score = 1.00] but empirically also not Confidence Level 0. Their C Level is somewhere between 0 and 1 ; the lower the score, the more likely the product is not up to expectations. And the converse is also true.  


In conclusion, it would seem every usable product out there has reached a certain level of confidence/acceptance -- and that would be directly or indirectly through the efforts of Testing. 


In most cases, Confidence/Acceptance Level can be perceived as an inference of Quality. The two appear to be correlated but semantically not the same. Confidence/Acceptance is UX-centric, while Quality is SUT-centric. 










trigger:  https://www.linkedin.com/posts/maaike-brinkhof-1942b725_the-mainstream-tech-industry-has-done-testing-activity-7429464520768671744-UL_X?utm_source=share&utm_medium=member_desktop&rcm=ACoAADVOWcIBc7VFWTKgh6Qof566qxbgu2eqJDQ


Comments

Post a Comment

Popular posts from this blog

The phenomenon of QA(quality advocacy) in Test-PhaseSpace

Image
  Quality Advocacy                      \___ 3rd tier/level --- designers,  coders                      \___ 2nd tier/level --- quality advocates                      \___ 1st   tier/level  --- grassroots testers  ================= definitions:  ================= ..Quality [ Q ] = the state of the product (high or low) at any given time (m).  ..QA [ Quality Advocacy ] = the monitoring/measuring of quality to know quality ; unless it is monitored/measured, quality [ Q ] cannot be known. Quality Advocacy extends to all 3 tiers/levels.  ..QA [ Quality Assurance ] =  working together  as a  Development Team (coders + testers + proj.mgr + designers + etc.) which will always deliver a specific level of quality. ..software tester = 1st level, grassroots interactor [someone...
Read more

do QA/Testers contribute any value to the Product's Quality?

Image
With all due respect, my take on the matter is:  a.  hypothetically,   if a teamA{devs+testers+designers} >> work together == resulting in a product{Quality = 0.95 good}  b. if same teamA{devs+designers} minus the {Testers} >> work together == resulting in a product{Q = 0.65 good} c. then it means the product{Q} suffers a {0.30 good} reduction without the {Testers}  d. so, mathematically, the Testers seem to contribute to the Product{Q} an exact value of "N"  assuming the Devs work on the findings of Testers e. if Devs don't work on the Testers' findings, then the testers still would've contributed their share to the product being built , but the negative impact of the Devs' under-contribution will adversely affect the overall Product{Q} -- making {Q} fall below agreed values.  f. The relationship of contributions from actors {designers,devs,testers} is apparently non-linear --otherwise things would've been so obvious, this wouldn't be...
Read more

Pyramid, Honeycomb, Feather Testing Models

Image
How much time should be allotted to each level of test activity (unit test, integration test, system test, end-to-end test)? it varies; but definitely just enough to get the job done to an agreed level of Acceptance Credence.  A model that is not adaptable to the task at hand constricts development, and needlessly constricts the actors themselves(coder, tester) -- such that, either  (a) the team starts to get coerced to follow the model, sacrificing any innate efficiency; or  (b) the team ignores the model and  lets the nature of the task dictate the most efficient work flow.  The nature of the test_paths themselves would provide the impetus  to place  emphasis on either  (c)   integration tests (e.g. majority of the test_paths are integration subsystems); (d) a balance of unit tests and end-to-end tests (e.g. the product is simple, or a self-contained supersystem); or (e) a balance of unit, integration, and comprehensive systemic tests ...
Read more