Tester's Musings

If i was assigned to multiple projects as a software tester (and the only tester) i should NOT succumb to pressure and 'juggle.' Each one has its own release date, and the PMs must decide which one takes priority release, which in turn dictates which one takes priority testing. { Testing to a specific degree of product acceptability should be agreed first; then the rate/speed of testing follows the degree of acceptability; subject to the release dates of improvements and fixes; which in turn is subject to the complexity of the feature/s being developed } cross this with { N projects } and we see that the 'quality' of the product/s is more related to the 'degree of acceptability' and is never derived from 'juggling between projects.' source

  i have found out that after a while -- where the tester has proven his mettle by his documentation, artefacts, and proven investigative and evaluative capabilities -- more often than not, respect grows between Dev and Tester. Devs start to not dismiss our bug report anymore -- they say 'it works on my machine, so i must be missing something; can you show me?' https://www.linkedin.com/feed/update/urn:li:activity:7250131780119224321/

  my answer: i use it where it matters (removing unwanted background from an image, creating voice over from text).  for testing, the current status of AI seems way too low, i haven't considered it as a partner just yet (but i'm open to be enlightened;)

 Bug Report1 (pers template) .pic (issue vs expected):  ..STR:  ..expected: ..attachments: (scene,json,etc) .vid (issue @ time, @time, vs expected): ..expected: ..attachments: (scene,json,etc) ================== .affected: ..BUILD_VER ...( Windows Native (KB/Touch), Webgl(KB/Touch), iPad, Android, portal, CLI ) .n/a, not affected: ..BUILD_VER ...( Windows Native (KB/Touch), Webgl(KB/Touch), iPad, Android, portal, CLI ) .untested, might also occur in: ..BUILD_VER ...( Windows Native (KB/Touch), Webgl(KB/Touch), iPad, Android, portal, CLI ) for fixing / triage: .Blocker,Critical,Major,Minor .Reason:

================ 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])

 I find this quite true, from personal experience: I find it more productive when testing with an independent mindset, even when part of a dev team. And actually, everyone appreciates the resulting product evaluation-- positives and negatives included. A strategy where a coder tests his own work plus a test specialist evaluating the end prototype -- doesn't seem superfluous. Each brings a unique contribution to the quality of the end product as a whole.

That's why i have since veered away from "who made the mistake". It evolved into: "there is an issue" observed in the product under test -- which is due for "further fixing" -- and fix it / retest it, everyone definitely gets a hand doing. How we got that issue in the first place is a matter of retrospective (or introspective, for very very small teams 😅 ). Consonance between the tester's perspective and the BA's understanding of the product/feature(s) is actually under the tester's purview. Where the tester's questioning puts the BA on edge, that is one weak spot in the product development. That is why as an in-house tester, i don't limit myself to just chats with Devs. I go ask BA's, PO's -- just about anybody that can help answer my queries -- about their expectation of the product/feature under test. And then report any expectation incongruences so we can iron out a wholistic view of what is expected of the feature/prod...

  So why hire a tester? It really will depend on what the tester would bring to the table.  In the case of his coffee, if he is asking "will this sell to the masses?" then what he needs is a test of its appeal to the masses. And this means he can't be hiring one, but many testers of that specific taste profile, to get a probable evaluation representative of the target demographic's response. If he is looking for an evaluation of the coffee's "avant-gardeness" then he would need to employ a coffee connoisseur. With the connoisseur's provable taste grade, one coffee tester will do; but a duo or trio independent of each other would add more depth to the coffee evaluation at hand, providing better results.   When a Designer tests, he/she will invariably test for design flaws; designers can't help it, it's their thing -- part of their set of heuristics that make them who they are.  When a CEO runs a test, his/her background (tech or otherwise) wil...

UNDER CONSTRUCTION Note1: the equations presented herein are rudimentary; further inputs / corrections / suggestions are welcome. Note2: although this article was written from the perspective of software testing, we believe this can be expanded to encompass all testing phenomena in general.   Summary:  this article tries to describe testing using a Confidence Scale, with the various stages interrelated through mathematical equations. As a prerequisite , we base on the following assumptions:   Assumption#1.   confidence/level/quality scale: from 1(low) to   10(perfect), effectively divided into three ranges: Low -c onfidence(1-3), Medium - confidence(4-6), High - confidence(7-9), 5 = median - confidence/level/quality 10 = " perfect -confidence"  which will be generally accepted as highly  unlikely  to be attainable . (To those familiar with the Kepner-Tregoe method of problem / decision analysis, this scale may sound familiar.)   Assumption#2....