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

 

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 whose work makes him/her interact with the subject_under_test closely on a daily basis, who is therefore in the most probable position to provide an assessment of the subject_under_test ] ; may also be known as the product assessor / test_path executor. 


..Quality Advocate = 2nd level of Q.Advocacy, a senior test lead/manager, whose task is to aid in discovering further modeling perspectives for the subject_under_test ; may also be known as the test_path assessor. 


..designers,coders = 3rd level of Q.Advocacy: the conceptualizers and builders of the product / subject_under_test; may also be known as data plotters, and test_path creators


=================

relationships:

=================

..the relationship of Quality Assurance << to >> Quality Advocacy --- strictly speaking, no causative link. 

..the product's state (high or low quality) is always sure to exist [assured] every time the development team delivers a product. Advocacy is not required for a product to have an inherent state of its own. 


..Quality Advocacy is linked to Acceptance Levels because it is a monitored / measured event;  

..if Q was not monitored/measured, there would be no point comparing product_A to product_B, nor even comparing an earlier product_A ver.1 to a more current product_A ver.2. 

..and precisely because monitoring/measuring Q requires test activity [test_path execution ; test_path assessment ] --- Quality Advocacy is inseparable from test activity ;


..sidenote: a test_evidence [generated by test_path execution] -- by inherent definition is an artefact of monitor/measure of the event Q ;  only by the test_evidence can an Acceptance Level / Assessment be ascertained of the product / subject_under_test ; 


..coders are test_path creators ; but the corollary phenomenon of test_path branching [ which results from interaction with environmental data points ] is generally outside a coder's initial scope of control, in direct proportion to the complexity and probability of branching ( a.k.a 'ramification' ) ;  oftentimes, the most effective way to ascertain test_path branching is simply to execute, measure, and monitor the test_path ramification itself. 

..full test_path ramification (especially the high probability ones) can never be fully foreseen by the coding process alone.


=================

summary: 

=================

in Test-PhaseSpace:  

1. 'Quality Assurance' is an obsolete meaningless term, equivalent only to product delivery ; 

2. 'Quality Advocacy' is a more meaningful term as it has causative relationship to higher Product Acceptance Levels ;

3. 'Quality Advocacy' (measuring and monitoring) has its foundation in test activities; and is inherently practised by all 3 tiers, consciously or subconsciously 

4. high test_path complexity inherently produces high probability of test_path ramification that is beyond the coder's initial scope of control. (this is why bug fixing exists, distinct and apart from the initial coding effort)

Comments

Post a Comment

Popular posts from this blog

updated: Regression Tests as a normal part of day to day exploration / Regression Testing

Image
  Even before i heard of CICD, i had already coined the term 'continuous regression' in our office. For me it means 'testing for regressions' are not a specific activity, but incorporated into the testing/exploring process itself.  In the Hypothesis of Test Phase Space, every dot in that space represents a state of the Test (one dot an input, the other dot an output). And every line connecting those two dots is a Test Path. Each line comprises of multiple other dots between the two end-dots: these are potential branch points to other dots (linking to misbehaviour-outputs, or linking to other test paths) such that while exploring current code changes/fixes it is inevitable that some of these code changes may/might be linked to other parts of the product. It is in such context that i couch continuous regression testing.  Continuous modular regression testing should be part of normal exploratory testing. How fast and how thorough should these tests be? As speedy as the deg...
Read more

The Quality Advocate (Test supervisor / manager / lead)

Image
A Quality Advocate isn't / shouldn't be about auditing the work of your fellow testers.  The work of a Quality Advocate should be to check the current testing procedures vis-a-vis the product/prototype under test.  When you have testers testing under you / for you, the supervisor's role is not to check if the tester tested the product properly. Because the tester has already been coached to be critical-thinking, and exploratory -- so assuming his/her evaluative report shows exactly that -- then rather the sup's job is to see if there's an expanded way to model the product under test, to give a more justified evaluation.  What if we find there is nothing more to expand? Then either (a) you, as a supervisor, have failed in your task; or (b) your test team is above par excellent.   note: 'justified' :   General Context: In a general sense, "justified" can mean that something is reasonable, logical, or well-founded. For example, "Her concerns were...
Read more

Test Report1

Image
================ Test Report --------------------------- Product info: (what is it we are testing? ; complete info) Product Eval: (what can it do ; can't do ; suitable for what ; product claims vs product capabilities) Test_Map, Results: + behaviours, - behaviours, AssocRisks -- in table form Supporting_Artefacts(evidences[vids,pics,files,urls,etc])
Read more