Sustaining Rapid Software Testing Practices Within Organization

Posted by Albert Gareev on Nov 18, 2014 | Categories: Notes


This post and mind map are work in progress. I’m hoping to get the community feedback as well as further refine the ideas myself.

Stay tuned. See more contents below the mindmap.

Sustaining Rapid Software Testing

Below is the mindmap in [accessible] list format with my comments elaborating the points.


You’re a Test Manager. You had your team taking one of the best practical courses in testing. How do you make it stay and what are the problems? See also here.

Corporate training is a serious investment – of funds, but also project time and reputation of the manager arranging the training. And there will be expectations. To make a return of investment, one should consider means to increase “germination of skills” after the training.

Lack of Support

Lack of Interest

Lack of Engagement

Lack of Connection




I think, recognition within the community is pretty good. But within the industry – not really. This topic is an idea for brainstorming itself. As a quick thought, promotion of RST brand can (should?) be done in connection to products. You know – “this blog is powered by WordPress”, “runs on Yahoo servers”, etc. Of course, the trick is in virtually no difference between well-tested and untested software.


  • Context-Driven Testing community
  • Agile Testing community

Per my observation, there’s a degree of misalignment with the two and within those, but the direction is common.


This is currently a weak spot. Somewhat like a brand would greatly help – to make RST distinguishable and to ward off meaningless certification and standardization schemes.

What’s important to emphasize is the trap of easyness of binary assessment: if got [certification, training, etc.] -> qualified for the position.

External Incentives

“Demand – supply” is a proven instrument. Having set RST course as an asset and skills it teaches as mandatory both adds up to industry recognition and quality level of the candidates.

Job Requirement

Hiring process is really flawed, and many recruiters write about it. But let’s be part of the solution here, and create right job descriptions. Set right requirements. Educate recruiters on what we need. To be practical: I’ve used this example in recent hiring cycles.

Skills Requirements

  • Too often, almost always, job requirements require tool and technology knowledge instead of skills. But what matters is what testers make out of them. Tools don’t make the master.
  • Too often, almost always, job requirements specify delivery of artifacts with questionable value.
  • Too often, almost always, job requirements describe the motions testers go through, and only visible part.

Elaboration on the real testing skills would help both recruiters and job seekers. Recruiters will know what to look for and how to evaluate. Job seekers will know what skills to work on.

Internal Incentives

Position Requirement

Skills Assessment and Development

Gradual Implementation Plan


Implement Changes


Find Answers To What Stakeholders Care About

Demonstrate Value

Produce Tangible Artifacts


Improved Bug Reports

  • Problem Statement

Meaningful Project and Product Reports

  • Product Story
  • Testing Story

Useful Project Artifacts

  • Risk Catalog

Develop In-House Community


Yes, many employees don’t go to external events, but they still socialize a lot inside of the company. So in the big enough organization one could run internal meetups. (For small organizations, this might be a problem, but I assume that small fast-paced companies have different,  typically quite active kind of employees, so going external won’t be a problem for them).



Invite Speakers

Run Blogs

Do Workshops

Rapid Software Testing course and workshop is qualitatively different because of vast amounts of practical ideas, tricks, techniques, methods, and eye-opening exercises. It is very fast-paced. Highly condensed knowledge. In fact, it’s so un-academical, that adding theory afterwards would help people, because they need to un-learn and re-learn a lot. And while independent course takers usually have that drive taking them further, corporate course takers may need continuous support.

  • Weekend Testing Format
  • Testing Dojo Format
  • Group Reading and Reviews for books and articles

Assess and Grow Skills and Experience



  • Online presence
  • Hands-on (and brains-on) interview assignments


  • Performance in context
  • Job assignments





Stop Giving Useless Artifacts And Metrics

  • One response to "Sustaining Rapid Software Testing Practices Within Organization"

  • Justin Hunter
    18th November 2014 at 17:08


    Nicely done!

    I like the way you’ve highlighted some good, key, insightful ideas here.

    A couple additional thoughts:

    (1) For the problems you identified, it might be useful to ask “why?” (once or “5 times”) and potentially consider creating an Ishikawa diagram to assess the underlying root causes of some of the key problems. That might help you see ways that it might be possible to overcome those problems / barriers to successful adoption.

    (2) For the “Internal Incentives” section, I think there is also an important element of joy / personal growth / pride in improving one’s craft / intellectual curiosity that is a major reason that Context Driven Testing / RST ideas so powerfully take hold in the brains of many testers who are exposed to the ideas. I think it explains why CDT-focused testing conferences are filled with people who have real passion for software testing, for example.

    Inertia is a powerful force, but it is worth fighting against.

    Finally, an idea for your consideration… you might want to put a few calendar reminders in your electronic calendar (once a quarter for 4 quarters?) to check back and look at this blog post yourself.

    Good luck!


    [Albert’s reply. Justin – I appreciate your feedback and ideas. I sure will be coming back to this topic many times!]

Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported
This work by Albert Gareev is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported.