How do you mitigate the risk of someone leaving a company? Especially if they helped set up the automation framework that everyone relies on.
This topic came up during The Testing Planet Episode One.
I once remember leading a team and hiring a contractor to set up part of our framework cos âthey had the tech skills that no one else hadâ. It was a disaster. They were great and helpful yet it wasnât possible to train anyone else up as we were all focused on other things. It was a while back yet if my memory is correct, we had to ditch the lot when he left.
I reflect that it was fascinating that we could do that and get away with it. What a waste of money. No excuses really, just that we were so focused on delivery that we didnât give enough attention to this person and encourage them to train others. It was all about âwhat coverage are you at now?â
Fortunately, I went back as a contract Quality Coach much later and theyâd spread much of the testing effort across delivery teams so that wouldnât happen again â devs/testers pairing to write integration tests together. It was something Iâd put in place just in my own delivery team before leaving the first time round and it was cool to see it had grown across teams.
Probably I can suggest the most obvious and general ideas but they are a good start anyway if you want to mitigate the risks of someone leaving a company itâs not my or anyoneâs stories but just common sense
Compensation packages are competitive (higher than average or median) in your industry/niche and location - salary, benefits, and other perks.
Opportunities for team members to grow and develop their skills - training programs, mentorship, or clear pathways for career development and promotions within the company.
A healthy work-life balance - flexible work hours, remote work options, or policies that encourage time off, vacations, etc
A positive work environment where employees feel valued and engaged - team-building activities, open communication channels, recognition of employee achievements, etc
1 2 1 meetings with employees to discuss their job satisfaction, any issues they may be facing, and their future goals.
Itâs important to share knowledge within the company to reduce dependence on any single employee and ensure that multiple people can handle key tasks.
Proper documentation is crucial as a backup plan in case a key employee leaves the company. It can also be helpful for points 2 and 3, together with knowledge sharing (point 6).
Every employee is unique, so itâs important to tailor your strategies to meet the needs of your employees. These points, I believe can help reduce the overall risk.
Having robust documentation. If you buy furniture from a store, you donât need the designer or builder to come teach you it. Thereâs documentation to follow. Explaining how it works, how it should be put together and more importantly, what it should do and what you should never do with it.
We are working towards Tests being Self Documented. Each Unit Test, Integration Test and E2E test should be easily readable and gives the full context. Tests should be the codes documentation. A series of specific but complete tests that cover many different scenarios and outcomes.
The same goes for manual test cases. Test cases should be complete and thorough and should act as the âhow-toâ guide for a given service/prodcut/project. They should be varied and setup as a âThese cases should give X outcomeâ for positive and negative test cases.
Iâve heard people describe their tests as self documenting but every time Iâve read them they just never live up to the label. Full context is never given unless itâs attached to a doc written on why we did this in is way.
Point is to have multiple sources of documentation that paint a fuller picture.
Early on in my career I deployed automation frameworks that Iâm pretty sure stopped being used right after I left.
Later in my career I learned to bring people up to speed as I deployed the code. Work with them to become self sufficient at debugging, updating and even writing automated tests. This way when you or someone else leaves the knowledge is still there and so are the processes.
One thing Iâm getting better at is writing documentation, not just the how-to but the decisions / context for why. Confluence allows individuals to publish blog posts. I wish I had documented/ written about a ton of decisions and why we do certain things this way but not others ways. Itâs a form of wiki culture and it helps companies create and store institutional knowledge.
Iâm sorry, but the wording and style of your comment are extremely similar to the style that ChatGPT would generate. Is it really a good idea to use a large language model when someone asks about personal experiences here in the community forum? I believe that almost anyone has access to this kind of information, and itâs not adding any value here.
@lubos.ulicny First of all, youâre wrong. Here particularly I didnât use ChatGPT at all, and if you use ChatGPT often then youâll notice that style isnât like ChatGPT would generate, wording⊠kinda yeah. To be clear, I google some stuff and used a couple of points to add here and used Grammarly to correct spelling, grammar and style mistakes (Iâm not a native English speaker and I always check and correct my publications on any platforms, I usually have a couple of issues).
Secondly, I use ChatGPT often when I write not to generate texts or ideas but to check my writing which means I write the whole draft (more often this is just some parts of my articles or a paragraph) and check it for mistakes and sometimes I want to improve readability or change style but part of my prompts is always âdo not change a lot or add new ideas, stick closer to my draftâ. And I always read and usually edit a lot of the results of any work with ChatGPT
Sorry guys for doing this in this thread, if admins believe my posts are inappropriate - just delete them.
recently Iâve been thinking more about setting up âpeeringâ systems. Everybody should have a peer that can cover on various forms for absence. To reduce bottlenecks and dependencies on single persons.
We have recently struggled to find a replacement tester, due to the tester taking a long vacation. We have finally sorted it out, but since the tester didnât have anyone else on the team, it became a challenge due to customer deadlines during the vacation period. (vacation was approved first, and 6 months in advance).
One solution could be to have your juniors and entry-level people shadow the experienced people. Iâm sure that will be beneficial for both parties. Itâs an investment, but so is missing deadlines and building frameworks that are not used.
Thanks for raising that, @lubos.ulicny. Feel free to use the flag feature on this forum instead of making a public accusation â the flag goes to us admins and we can review it. I do appreciate youâre attempting to ensure that replies are human. Letâs keep how we interact with each other as human and as kind as possible.
First of all, it is an issue in testing, but also on any other activity of software development (and probably other fields as well).
So, in that context, letâs take the example of what developers tend to do in well organized teams. Theyâre using principles and activities that exist at least since Extreme programming was around. Letâs name at least Pair programming AND Code review. I insist that weâre talking about both of them, and not just one or the other. In addition to that, team stories refinements and estimation are in place, where more than one dev (in addition to other profiles) can raise their concerns.
Also, very often, itâs good that each improvement / change / bug of a service or a specific part of a system can be handled by any of the devs within the team. Of course, there might be a specialist and for more complex change (in that case, I would even recommend that the specialist should be the navigator and not the driver).
There are other points like documentation, comments and others to mention, but you get the picture.
Testing (and again, other activities) should be treated the same way. And of course, itâs not just a matter of individuals, itâs a team effort and even an organization effort. If devs are able to do it, so should testers. It can even be pairing between devs and testers. I often have those cross functional pairing sessions and it carries lots of benefits.
Having been in the business since late 80âs I saw this starting some years earlier in Uni. This kind of messes is not in any way exclusive to test automation but it has some ingredients which makes it even more stupid. And yes, I have seen this many, many times.
There are a number of stupidities here:
Managerial, managers seeing employees as âresourcesâ, thinking that every hired âtechnicianâ can do, and have a drive for every technical aspects. Here - being a good tester does NOT NOT NOT entail being a good programmer. And test automation is not testing, itâs programming. As a manager, I have had to deal with messes caused by this macho attitude. Test automation really working longtime is rock hard. It was hard 1990 automating testing of CLIâs and its hard now.
The general shortsighedness everyone, including myself has, when taking on a project of any kind, even outside job. The nature of a project is to get something done. But very few SW tasks ends.
A kind of stupidity that really peaked the years before starting in the business, at Uni. Lets call it technician arrogance. You think you are the best programmer or tester or maths anything in the world. And worse, have the attitud of everyone else around you is supposed to be one. There is a drive in it, granted, you strive to become the best. But any sofware enterprise larger than a personal project is about people. The really good technicians knows this, the ones that aint wannabees, the ones that are good. Writing a âframeworkâ for test automation for testers that aint really programmers is hard. I have seen some good examples, but far more bad ones. And when the guy leaves you end up with something that noone knows how to maintain.
This is probably one of the most consistently âtalk the talk but now walk the walkâ thing I have experienced over the decades in the SW business. Documentation. And itâs not better now than in the 80âs.
Youâre absoutely right, but being in all kinds of organisations, producing all kinds of SW, I have never seen a documentation of SW really working, test automation in no way better, even if test automation really need way more documentation than other sw products.
As an example of another approach:
I worked as a tester in the beginning of the 00âs in a team of really good Java programmers. That was probably the best maintained SW products Iâve seen. If someone left, the company just hired a new java programmer. And since they wrote the java code strictly in a manner supposed by java programming, the code was more or less self explaining. Think test automation have to strive for that - IE test automation is a very specific skill and the automation code should be easily understood by other test automation engineers. Manual test is learning by doing. Every troubleshooter should be all over the place, everyone should strive to know every part of the systems. Thats a very different person than the programmer.
As for troubleshooting, manual test, exploratory test, the testers should just jump around as much as possible among the products maintained by a sw department. âEveryone should be able to test everythingâ. Being locked up in say automation of some specific product does not help.
Some people should be test automation engineers and some manual testers. Some few both.
To answer the question in the title - To hire people having the skills and drive for the tasks needed to be done, doing it in the state of the art of that thing. If someone leaves, either you hire a new person with that skill or someone having the same skills work overtime. I have seen this working in many sw organisations over the years. Focus on the people working.
Plato - or rather Socrates - did 2500 ys ago get a lot of things really right in The Republic. Every person should be doing what that person is good at. Good reading, actually!
As Iâm reading this, I have a user manual or wiki printed out next to me for how to use a particular tool. Apologies to anyone who works there, but the documentation time wasted documenting an obscure feature, is the core reason that I no longer believe that wikis and documentation really solve anything. A few commenters, Anders and Nicolas among them, have already pointed out how if people are too busy to collaborate and learn, that itâs pointless. Even having documentation that takes up space and eventually grows stale starts to become a source of mirth and also of false-trust in it. Why does anyone need an entire page just telling you how to logout if you should get logged out every 30 minutes anyway? Why waste the paper?
I do love how the writer here even includes the word âhappyâ in the documentation, something I try to never do, because that is how I can tell when a document was written only as a document writing appraisal objective, I would hope ChatGPT would never do that For me, the real mitigation is what Simon hints at, invest in your peopleâs collaboration skills over their technical skills.
Sadly Iâm sitting here right now writing up my quarterly appraisal, and guess what skills and goals are missing? I love wiki writing, but we have to stick to reasons and facts.
itâs not my or anyoneâs stories but just common sense 
.
