Boozang is built for collaboration. Simply access your project in the management view and add users. After typing in the email of the user, an email will be sent to the user where they will be invited to sign-up.
It’s actually quite easy. Because Boozang is browser-agnostic, you can work creating tests in the browser of your choice. When doing cross-browser testing simple copy the URL into the browser you want to test, login and you can access and replay all the tests previously created.
Boozang has a full-featured entry level tier that is free of charge. It is limited to 1000 actions executed per month and maximum one project. When this runs out it’s easy to upgrade to a Premium or Enterprise tier.
Imagine a scenario flow change (i.e. an additional button was added to cart checkout and we need to add this action in all scenarios). This could potentially affect many test flows and create a lot of maintenance work.
The way we handle it in Boozang is that you will create many reusable “atomic tests”, which are test building blocks. You will then build longer tests runs comprised of tying together these atomic tests. In the case of the “Cart Checkout” case this will mean that you will update a single tests, and all other will follow.
Boozang treats preconditioning through UI (like setting cart to zero). We advocate this approach as we are testing like a real user would do it (to find hard to find errors).
For performance you can also pre-condition tests by other means, like running actions towards an API or run a clear-cookie action.
DOM tree changes should be handled well by Boozang. As tests are written in natural language, we will re-scan the DOM on test execution trying to find the best-match element.
As all our tests are hyper-linkable, we integrate with any CI out-of-the-box. We do that by allowing for Boozang to run from command-line using a headless browser. We have also built and open-source library built on Google Puppeteer, that allows for a one-minute installation (when you have node installed).
npm install -g boozang
to test it out.
As we operate within the browser we automatically wait up to 30 s (configurable on a per action basis) for a an element to appear. You can also force a wait by changing the wait mode from “maximum” to “minimum”.
Also, for recorded tests, we will increase the time-out automatically to increase stability. For instance, if an element takes 20 s to appear during a recording, we will set the timeout to 40 s, twice this time. Note that this only increases time, so the application never waits unnecessarily. There is no impact performance for a fast application.
It’s been tested working on all recent versions of Chrome, Firefox, Safari, Edge, and Opera. The only known browser which is not working is Internet Explorer.