A Tester's Life is constant proofs


QA/Tester's personal log: 2025.254


Time flies, it is Thursday, and the week has just zipped by. One may wonder what a Tester's day looks like. Well, for me, everyday is like 'thesis day' -- 




  • (a) you volunteer to take up a project (i.e. subject_under_test: could be a super_system, sytem, sub_sytem);  
  • (b) pick your way into it ('pick' verb, like using a pick-axe); learning everything you can about the subject_under_test (i.e. explore it), and 
  • (c) compile a test_report of your evaluation of the subject_under_test ;

Note that (c) is not just a list of ... 

  • what it 'can do' 
  • and 'not do', 
  • it also specifies under which scenarios it behaves as such, 
  • and what inputs triggered which behavior. 
  • It also requires you to provide proof of your claims: this comes in the form of vids, pics, urls, files, software builds -- virtually anything that could be an artefact (yep, archeologists don't have a monopoly on artifacts) showing proof that supports your conclusions.
    • (All this 'proof/proving' makes a QA/Tester's contribution to Gdrive overwhelming -- at least in my experience -- such that i've started to zip some archival stuff to help with the downsizing (but only as time permits -- which tbh is only a 0.9% chance of ever occurring. 😄)
  • also required is a list of any {anomaly, aberrant behaviour, intermittent glitch, issue, or anything suspicious} found, each one with
    • its STR{steps to replicate} as much as possible, to recreate the issue
    • and again, a host of artefacts to prove that your findings are not just ghosts, or illusions of the mind. 

In  theory this is how detailed a QA/tester's work should be, but in reality i have to abbreviate certain things because of time constraints.  This means management  will have to accept that...

  • mostly only the 'summary conclusion / evaluation' is in English or lay-speak; in my case, it is more often an oral summary😁
  • the rest of the Test_report is jargony and in QA shorthand; this is because to save time, i find the need to write in the most efficient way possible: 
    • using testmaps / testlogs in table format, 
      • laying out 'build version' / 'does' / 'doesnt' / 'scenarios' / 'risk_level' / 'issues' conveniently, 
      • i find this format very conducive to on-the-fly editing
      • and also it groups tests in a coherent relational manner
    • repurposed symbols and abbreviations that translate to {specific terms, operations, phrases} known to the QA/Tester 
      • this 'shorthand' saves time in writing, and
      • it condenses the document, while keeping all significant details (a 12-pager can be condensed to 6 or even 2 ? ); 
      • understanding of the jargon can be passed on to fellow techies, with the aid of a glossary. This makes any knowledge transfer easier and more efficient. 

As can be gleaned, it is no mean feat to be a tester; evaluation doesn't come without measured or monitored proof. It is like doing a Euclid, Kepler, or Bayes on a daily basis.  

Comments

Post a Comment

Popular posts from this blog

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

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

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