Launching today
Seldon
Behavioral QA agents that use your product like customers do
305 followers
Behavioral QA agents that use your product like customers do
305 followers
Find the tests you didn’t know to write. Tell Wren what should work in plain English. Its QA agents try the paths your customers take, like going back to change an address halfway through checkout or retrying a failed payment. When something breaks, you get a replay and the steps to reproduce the bug. First 10 runs free.
Free Options
Launch Team
Render Sandboxes: a computer for every agentGive every agent its own machine. Starts in under a second
Promoted
Congrats Tom and Liv :)
@lisa_shmulyan Thanks so much!
@lisa_shmulyan Thank you!
Would love to see the demo!
@vijayanandkailash of course, lets set one up with the team (theres a booking link here: https://www.seldon.com/), in the meantime you can signup and have a look around https://www.seldon.com/products/wren?ref=producthunt, would love to hear more about your use case!
@vijayanandkailash @cosima_calder thanks, cos!
Vijayanand, I’d love to grab some time to show you the demo. Can you take a look at my booking link and schedule a time that works for you?
Calendly.com/rjg
Cheers!
@cosima_calder @bobby_glasco Long booking form :) Blocked a slot for Thu, my friend. Talk to you soon. Excited to see the test cases defined and seeing how system go over the screens like human and do the testing.
congrats on the launch tom. the invite plus account switch example is a good one, those half finished flows are where real users get stuck and nobody writes a test for them. can wren start from a landing page and follow the whole signup from there?
@agshin_rajabov Hello Agshin, absolutely! Wren can sign up for your product, and tell you what about your signup flow caused the most friction! We even have customers presently using Wren as their weekly regression suite, running several dozens of test cases!
thanks marquise, a friction report on signup is exactly what i would read first
@agshin_rajabov Thanks so much! Yep, you can give Wren the landing page URL and a goal like “sign up and reach the dashboard.” It starts on that page, finds its way through signup and checks whether it gets there. If it gets stuck halfway, you can replay the run and see exactly where.
thanks tom, the replay is the part i like most. seeing where it got stuck is more useful than just a red fail
@agshin_rajabov Cheers! 'Signup failed' is usually where the detective work starts. With the replay you can see the exact click that left the agent stuck and drop it straight into a bug ticket.
the wrong account invite example is a good test of a real onboarding flow
the replay needs to make it clear whether a failure came from the product or from the agent getting stuck operating it
@saad_el_gueddari Yeah, that’s exactly why Wren records the whole run. You can watch the agent switch accounts, see which account it accepts the invite with and where it lands. If the agent gets stuck trying to switch, you can see that too.
Writing tests in plain English and letting the agents find their own way through the app is such a good shift. It caught a confirmation that only showed up below the fold after loading, something my unit tests would never flag. The replays make it easy to see exactly what happened. Congrats on the launch!
@mian_abd love that example! We're super excited about reducing the overhead of writing and maintaining detailed test scripts, whilst removing assumptions & uncovering issues we might have never tested for in the first place! Would love to hear more feedback as you continue exploring Wren :)
@mian_abd Great to hear Mian! We have found that the videos are very necessary in quick identification of the issues and repo. Keep running tests and tell us how it goes
@mian_abd The great part about this is that Wren really leverages the dynamism of AI Agents. If you make a change to your application, there are no test specs that you need to update. The agent is able to adapt to your UI/UX changes and test against the core functionality that your test cases are supposed to cover.
Giving agents a goal rather than a script catches the path nobody wrote a test for, like editing an address mid-checkout, and that is where many customer-facing bugs actually live. The false-positive question in the comments is the real test: separating a genuine bug from a route no customer would take, and building on behavior models of real users rather than random clicking is the right bet. When Wren flags something, how can a team teach it that a given odd path is acceptable, so the same finding does not come back every run?
@qingyun_wu that's a great question!! you can handle this in the setup yaml by describing the path in plain text as further context
@qingyun_wu love this question and this is a part of the Seldon "why"! This set up will apply to future runs - wren knows its intended and doesn't keep flagging it. Runs come with a record and tractability as well so you know how it works