preload

Sustaining Rapid Software Testing Practices Within Organization

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

Notice

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.

Problems

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

 

Ideas

Recognition

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.

Community

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

Industry

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

Solutions

Implement Changes

#GradualTransformation

Find Answers To What Stakeholders Care About

Demonstrate Value

Produce Tangible Artifacts

#GradualTransformation

Improved Bug Reports

  • Problem Statement

Meaningful Project and Product Reports

  • Product Story
  • Testing Story

Useful Project Artifacts

  • SFDiPOT
  • Risk Catalog

Develop In-House Community

#GrowSkills

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

Confer

Present

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

#GrowSkills

Hiring

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

Employees

  • Performance in context
  • Job assignments

Stop

Demotivating

Isolating

Templatizing

Stop Giving Useless Artifacts And Metrics


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

  • Justin Hunter
    18th November 2014 at 17:08

    Albert,

    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!

    Justin

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

  • Leave a Reply

    * Required
    ** Your Email is never shared

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.