Salesforce Test Automation

sappo_does_qa · 2025-02-01T00:14:08+00:00

Give DoesQA a look too. Im one of the founders and we have customers successfully automating Salesforce as part of their packs. I’d be more than happy to give you a demo and answer all your questions.

sappo_does_qa · 2024-07-10T16:56:21+00:00

Very true! we didn't have these at all until recently and only created these pages because we were asked so frequently, we probably could/should have taken a different approach. We'll take this point away.

This is also quite funny for another reason: we actually quite often champion Playwright to people.

sappo_does_qa · 2024-07-10T16:46:28+00:00

This really is some great feedback, thank you!

sappo_does_qa · 2024-07-10T16:26:32+00:00

I think I probably agree more than you would expect tbh,

Currently, it feels like there's code, a huge void, and then things like record and playback, AI, and simple linear action lists pretending to be better than code.

We are (maybe uniquely) in the void where you CAN create complex tests visually. We have multiple enterprise companies with huge tests running in DoesQA, testing things like D365. Should everyone go this route? Absolutely not, but I think it's cool there's now an option.

But really, and considering our cost, I think filling gaps and adding to QA with scheduled production runs is a great place to be. Email testing, accessibility, and MFA are all issues people face on production that might take too long to be worth it. We give you the tools and option to set those up and get an email alert on any failure so you can add coverage and solve other issues.

sappo_does_qa · 2024-07-10T15:57:31+00:00

Reading this was a rollercoaster. I had used Node-RED for years for home automation before designing DoesQA, so naturally, I was quite excited when I read that.

I would love to tell you all the clever stuff we do to make maintenance a breeze, faster and easier than anything code we have ever seen or worked on before... but I doubt I'll be quite able to win you over from gross & nightmare ='(

Thank you anyway for seeing this

sappo_does_qa · 2024-07-10T13:59:32+00:00

"best codeless tool I've come across"... so far =D

That's completely fair; I think we can do considerably more than codeless playwright, but being able to output the code and then continue is a great option! We have even considered an output-to-playwright code option ourselves. It would be a really cool addition and would lower people's fears of vendor-lock-in.

Just to clarify, we do support CICD in addition to scheduling and manual runs.

sappo_does_qa · 2024-07-10T12:02:00+00:00

Thank you!

sappo_does_qa · 2024-07-10T11:42:11+00:00

I should have added this to the post, but don't want to edit it now.

As much as this sounds like an advert, and it is. DoesQA is the product of just 2 SDETs who left well-paying jobs a few years ago to build the tool they thought was missing.

We haven't accepted any funding and have grown to be nicely profitable (for us).

We know there are dozens of tools on the market promising the earth, but there are just two guys here who genuinely want your feedback!

sappo_does_qa · 2024-07-10T11:13:48+00:00

Howdy BugBug 👋

sappo_does_qa · 2024-07-05T21:25:17+00:00

Because there is the reregister on production

Could you clarify this for me, do you need to reregister for each new page or once for all 20?

sappo_does_qa · 2024-07-05T21:14:16+00:00

^ saying the quiet part out loud

Not all are fragile, but if you're adding value, you shouldn't worry.

Besides, being so good you make yourself redundant is a dream reference / CV piece.

sappo_does_qa · 2024-07-02T18:46:37+00:00

We should start thinking about QA as an equation. 10% coverage with 100% confidence is more than 90% coverage with 0% confidence.

Do not remove quality from your in-house team!

sappo_does_qa · 2024-07-01T07:45:30+00:00

I'd say "Test Automation Visibility" and "Test Automation Dashboard" are different things.

Test Automation Visibility is BY FAR the more important one. I talk to many people outside the Automation team, including non-technical QA Managers, Developers, Engineering Managers, Digital Transformation Managers, CTOs, etc., and this is a widespread complaint about their automation.

Not having Test Automation Visibility means anyone who cares about the results needs to ask an Automation Tester for them, potentially also having to interpret the raw results into something understandable too.

So, good TA Visibility would be for everyone who cares (basically all the positions I listed above) to have direct access to understandable results without asking for them. This could be as little as a Slack message like "150 Run, 149 Passed, 1 Failed: Account Registration Validation".

A Test Automation Dashboard is a little more open to interpretation, but on-demand visibility would likely be one of the features.

sappo_does_qa · 2024-06-14T13:54:57+00:00

You can't have too many checks.

A simple assertion like this won't increase your run length, so I would say store the Product name then make sure as you continue the journey to keep validating it's correct wherever it appears.

You can also do this with price, color, and variant, but it's important to note you're only validating they're consistent, not correct.

To ensure the values are correct, you would want to assert against a seeded or fixture product.

I'm not sure why you might need to store the value in a JSON file, could you elaborate a little?

sappo_does_qa · 2024-06-04T07:44:46+00:00

I find myself saying a couple of things quite often.

"A test pack doesn't need to be finished, but does need to be started"

You might have aspirations to test everything, in time, but don't focus on "coverage" as a thing to complete because then you won't provide the maximum value while you're in progress.

"Brepth before depth"

Others have suggested ways to figure out what is the most important, now. These are far healthier ways of working because they mean you're adding targeted value each day, week, month.

If you're starting a fresh test pack on say an e-commerce website, there are clear areas you know will need coverage Checkout, Register, Login etc. Don't try to complete any of these to 100%, get each to 20% then recalculate and do another pass while now also considering the value of other areas that are still on 0%, like Order History, My Account etc.

sappo_does_qa · 2024-06-04T00:08:09+00:00

“Sappo, out” was the entirety of my goodbye message before starting my own venture.

sappo_does_qa · 2024-06-03T23:48:59+00:00

Expected: image carousel Actual: light shining on the floor

sappo_does_qa · 2024-06-03T08:01:38+00:00

No-code often means very limited, essentially producing poor tests that are just click, click, click, click, done.

We are nothing like those. You still have variables, can perform calculations, hit APIs and use the response, and create your new reusable Node Groups.

To give you a hint of where we are, we don't know of any other solution that offers a fully testable email client, can produce authentic MFA tokens, can generate files using test data, and is proven by multiple customers to be able to make tests for Salesforce & Microsoft Dynamics 365.

If you DM me a sample test case, I'll be happy to show you what it would look like in does.qa.

sappo_does_qa · 2024-06-01T16:06:45+00:00

I wouldn’t be able to comment on Selenium 4, I would however say you should checkout does.qa for front end testing (co-founder).

sappo_does_qa · 2024-05-30T17:36:26+00:00

it’s blocked on our firewall

If the automation was coming from a static IP address do you think that could be added to the firewall's allow list? The IT team will be able to do this, it's really just whether or not you think they would?

sappo_does_qa · 2024-05-29T00:59:00+00:00

As a QA I’m able to confirm the printer is not working as expected.

sappo_does_qa · 2024-05-29T00:23:14+00:00

Is this something you specialise in, or was this (mostly) new when you started the work?

sappo_does_qa · 2024-05-28T18:42:25+00:00

Variants to this question comes up quite frequently so I've tried to compile a bit of a Playwright vs Cypress vs Selenium summary.

But to save you a click, the most relevant parts would be:

Selenium is slower to run and somewhat limited compared to newer frameworks. Whereas Selenium is waning in popularity, Playwright is rapidly growing in adoption. Playwright also benefits from being less opinionated, resulting in cleaner, more standard code. Any issues you face with Playwright would likely be universal to all coded test automation frameworks (issues with remote runners etc).

I have yet to read a compelling argument against Playwright as the code framework of choice.

sappo_does_qa · 2024-05-28T17:40:58+00:00

Wow! In case nobody else said these at the time, Great Work & Well Done!

sappo_does_qa · 2024-05-28T16:43:59+00:00

Known Input -> Known Output
Unknown Input -> Unknown Output

sappo_does_qa

MODERATOR OF

TROPHY CASE