Tester's Musings

What's with the topic of rushing Test Teams? i think this is the 3rd one in a row now? Do we forget that evaluation is a critical thought function? i wish there'd be other questions better suited for Test Teams to answer. The question of 'rushing' Test Teams is very counter-quality. Every time they 'rush' they tend to suspend their critical thinking. Test Teams should be given the chance to give their estimated timeline of completion, and people should respect that. Shortening an already lean test estimate is ridiculous.  ( link )

I would simplify it as: Activity: Testing; Doer: tester, in the categories a,b c.: a.Tester who uses code, debugging tools, and/or other greybox tools: greybox/coding tester b.Tester who doesn't use any code, nor greybox tools: blackbox/noncoding tester c. Developer who does unit tests, or does system troubleshooting: whitebox/coding tester. (Most professional testers would thus be either greyboxers or blackboxers; while whiteboxers will almost certainly be developers)  it's like, an Engineer testing machinery: either by using fancy gadgets or just by doing the old 'tap it, run it, look, smell, and listen.'  Maybe tester-life would be much clearer, if we go back to our roots of white, grey, black. 

  i can give the stakeholder the current Test Eval in progress. That's as raw as it can get. That's also the state of acceptability of the product as we know it -- the 'quality built into' the product at that time. Take it or leave it, but that's it.  When we say 'it has Y degree of acceptability', we mean we have 'tested' it as acceptable to that degree. How else can we know unless we test it?  We shouldn't get the illusion we can have a high degree of acceptability/dependability of an untested/improperly tested product. There's 'absolutely' no way of knowing without testing.  ( link )

  Although i don't use formal test cases (i kinda use shorthand test maps in table form) i group my testing by feature, which gives it a wholistic, systemic approach, to make it coherent and actually make sense (seeing it from the prospective users' POV). Unless i approach it this way, testing would be piecemeal, and would lack relational cohesion.  Which goes for test documentation too. Grouping them together makes for more coherent and meaningful regression tests while exploring the module under test. ( link )

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

'Tests prevent bugs.' -- from a tester's POV, if anything, running tests 'discovers' bugs/issues, they never prevent them from appearing :) 'Testing a document' however (i.e, reviewing a feature written-up to be developed) i find this to be a layer that can be done without. In the end, we should be testing the 'product' not the 'document.' And testing the 'concept' during the design stage is actually a lot better than testing the document. Involving a tester to mentally 'mock-test' the concept does some good in the design phase, but there is still a pitfall -- whatever 'document' that comes out of that 'design-phase testing' will not be the basis of the actual test run approach. why? because once the 'design-concept' gets into 'code-form' and the devs did their unit tests based on the design-phase test, it is still the end-tester's job to test how the code fares out there in the wild: an...

In my test report i don't use pass/fail wordings anymore. It's an evaluative report, so i detail the current state of the app as it is: what works acceptably, which feature/s exceeded expectations, which ones need more development because certain scenarios were found that put the app on edge. This should have been coordinated with the DevTeam in advance, because at the end, the PM should be able to expound on the revised timeline: highlighting the complexities discovered which still require deployment of more enhanced fixes.  A demo of the working product is always helpful, to showcase current achievements that prefigure the app at its completion.  When giving bad news, PM's would do best to focus on remedial positives, without giving false hopes.  For the tester? We just dish out the blunt truth all the time.  (https://www.linkedin.com/advice/0/your-testing-results-dont-meet-client-expectations-wj9tf?trk=contr)

Testers don't build quality into the app. Devs do. Testers evaluate the app (at any stage) and send it back for fixing as needed -- in that way we 'contribute' to the quality of the product. Testers are responsible only for evaluating the product at hand, and only to a degree of certainty. It's the Team (Devs+Testers+et al.) together who are responsible for building the product to the agreed degree of acceptability. Let's cut the finger pointing and move forward, please.  (  https://www.linkedin.com/feed/update/urn:li:activity:7259216033884839936/   )