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 99% 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 through 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 the process works, then it works! The nature of the task at hand dictates the workflow [esp if the dev is crammed]. Hence i can forgive devs for skipping documentation in jira, as long as they can explain/demo it to me verbally.


[it's amazing how they can sometimes explain it to me under 3mins, vs the 6-12mins it takes for them to write it down -- and this has happened with major and critical issues we've encountered.]


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 we get crammed ourselves, i wouldn't be surprised if we QAs abbreviated our logs too -- without loss of content or meaning, of course.]


With that said, I wouldn't attempt to close the testing cycle without test documentation. Because when the product starts to fail at any point after testing, the QA needs every backup artefact he/she can find -- to show weather (a) the issue is out of scope ; (b) something broke between last testing and the buggy version ; or (c) find out how we missed the bugger.


That's why if test logs/docus are not yet completed, i'd say the test cycle is still open: we have a Test Drag on our plate, and we should address it, rather than sweep it under Jira's mountain of trash.


if Devs have their git repos ;

QAs have their repository of artefacts [documentations and logs included].


That's how important test documentation is for QA / Testers.


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

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