Subscribe
Sign in
UI-licious
p/ui-liciousTest user journeys, not HTML
Start new thread
Shi Ling

UI-licious for Teams - Test user journeys, not HTML, catch bugs before users do

by•

UIlicious is a low-code tool for automating tests for your e-commerce websites and SaaS web applications with UI-licious. In this newest update, annotate test reports to highlight issues and discuss what's wrong. No more pointing and gesturing at screens!

Add a comment

Replies

Best
Portia
Finally, testing tool that doesn't require an advance degree in Selenium! 🤣 Is UIlicious geared more towards non-coders or engineers?
Shi Ling
Maker
Hey Portia! Yea, I think even for engineers, Selenium test can be a challenge to setup and maintain. Great question! I would say UIlicious more geared towards making test automation accessible to non-coders, but at the same time, we don't want to sacrifice flexibility for engineers to get creative in the name of simplification. When @picocreator and I first thought about creating UIlicious, we wanted to make sure it as easy to use for folks in the product development team that don't code, such as the product managers, designers, or manual software testers. I'm quite proud to say that as we've accomplished this mission as 70% of the tests created by our users are written by non-coders. But as programmers ourselves, we want to make sure that it is still possible for programmers get creative, and use javascript natively to handle more complex test scenarios. I've tried codeless testing tools in the past and always struggled with trying to modify tests that were created by non-coding members of my team, even for simple things like generating relative test dates or randomised IDs. In UIlicious, engineers may use native Javascript along with the simple UIlicious test commands to do almost anything!
Shi Ling
Maker
Hello Product Hunters! I'm Shi Ling, one of the creators of UI-licious. I'm really excited to announce one of our most highly requested feature: Report annotations and comments! One of the things that surprised me about the feedback coming in from y'all, our beloved users, is that you really love to export the test reports to PDF just to annotate the screenshots with comments and send them to your devs, designers, and clients... 😂 I hope none of you have been printing those PDF test reports out to draw with pen and markers. 😱 Now, with this new feature, you can annotate and write comments on your test reports directly within UIlicious, and share links to the comments to your team members. 🎉🎉🎉 We'd love to hear your feedback, do share your thoughts in the comments below. There's much more we're working on to improve the tool to make testing a piece of cake. Check out our roadmap on Upvoty: https://ui-licious.upvoty.com/ If you haven't already tried UIlicious, you can try our lite edition for free without signing up and run tests for your website on Chrome here: https://snippet.uilicious.com Or you want to try the Professional edition, which offers testing across all major browsers, and great features like scheduling tests, sign up for a free trial on our website: https://uilicious.com To celebrate the launch of this new feature, we're offering 25% discount for your first year of subscription with this promo code until the end of the month: PHOCT22 Join us on Discord to discuss about software testing, and occasionally cats: https://discord.gg/DZCmSRFwq8
Shi Ling
Maker
@albertodrs Thank you, I hope you'll find UI-licious delightful to use. :)
Roy Jacobs
This looks interesting! How do you make sure that tests keep working once they've been authored, though, if they're mostly based on the displayed text?
Shi Ling
Maker
@royjacobs , great question! Our philosophy is "Test User Journeys, not HTML", because we want you to write readable and maintainable tests. UIlicious supports many ways to target an element, but has a strong bias to target elements based on displayed and assistive labels. The UI-licious test engine target elements based on their displayed labels, assistive labels, semantic attributes (e.g. name, title, placeholders), but also conventional CSS and XPATH selectors. For example, to fill a "Username" text field, you could write: `I.fill("Username", "royjacobs")` And UIlicious will search the page for a visible text input field that would likely be the "Username" field, based on the any elements attached to the input field, or any assistive labels set using the ARIA- attributes, or semantic labels such as "name" or "placeholder" attributes, or even nearby text that say "Username". You can also use CSS / JQuery selectors, like this: `I.fill("#username-input", "royjacobs")` Or XPATH selectors, like this: `I.fill("//*[@id='username-input']", "royjacobs")` But unless your testing and development teams have established conventions to give each page element a unique element ID, we do not recommend using CSS and XPATH selectors, as they become difficult to read and maintain, and very difficult for new testers to be onboarded into the project.