Transient WIP vs Permanent Logs (about title-only-tickets)

Personal take: when your development team (coders+testers) is small (and i mean real small, like less than 10 people), you know you got each others' backs.

And so I've accepted the 'title-only-ticket' (especially one with a descriptive title), given that whoever created it can and will reliably discuss it with the group, or visually demo it, with a greater than 90% certainty of replicability. It is then up to me to docu my own understanding of the issue at hand, repeat it to them, and once agreed, my docu becomes the standard by which this issue will be judged.


The above scenario mostly happens within mature teams, i guess.


A most irresponsible move is to create a title-only-ticket then halfway thru your demo you can't remember the STR(steps-to-replicate) to show everyone the issue. That is an irresponsible waste of everyone's time.


A team that can abbreviate it's WIP(work in progress) is a great team; after all, WIP is transient -- however we go about it, if it works, then it works! The nature of the task at hand dictates the workflow [esp if the dev is crammed].


But a QA without docu/logs is unsustainable; because QA is about measuring a product at a specific point in time. Which makes *our* artefacts always substantial and pertinent, never transient. [And when crammed themselves, i wouldn't be surprised if QAs abbreviated their logs too -- without loss of content or meaning, of course.]


With that said, I wouldn't attempt to close the testing cycle without docu. Because when the product starts to fail at any point after testing, the QA needs every backup artefact he/she can find.


If Devs have their git repos , QAs have their mastery of artefacts [documentations and logs included].


source: https://www.linkedin.com/post/




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

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 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