Thank you! By standing up, I simply mean getting to a place where your team is taking full advantage of web automation scripting. "Implementing" is probably the better word there.
And right now, "implementing" web UI automation usually means downloading and installing Selenium drivers and their language bindings... and writing Selenium scripts in a major programming language (C#/Java/Ruby/JS etc). Then coordinating teammates' machines... then sharing tests with each other, so we'll create a git repo... ARGH I'm a QA analyst, not a developer!
But that is the crux of the issue: QA people usually do not have the necessary programming/technical experience to get that to a place where the rest of the team can use it AND not have it result in a heaping mess of abandoned scripts a year later.
However, show any QA person an automation of a tedious workflow of theirs and their eyes light up as they think of the time that can be saved.
Flytrap aims to make the automation barrier-to-entry insignificant by providing simple commands that map directly to things people can do on a website. Click this, set this value. But it's also extremely powerful and can perform very elaborate workflows by utilizing a few simple programming constructs (loops, variables, etc).
Right now, Flytrap only works in DOM environments, so "just" the browser. But that's not to say that it couldn't be extended for mobile apps (and it actually works like a charm for a mobile web app!). As long as the "things" in a UI can be referenced via text, then theoretically, Flytrap would work in any environment!
I'm focusing on web for now though because that seems to be where most shops struggle with automation and it seems to be where a JS library and have the biggest impact.
I really appreciate the comment and would love to expand on any other questions.
And right now, "implementing" web UI automation usually means downloading and installing Selenium drivers and their language bindings... and writing Selenium scripts in a major programming language (C#/Java/Ruby/JS etc). Then coordinating teammates' machines... then sharing tests with each other, so we'll create a git repo... ARGH I'm a QA analyst, not a developer!
But that is the crux of the issue: QA people usually do not have the necessary programming/technical experience to get that to a place where the rest of the team can use it AND not have it result in a heaping mess of abandoned scripts a year later.
However, show any QA person an automation of a tedious workflow of theirs and their eyes light up as they think of the time that can be saved.
Flytrap aims to make the automation barrier-to-entry insignificant by providing simple commands that map directly to things people can do on a website. Click this, set this value. But it's also extremely powerful and can perform very elaborate workflows by utilizing a few simple programming constructs (loops, variables, etc).
Right now, Flytrap only works in DOM environments, so "just" the browser. But that's not to say that it couldn't be extended for mobile apps (and it actually works like a charm for a mobile web app!). As long as the "things" in a UI can be referenced via text, then theoretically, Flytrap would work in any environment!
I'm focusing on web for now though because that seems to be where most shops struggle with automation and it seems to be where a JS library and have the biggest impact.
I really appreciate the comment and would love to expand on any other questions.