1

With a recent, wild development of different libraries (mostly JavaScript), very frequently in the internet atmosphere, we come across with some awesome open source testing tools, that promise to help us in automating anything possible: web site functional testing, penetration web scanning, reporting, web crawling, working with data over to databases....you name it. Most of those tools are either sitting on someones GitHub accounts with package zipping to your machine option, or can have their dedicated web site with the download option. At my current position I was given several open source tools to work with: installing, setting up, configuring appropriately and providing the results (this is not Selenium or Jenkins....no). To be honest I wasn't and still am not a big fan of this approach and would like the tester to pick up the technology he/she most comfortable with. While having experience using those libraries I've distinguished 2 completely opposite sides:

  1. Positive side. Well, first of all, they are free to use. Neither you, nor you boss (what would probably make him/her happy), has to pay a penny. If you partially can make a tool working as it's supposed to, then the demo can be demonstrated to the team and your effort will probably be appreciated (sometimes in salary equivalent). You can also (not the usual case) find some tool community support on stackoverflow or GitHub issues pages since it's open source and there is a probability someone touched and tested it before.
  2. Negative side. From what I've learned so far is that very frequently those free of charge tools have a very poor documentation (and in my case, it's a real truth). Have you ever had a situation where following steps in a tool's documentation is simply not correct or outdated? What's your 911 call then? Stackoverflow or Google Groups? This leads to digging inside the code and making guesses of what's right and what's wrong with the particular action. Imagine you are comfortable with Java, or vice versa, with Python or Ruby, and then you are given a task to explore the tool written in Go and make it work somehow. Asking community support sometimes might takes days to get responses. I like to learn things, but not when it takes that much time to make a small part of a tool to function.

My question is not about particular tool that I can't make to work in a way it pretended to be according to documentation. Rather I want to ask how would you handle these situations? Reporting back to the management that the tool is not able to perform certain tasks it claims it should, or just keep trying (while probably wasting time) to explore it till I find a solution to the problem (not a guarantee of course)?

  • 2
    This is a very good question. Next time you may want a day or two to give a chance for people from other timezones to answer. – Peter M. - stands for Monica Apr 18 '18 at 20:35
3

Be more aware and selective

Is my main advice on how to handle tool selection. Don't just pick a tool 'cos it does the job today. Spend some time reviewing it. This happens to me a lot in my Ruby community where it seems theres multiple 'gems' for everything you can imagine. In cases such as those I use the following factors to help determine where I should start using this in my current toolbox:

  • Tests - does it have a test suite ?
  • Choices - what is the competition like ?
  • Update date - when was it last updated ?
  • Usage - is it used by a large number of users ?
  • Documentation - Does it provide good information ?
  • Complexity - What external dependencies will be required ?
  • Internal dependencies - what else is required for this tool to work ?

At the end of the day there is still risk and frustration, etc. but this can be minimized so the benefits are maximized by using some of the criteria above.

It certainly does mean doing more work evaluating a tool than just pulling it off the shelf and using it but that is just part of a responsible developers job.

If an existing tool has an issue and you are waiting on the open source community to respond then yes you state that fact. Its nothing to have to hide and is the truth. If it points out that you need to hire someone to code it then so be it.

You may need to carve out some time for 'tool selection' stories to address that you need this time and to make it clear and visible to the group at large.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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