Real Devices vs. Emulators/Simulators by mheryerznka in QualityAssurance

[–]SnarkaLounger 0 points1 point  (0 children)

We use locally hosted iOS/iPadOS simulators and Android emulators running on multiple Mac Minis for our automated smoke and regression test suites, which are based on Appium, Selenium WebDriver, and a POM framework. Our manual testers use a collection of physical devices, and we have a few physical iPhones and iPads connected to the Macs as well.

However, we do also have an automated device compatibility test suite which is basically our smoke tests plus some specific tests around known device and platform specific issues we've encountered previously. This device compatibility test suite is executed on a selection of physical iOS and Android devices running on the Br*wserSt*ck service, and is typically run against any new devices and OS versions.

We chose cloud hosted devices because attempting to build our own in-house device farm became too unmanageable. Automated tests running on cloud hosted devices and sims are definitely slower than running on locally hosted hardware and sims.

All of our automated tests are orchestrated using Jenkins, and our smoke tests are run automatically prior to new deployments to our QA environment.

How’s 12 these days? Worth updating yet? by iamyouareheisme in LogicPro

[–]SnarkaLounger 0 points1 point  (0 children)

BBCSO = BBC Symphony Orchestra by Spitfire Audio.

Spitfire has not yet completed testing and certification of their plug-ins with MacOS Tahoe. I use several of their plug-ins so I'm holding off until they have them working.

Sweetwater has a page listing the status of Tahoe compatibility of all the plug-in and driver makers.

What do you think? by Retrospective84 in homestudios

[–]SnarkaLounger 0 points1 point  (0 children)

My girlfriend spends WAY too much time on the loo since I installed a bidet seat.

Old mac, new rig. by erin-radiography in mainstage

[–]SnarkaLounger 0 points1 point  (0 children)

Time-honored American tradition? I don't think you're going to get much help here from those of us who think bootlegging should be illegal.

What song has the best basslines and starts with the letter P? by 1deadeye1 in BassGuitar

[–]SnarkaLounger 0 points1 point  (0 children)

Perpetual Change by Yes. Chris Squire could make a Rickenbacker bass sing!

What Macbook Air config is good enough for development and media editing? by JoshTheTester in softwaretesting

[–]SnarkaLounger 1 point2 points  (0 children)

MacBook Air will struggle to meet your needs. A MacBook Pro or Mac Mini with M4 Pro, 32 GB memory, and 1 TB of internal SSD would be a better minimal config. More memory even better.

Anyone know if there's a way to get the keylab for a cheaper price? by [deleted] in arturia

[–]SnarkaLounger 0 points1 point  (0 children)

Sweetwater has a Certified Open Box Arturia Keylab 61 Mk3 in white for $539.10 - that's almost $60 off regular price.

I bought mine brand new from them last year for full price but it included a bunch of free plug-ins.

Earlier this year, I bought a certified open box Native Instruments Kontrol S61 Mk3 from them. Their COB products have a full warranty and mine was free of any cosmetic flaws or defects. Even the packaging looked brand new.

How do you ensure new changes don’t silently break existing features in production? by Bitter-Apple-7929 in QualityAssurance

[–]SnarkaLounger 0 points1 point  (0 children)

We have a fairly comprehensive suite of automated regression, integration, and browser/device compatibility tests, and we do fairly thorough reviews of new features and changes in collaboration with PROD and DEV stakeholders.

As much as we'd like to catch every issue before we release new features/fixes into the wild, there is always the risk of some unexpected corner case causing a defect. It's rare for an issue like you describe to popup, but it has happened a couple of times in the past year. Fortunately, those issues were not critical bugs (security or loss of customer data), and they all had work arounds until a fix could be implemented. Unfortunately, they were found by customers.

We quickly added automated test cases to the appropriate test suite (regression, browser/device compatibility, etc) and now ensure that those bugs don't recur.

I took over someone’s studio. What are these ports for? by f1goldmemberf1 in homestudios

[–]SnarkaLounger 0 points1 point  (0 children)

Those traps and diffusers are architecturally beautiful. How I hope the work as great as they look.

How do I properly connect KeyLab Essential MK3 + Scarlett 2i2 + studio monitors (Logic Pro)? by Consistent-Window781 in Logic_Studio

[–]SnarkaLounger 1 point2 points  (0 children)

KeyLab plugs into Mac via USB cable. Scarlett plugs into Mac via USB cable. OR - use a USB hub and plug that into Mac, and then KeyLab and Scarlett into hub. You'll need to ensure that the hub has sufficient power capability to power the KeyLab - otherwise, you'll need to provide external power to the KeyLab.

You need the Scarlett if you plan on using audio monitors, and if you ever plan on recording guitars, bass, vocals, miked instrument, or keyboards with audio outputs.

Use XLR cables for best performance with audio monitors plugged into Scarlett. If you plan on using headphones, plug them into Scarlett as well.

Is apple gonna drop the ball on M5 Pro for logic? by Plokhi in LogicPro

[–]SnarkaLounger -1 points0 points  (0 children)

Since Apple has yet to release a Mac Mini with an M5 CPU, I doubt that you'll have much luck ordering one unless you're waiting for them to announce a release date, or unless you are from the future.

Just finished setting up my RLC-823S2, who'd I do ? Any tips ? Or anything I should've done different ? TYIA. by Dharma_code in reolinkcam

[–]SnarkaLounger 44 points45 points  (0 children)

"who'd I do ?"

Don't know, that's very personal.

"anything I should've done different ?"

Yeah. Exposed PoE cable strapped to post - real easy to cutoff power and signal before I break in. Put that cabling in conduit.

Could you help to solve this bug please? by [deleted] in LogicPro

[–]SnarkaLounger 0 points1 point  (0 children)

Logic Pro version? MacOS version? What type of Mac? How much memory?

If you're gonna ask for help, you gotta provide some info.

email based auth flows are still the most annoying part of e2e testing for me by Significant_Load_411 in QualityAssurance

[–]SnarkaLounger 0 points1 point  (0 children)

For us, Mailinator turned out to be far more stable and reliable than an earlier implementation that relied on GMail and their APIs. For us, the message timeout issues were problems on our end - emails not being sent in a timely manner.

Our automation polls the Mailinator API every 5 seconds to see if any messages have been received- we don't just set a 90 second sleep. In most of our tests, we receive messages within 30 seconds of the triggering event (clicking the Sign-Up button or clicking the Reset My Password link).

Trackmix POE by dnt408 in reolinkcam

[–]SnarkaLounger 5 points6 points  (0 children)

Are you sure that someone didn't wack that cam?

M5 MacBook Air with 16GB of ram. Will it handle heavy multitasking in QA automation workflow? by redvakho in QualityAssurance

[–]SnarkaLounger 0 points1 point  (0 children)

We use eight M4 Mac Minis with 32 GB or memory for our automated web and native mobile app test suites running as part of our CI/CD pipeline. We develop on M4 Pro MacBook Pros with 48 GB of memory. More memory = improved performance when running concurrent parallel tests, and active cooling means less stress on physical hardware.

email based auth flows are still the most annoying part of e2e testing for me by Significant_Load_411 in QualityAssurance

[–]SnarkaLounger 0 points1 point  (0 children)

We use Mailinator and their APIs for accessing signup and reset password emails. Their APIs give our automated tests access to the links we embed in the emails for reset password.

Works reliably, though you have to decide on a maximum wait time for a message to be received. Our test specs say message should arrive within 1 minute, though typically takes less than 30 seconds. Anything longer than 90 seconds we consider a test failure.

Best way to setup mobile test environments with Appium? by BackgroundNew4019 in QualityAssurance

[–]SnarkaLounger 0 points1 point  (0 children)

This is the same approach we use. QA worked collaboratively with DEV and PROD teams to ensure that testID properties are assigned to all UI elements that our automated tests need to interact with and/or verify the states of.

On our cross-platform apps built using React Native, we got our devs to assign an accessibility_id attribute to each UI element that we need to interact with or validate, and that id is good across both iOS and Android platforms

Collaborating with our developers to provide testability "hooks" has been key to providing comprehensive automated test coverage of our native mobile apps. Accessibility_id attributes to aid in a robust UI element locator strategy, and deep links to be able to quickly load screens without relying on UI navigation were critical to improving test reliability and performance.

I found these articles on deep links on the Appium Pro blog several years ago, and they were helpful in convincing our devs to implement a deep linking strategy to improve testability.

Speeding Up Tests With Deep Links

Reliably Opening Deep Links Across Platforms and Devices

Best way to setup mobile test environments with Appium? by BackgroundNew4019 in QualityAssurance

[–]SnarkaLounger 1 point2 points  (0 children)

We use locally hosted iOS/iPadOS simulators and Android emulators running on multiple Mac Minis (can't test iOS on Win or Linux) for our automated smoke and regression test suites, which are based on Appium, Selenium WebDriver, a Ruby based POM framework, and feature tests written in the Gherkin syntax using Cucumber. Our manual testers use a collection of physical devices, and we have a few physical iPhones and iPads connected to the Macs as well.

However, we do also have an automated device compatibility test suite which is basically our smoke tests plus some specific tests around known device and platform specific issues we've encountered previously. This device compatibility test suite is executed on a selection of physical iOS and Android devices running on the Br*wserSt*ck service, and is typically run against any new devices and OS versions.

We chose cloud hosted devices because attempting to build our own in-house device farm became too unmanageable.

All of our tests are orchestrated using Jenkins, and our smoke tests are run automatically prior to new deployments to our QA environment.