your post sounds quite biased.
1) Every now and then (for the last 20 years) a new tool pops up that promises easy to use test specification without any coding knowledge needed. None of those tools have lived up to their promises.
2) You should compare your tool with Serenity BDD, CodeceptJS or any other high level test suite. Selenium and Puppeteer are merely the drivers that speak with the browser
3) Given that more and more teams learn to work agile, testers will be able to code and coders will be able to test. That renders a dedicated tool for people that can not code useless
4) I can code. I have experimented with a few point and klick test tools. Your approach might be of some use for tiny test suites which have no relevance in the real world. Once a test suite becomes a bit bigger there is no alternative to code tests.
Thank you for taking the time to write that comment.
CodeceptJS and Serenity BDD are just some libraries.
Selenium is also just a library.
The open source and zero license cost nature of such libraries is attractive when compared to the license or subscription costs of commercial automation solutions.
But there is more to it than just that when you look at the cost of implementing an automation solution.
For example, Selenium is open source and free, however building and using an automation solution on this ‘free’ software comes with some real costs:
1) The open source tools/libraries provide a starting point but you still have to write code for test creation, management, execution, handling errors and reporting. Note that this is over and above the test logic that you want to automate.
2) If you are looking to test integrations with back-end systems and external systems via API, you have to build in support for that into your framework.
3) If you are looking to implement a continuous testing solution, you must add to the above effort, the effort of building integration with DevOps or CI/CD tools.
4) Also to be considered are the costs of building and managing an infrastructure to run these tests. These costs are likely to go up as you scale your infrastructure in order to support increased test volumes or to increase the pace of testing.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
@klaus ,
your post sounds quite biased.
1) Every now and then (for the last 20 years) a new tool pops up that promises easy to use test specification without any coding knowledge needed. None of those tools have lived up to their promises.
2) You should compare your tool with Serenity BDD, CodeceptJS or any other high level test suite. Selenium and Puppeteer are merely the drivers that speak with the browser
3) Given that more and more teams learn to work agile, testers will be able to code and coders will be able to test. That renders a dedicated tool for people that can not code useless
4) I can code. I have experimented with a few point and klick test tools. Your approach might be of some use for tiny test suites which have no relevance in the real world. Once a test suite becomes a bit bigger there is no alternative to code tests.
Thank you for taking the time to write that comment.
CodeceptJS and Serenity BDD are just some libraries.
Selenium is also just a library.
The open source and zero license cost nature of such libraries is attractive when compared to the license or subscription costs of commercial automation solutions.
But there is more to it than just that when you look at the cost of implementing an automation solution.
For example, Selenium is open source and free, however building and using an automation solution on this ‘free’ software comes with some real costs:
1) The open source tools/libraries provide a starting point but you still have to write code for test creation, management, execution, handling errors and reporting. Note that this is over and above the test logic that you want to automate.
2) If you are looking to test integrations with back-end systems and external systems via API, you have to build in support for that into your framework.
3) If you are looking to implement a continuous testing solution, you must add to the above effort, the effort of building integration with DevOps or CI/CD tools.
4) Also to be considered are the costs of building and managing an infrastructure to run these tests. These costs are likely to go up as you scale your infrastructure in order to support increased test volumes or to increase the pace of testing.