We have a number of teams, each with developers and SDETs. SDETs automate current sprint tests and, often, create tools/libraries supporting test automation within their teams. A year ago we started an initiative of sharing test libraries across teams. That started to work better than one generic test framework for all the teams, because people could pick-up from the common repository only the libraries they wanted.

However, with sharing the library comes not only reconignition but also responsibility: people who share libraries with other teams are made owners of those libraries. The goal was to have someone responsible for those libraries, when other teams report bugs or feature requests. Some people take this reponsibility lightly, other decide not share to avoid bothering with a new responsability.

How can we encourage people to share testing libraries with others and take ownership of them?


6 Answers 6


The thing is that taking ownership of these new libraries is extra work for these people. How are they expected to handle this extra work? Are they allowed to postpone their other responsibilities while solving a bug or adding a feature for these libraries? Or are they expected to just suck it up and do these things while also doing their regular job in the same timeframe? What I’m trying to say is that you should make sure that they have the time and other resources needed to take this ownership and that includes cutting them some slack with their other work when needed. If that’s not the case, you are asking them for free work and the only smart thing to do is not participate.

Secondly, doing a shiny new tool for their own use will always be more exciting and challenging than fixing bugs or adding new small features to older tools. So, you need to reward the ones that do so somehow. Either give the people making the best tools a bonus, or give them some extra free time, or whatever to make it appealing. Without an incentive most people will not voluntarily do what’s basically grunt work, and quite honestly recognition is not a big enough incentive.

  • 2
    The part about taking ownership of these tools is definitely true. I asked a similar question on the Workplace to this topic about a year ago (Except I wanted to share my tool), and now that several dozen people across the company use it daily, I have to dedicate a good deal of capacity for maintenance to it and adding new features. I would recommend if you try and get people to share their tools, approach it from the perspective of if they think the tool is ready to share.
    – Sidney
    Dec 4, 2017 at 19:03

Some companies structure libraries and tools development the same as open-source projects do, as it seems like a proven practise. It is called InnerSource and used by PayPal for example.

InnerSource is the name given to a development approach that applies open source > software practices to the way organizations' develop software internally.


O'Reilly has a free ebook on InnerSource, maybe it is worth reading for more idea's around InnerSource.

Things like "trusted committers" can keep your project going, a sole maintainer might get demotivated and be a major bus-factor.

How can we encourage people to take share testing libraries with others and take ownership of them?

Let (thought-)leaders in your organisation explain InnerSource, set some examples and document how to get started with it. Promote it as a benefit to all employees. Maybe even try to open-source stuff to get external exposure.


The simplest way to encourage this is by coding standards for all teams. Those standards should include commenting that works with a documentation tool, such as javadoc or the XML Sandcastle style comments.

With that done, the next step is to require builds to also generate the documentation (which is usually a simple flag in the build process) and configure deployment/test automation runs to publish the documentation to a defined network location.

With that and the libraries themselves in source control, everything that's needed will be shared semi-automatically. All that the team leaders need to do is include checking the comment documentation during code review.

  • 1
    We have coding standards and cross-team reviews -- that doesn't encourage people for taking ownership of the tools they share. People say: you can use our libraries if you want but we promise no support, maintainenance, bug fixing or implementing feature requests. It looks like the only thing they care is that the library works for their team and if it does not work for other teams it's not their business.
    – dzieciou
    Dec 4, 2017 at 13:28
  • 1
    If the source is available for all teams and the documentation is updated with each build, then any team can add to the libraries.
    – Kate Paulk
    Dec 4, 2017 at 16:47
  • Mechanical enforcement doesn't help with anything. It only leads to people finding ways around the mechanical enforcement (auto-generated documentation anyone?) or simply not creating the library in the first place (because now you've made it too difficult). -1
    – user253751
    Dec 4, 2017 at 23:13
  • @immibis I'm not sure where you're going here: the point of my answer is to use auto-generated documentation and share the library source for anyone who wants to update it to do so.
    – Kate Paulk
    Dec 5, 2017 at 18:49
  • @KatePaulk Your suggestions seem to discourage people from sharing, by creating more work they must do before they can share.
    – user253751
    Dec 5, 2017 at 21:42

Since the invention of money, it is easy to show appreciation.

Manager certainly has discretionary bonus fund. Let him give away few hundred dollars bonus every quarter for best tool library, as nominated by peers. Problem solved.


In my groups, code written by QA engineers are treated the same way as code written by software developers: it gets schecked into source control and bugs and feature requests get assigned to it as it does with any code.

Bug review meetings are used by management to decide which bugs get fixed when and by whom and get scheduled accordingly. The beauty of this is that management decides and schedules and prioritizes the work, and so the developer is not automaticaly on the hook to do anything.

If you treat your QA development as developmet, you shouldn't have any trouble applying all the development processes and principles already used by your company.

Hope this helps.


Taking a tool/script that works well within the constraints of a given user's environment and making it work well in more generic and diverse environments is significant work. Moreover it's not work that most developers would consider 'fun'.

The only way to motivate sharing is, as jesm00 mentioned, to take this additional work into account when evaluating their performance (e.g. are they allowed to slip their deadlines in their assigned duties?)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.