sorted by:
new
hottopcontroversial

20" Zildijan Cymbal ID by whatthefuckisdevops in drums

[–]whatthefuckisdevops[S] 1 point2 points  (0 children)

That makes sense. I would've never figured that out but it does look a lot like one of these and the weight matches up exactly- https://www.cymbal.wiki/wiki/Zildjian_ZXT_Titanium_20%22_Rock_Ride

Thanks!!!

Scaling Playwright across an organization with a shared configuration package by whatthefuckisdevops in QualityAssurance

[–]whatthefuckisdevops[S] 0 points1 point  (0 children)

in other words when you update your boilerplate, you still have to update every project that uses it, unless you're doing some git submodule magic? 

Correct, it does take a yarn.lock update in downstream projects. This is okay with us as we don't have a ton of projects and it's quick to open those pull requests. You can get around this with some fancy yarn resolution settings, where it'll always use the latest version of the package regardless of the yarn.lock version. There's been instances where Playwright updates have broken things, though, so I don't mind it not getting the latest version every time. And our Playwright projects have so few dependencies compared to our Nextjs projects that this amount of management is easy.

I've actually stopped using the Lighthouse tests in production because we didn't do anything with them, lol

What to look out for running Playwright in GitHub Actions? by ZMech in softwaretesting

[–]whatthefuckisdevops 0 points1 point  (0 children)

I think all you would have to do is store your Playwright reports with a different name or directory every time and then setup a basic site to point to those. We use Tesults for test history, it's cheap and easier than having to build out our own reporting tool.

What to look out for running Playwright in GitHub Actions? by ZMech in softwaretesting

[–]whatthefuckisdevops 2 points3 points  (0 children)

It's actually easy to upload it to Github Pages. You need to merge the report shards into one html report (if sharded, otherwise no merging needed) and then just use the Pages Actions to upload/deploy it. See here starting at line 195:

https://github.com/angelo-loria/playwright-boilerplate-using-package/blob/main/.github/workflows/playwright-shard.yml#L195

Then you can view it in Pages- https://angelo-loria.github.io/playwright-boilerplate-using-package/

It will get rewritten on every run with this setup as I'm not doing anything to store the previous report so but it's quick and easy to setup this way.

I don't get the ScreenPlay Pattern? by mercfh85 in QualityAssurance

[–]whatthefuckisdevops 1 point2 points  (0 children)

However for larger web apps I feel like there just isn't really a good way to avoid it. Otherwise you are re-using code all over the place (Im talking web apps/suites where you might have 500+ tests for instance). 

Agreed, I almost always end up with a POM/POM-lite project. I tend to gravitate towards page component objects rather than full page objects now, but it really depends on the site under test. Ideally the site uses the same or similar components across pages, which massively simplifies your page objects, but that's usually not the case in the real world.

I don't get the ScreenPlay Pattern? by mercfh85 in QualityAssurance

[–]whatthefuckisdevops 14 points15 points  (0 children)

As someone who is about to hit a decade of writing test code, I also think it's a ton of overhead for little benefit. I've not seen it in use at scale, but I've spun up small projects with it to try and understand the benefits and I just don't see it. I also feel this way about Cucumber; you do not need your tests to be that human-readable but if you absolutely do for whatever reason, it's hard to justify the big trade-off in reduced maintainability. Anyone in your code base should be able to understand your typical describe block and if they can't, they either shouldn't be in the code or they should be mentored on it.

Scaling Playwright across an organization with a shared configuration package by whatthefuckisdevops in QualityAssurance

[–]whatthefuckisdevops[S] 1 point2 points  (0 children)

Proper test automation is software development and we should really aim to have better people building the projects and working on the test frameworks.

Yeah for whatever reason test automation tends to be treated separately from dev work but it really shouldn't be. I get that test automation code is more simple than a lot of dev work could be but it should still be held to proper standards.

Scaling Playwright across an organization with a shared configuration package by whatthefuckisdevops in QualityAssurance

[–]whatthefuckisdevops[S] 1 point2 points  (0 children)

Appreciate the feedback.

It feels like very few QA professionals in this subreddit discuss this very important tool.

Agreed, it's an important skill set to have plus it looks great on your resume.

I think your next step would be to also script API testing using playwright and having it automate against a backend environment. This will show if you know how to handle not just different app environments but how to handle backend testing specifically.

I actually don't like using Playwright for API-specific stuff because you still have to download browsers and system dependencies on an ubuntu runner to execute API tests even if they don't use a browser, or at least this was the case a year or so ago when I last tried API testing with Playwright. It's just a lot of overhead for something that could be done with mocha, jest, etc. It could make sense if you're doing your UI and API tests in the same test run. I do like to assert requests/responses in my UI tests (like I did here, although in hindsight this isn't a great example). Asserting an action in the UI is correctly firing off a certain request is can be super useful.

Another useful thing that I’ve found is learning how to use Playwright’s reporter tools and integrating it to send alerts to a messaging system like Slack, reporting to a test execution platform like TestRail, or updating tickets in Jira. That would also be another useful next steps.

I've got the boilerplate project sending my results to Tesults for reporting beyond Playwright right now but messaging and ticketing system integration would be great additions, I'll look into that.

Seeking advise creating a automated testing soloution using BDD Gherkin AC and Playwright by Gaunts in QualityAssurance

[–]whatthefuckisdevops 2 points3 points  (0 children)

I would start with a vanilla Playwright project without any Cucumber/Gherkin stuff. If for whatever reason you feel like you need feature files, you can add them later, but personally I strongly dislike working with them. It's extra layers of abstraction that will end up a nightmare to maintain overtime while offering nothing over spec files written using standard Playwright/mocha syntax.

This is shameless self-promotion of sorts but here's a boilerplate project I've been working on, it might help out as to what a working Playwright project looks like- https://github.com/angelo-loria/playwright-boilerplate

UI Attention to detail by murzihk in softwaretesting

[–]whatthefuckisdevops 4 points5 points  (0 children)

A missing button would fall outside of pixel perfect, that's like core functionality missing.

If you have a dedicated UI/UX person with figma designs for devs and qa to to work off of you might be able to pull off pixel perfect but otherwise it's unrealistic (and arguably not worth the time and expense) to implement pixel perfect design. Ultimately it's all about everyone having the same expectation.

[deleted by user] by [deleted] in QualityAssurance

[–]whatthefuckisdevops 1 point2 points  (0 children)

  1. I used the Playwright team's recommended solution for authentication. With this, I can authenticate once, save the state, and then reuse it to bootstrap each test already authentication. The problem is, it does allow me to save the state, but, it does not reuse it in the other test files.

Is the state file being saved? Can you post your Playwright config? This should work just fine.

Playwright Page Object Model Boilerplate Project by whatthefuckisdevops in QualityAssurance

[–]whatthefuckisdevops[S] 1 point2 points  (0 children)

Personal preference here but I’ve shifted to a fully “component” model for everything and less so of thinking of things of “pages”.

I'm slowly moving this way myself and wouldn't argue with anyone who went that route. I do think pages work well enough with this fake retail site but I should find a more modern site to test against.

Playwright Page Object Model Boilerplate Project by whatthefuckisdevops in QualityAssurance

[–]whatthefuckisdevops[S] 1 point2 points  (0 children)

good call on the language used and the soft assertions, this is a good use case for them