geoelectric

I've been on at least one team effort like that (not as the architect, in my defense--in fact, it was that failure and my somewhat frustrated ask to my manager to give me a couple of weeks head down to start it properly that launched the automation lead portion of my career).

I bet a team like that would be totally transformed by getting some early success under their belts, and giving valuable feedback early enough to actually be included in the whole process.

That's exactly what a QA team can use these tools for, especially early on--it can accelerate manual testing if nothing else, by people record-replaying at their desk for repeatability. Even if that won't work for verification, sometimes just recording the script that does all the setup you have to do for every test gets you really far--then you just take over manually from there.

In general, I think QA's sometimes-bad rap comes from putting in maximal effort and cost, in trade for a very limited and usually unquantifiable increase in actual quality confidence, and that usually comes down to dogma. Most of the "traditional" ways of doing QA come down to writing maximum docs without any single point of truth (and therefore become maintenance hogs and/or wrong) then spending a million bucks or more a year on a team whose whole job is to tell you 99 times out of 100 that things look the same as yesterday.

It makes the sector a thankless grind from the inside, and makes it an expensive spreadsheet generator that sometimes blocks your releases for unclear reasons from the outside. Fun times.

It's been a lot of years, but some of the handwaving there was editorial on my side. I can't remember exactly which projects they propped up as their examples. That said, I wouldn't recommend record/replay for Gmail, for example, so I do believe they meant smaller and simpler ones.

I also think (but am hesitant to assign to them because obviously I built this up in my head over the last ten years too) that part of the argument was that this enabled testing earlier and for smaller projects than people normally bothered testing--for example, internal-facing tooling. Whether or not they said that, I think that is one of the big advantages.

Also, left unsaid, this was for situations where a very small number of critical path UI tests are sufficient for the moment and you're not re-recording a huge suite if something breaks. Of course, if you're familiar with the testing pyramid, you probably know that only having a small handful of critical-path tests running E2E via UI is your ideal, period. Most organizations who do it at all heavily over-test via UI automation.

Your point is well-taken, though. By the time your app is that complex, I'd say you're probably in the position of creating those long-standing tests I wouldn't recommend recording.

We're of a mind, for sure.

I was/am a pretty big fan of the Context-Driven Testing (https://context-driven-testing.com/) concept from James Bach and Cem Kaner, though I think Kaner later backed away from either it or Bach, not sure which. It was basically the testing version of the Agile Manifesto.

The idea in general of "THINK about what you're doing and the specific results you need and do what's OPTIMAL, not what's DOGMATIC" has guided my career for many years, both inside and outside of testing.

I was probably being a little too literal when I said xpath/id. Something unique like a custom class would be ideal, agreed. I just see that as a different kind of id that I find through an xpath query, which is what I really meant.

To your point, though, the advantage of the class is that other things in your stack probably don't have opinions about what class you tack on, whereas they might want to define your (actual) id for you. IIRC this was how I asked devs to get around dynamic-UI runtime issues where the ids were also auto-generated.

Oh, OK! I misunderstood the comment entirely then. Thanks for correcting me there, especially since I was apparently too lazy to look for myself.

This does sound more promising then, if they've found new ways to add maintainability or QoL aspects to record/replay. As I said elsewhere, I think r/r gets a bad rap, and those sorts of improvements would increase the number of situations where it makes sense (at least for testing in incubation).

I could get into an even longer discussion on this, but basically when I brought up UI automation teams my advice was:

Use granular element-oriented functions (i.e. loginButton.click() or fillForm(name, pw) type stuff for the very small part of the very few tests that were specifically exercising that portion of the UI.

Those you probably define traditionally for POM, as methods of the page (or functions in the page module depending on the language).

Use result-oriented functions (logIn(), registerNewUser()) whenever it's "travel" i.e. things you do to get to the start of your scenario, or a setup/cleanup task.

Those you do not keep with your pages, they live in modules organized by task or result. Plus they have to work from anywhere. They can leave you somewhere, if that's their defined result, but they should be callable from any UI state. By the same token, tests shouldn't assume how they used the UI to get there, again, unless that was defined as their result.

In other words, they're functions: black boxes. The biggest point there was "you can't change this function without preserving that contract, and you can't assume anything but that contract."

The advantage is that if you could wave a magic wand for setup, travel, or cleanup and get the result, the test would still work and be valid. IOW, you can select the most robust and direct way to accomplish those things, even going completely around the UI with cookie injection or whatever.

What most other teams I've had visibility into tend to do differently than I advised is they'll use the granular element-oriented POM functions everywhere except fixture setup/cleanup. They don't have the "travel" concept of things you have to do on the way to your scenario start, and they include that in the test scenario itself with granular element calls.

And travel is really all setup. But some reason when it's "set up yourself via login, option selection, loading a file, etc" people's thought process goes out the window and they think that all needs to be strung together in UI like a user would do it. But intelligently separating out the very small bit of "specific UI manipulation that causes a state change + verification of that change" that is the test from everything else in the scenario that is setup/travel/cleanup gives you much more maintainable tests.

Or even when they do separate them out, they're not really "result-oriented" functions. Instead they're "flow-oriented" macros that you couldn't replace with a magic wand, because the meat of the test assumes intermediate UI flows they performed rather than just end state, and they're written to be strung together in some coupled (and usually undocumented) way.

Then you have the systems that try to use the same functions for setup/cleanup and testing, caught in between the need for granularity and robustness. Those tend to get extra "doItThisWay" flags on their functions and stuff really goes to hell.

Gotta keep 'em separated!

TL;DR I agree with you, and even a few steps further.

Does it have a mode where it can drive a real browser? Most real-world UI test matrixes for web apps want the tests run on their real targets for any final acceptance. "Fake" headless browsers tend to be more useful for first-tier CI and just keeping tests warm.

If it can only drive its internal browser engine, that'd possibly be a big argument against it for any test strategy I was architecting. I'd want the tests to be portable and usable cross-browser for acceptance--particularly UI-driven E2E tests, since that's really the only time they are critical.

Agreed, giving it at least stable identifiers to play with makes a huge difference. With some front end generators, that may not be trivial, though I'd think Selenium being a thing (POM does rely heavily on stable unique identifiers, since "nth element past m" xpath queries are way more fragile) has probably made it more of a standard ask.

Dynamically-created UIs are usually the hardest thing to deal with--if they get a different ID every time, record-replay is out the door, and even Selenium is a lot harder.

But personally, with a lot of automation architecture experience, I think you're exaggerating a little re: doesn't work 2 minutes later half the time. But it also depends on whether your app is driving some invisible external resource that makes the timing highly variable, etc. Even then you can usually "harden" the recording by putting in worst-case delays. It's just that then your test takes so long to run you can't CI it either.

It's really situational. What I'm arguing against more than anything is the knee-jerk reaction that it's never appropriate. It's just never enough usually. The fact that we tend to skip over the option entirely in testing is probably a blind spot and a mistake. Devs dabbling in testing as a side task definitely shouldn't ignore the option.

You're going to get a lot of responses that say record-replay testing doesn't scale, is unmaintainable, etc. They're totally right.

But the thing is, early on when your app is in flux, neither does writing Selenium code. There's a pretty big truism in UI automation that writing UI tests before a UI freeze is a recipe for a shit-ton of pain. Coding to ids or xpaths only gets you yay far if the UI flow itself fundamentally changes.

But re-recording might be easy.

Don't use stuff like this for long-standing tests. Unless you architect your app just right so that IDs are always stable, and you never change the interface, it'll break and break in ways that you can only fix by a complete re-record. Plus the tests tend to be extremely timing-fragile because recording uses delays instead of synchronization points, so they just won't work in CI.

But do use stuff like this at your desk during bring-up, when the cost of a re-record is lower than the cost of a test rewrite and it's ok to re-run the thing if the first try craps out due to a timing glitch.

And from there, keep an open mind.

I went to a GTAC (Google testing conference) where a presentation made a very good argument--with numbers and everything--that for smaller projects with simple and more or less static UIs, and where the tests were all fundamentally scripted, there was almost no advantage to coding the tests later. Record-replay was the best way to go.

But I definitely don't think a system like PlayWright fully replaces remote stubs like WebDriver and coding tests in the languages that can talk to it.

At some point you hit the issue that the login screen changed and now every single test is invalid. It's awfully nice if you used Page Object Model and you have a single-point-of-truth to fix it.

More to the point, test automation can do more than just execute a script repeatably. Randomized monkey testing is something you can really only do in code, ditto scenarios that need to talk to testing interfaces exposed from the app itself.

Glad you found a tool that resonates with you!

I see a pretty clear analogy to the various industries that felt threatened by home video and audio recording improving to the point of being able to make copies quickly and without significant degradation--particularly when disc ripping at 20x+ became a thing and time wasn't even a barrier.

A person who can clone a style and crank out illustrations at human speed is a very different thing than an automated process that can do it immediately on request, in minutes or seconds. If nothing else, the latter is a huge efficiency gain for being able to self-serve, as it would allow an editor to trial different illustrative approaches without all the back and forth contracting out to a human would require.

Personally, I think what this will do most is convince artists not to put galleries of their work suitable for training online.

The Redditor identified in the article posted a new comic art model based on James Daly III (this is mentioned at the end of an article with a link). The Redditor's comment in that post implies Daly was chosen specifically because they had a gallery of easily consumable training images all in one place.

I have no idea what the minimum effort would be to make the images less useful for training, but I foresee a lot of obnoxious watermarks in our future as people try to do so.

Yeah, that's roughly where I was coming from in what I said re: bad-faith termination in my other comment.

Without chasing your link, I assume it's the one where anything backordered (i.e. paid for but not shipped, which would technically be the case here) must get status updates every 30 days and be fully cancellable. I couldn't remember if that applied to internet sales too, or just the old mail order sales laws it came from. If it is that law, I agree it'd be potentially a violation of that, hence thinking probably technically fraud to block that option by claiming fulfillment.

With it coming from a small-business employer who already is obviously prone to shady and deceptive things, I'd assume it comes down to a constructive dismissal via intentionally lowering work satisfaction per your first guess.

...which makes me hope she found this Q&A online and works somewhere like CA that imposes good-faith requirements on at-will employment.

I'm fairly sure letting someone go over refusing to commit what's arguably low-level fraud (blatantly lying about whether fulfillment has already occurred in the course of a commercial transaction) might be treated as a bad-faith termination. In such cases the state can be very employee-friendly, especially if considering it as an official termination then puts the employer on the wrong side of other rules re: other employee protections, final paychecks, etc. The religious aspect would just be icing on the cake.

I'm certainly very curious about your surprising results. I hope you write the post (and I somehow find it again when you do!)

For the most part, they're barely even Gen X ages. Still a boomer world in the upper ranks once you get outside tech.

Depending on the area, lawyers (as outside representation) may not be allowed in small claims court, too. At that point, I believe they generally have to send someone working for the company who can represent them directly.

Last I subbed to Carrot it supported a few sources but the darksky API was the best there too. Apple pulling it out of community availability hurts.

The Clinton admin tried an "ID everyone to access the site" law federally back in the 90s as part of Clinton/Gore's attempt to censor the internet and it got knocked down for constitutionality concerns.

Is CA just relying on the crunchy state politics plus the right-biased SCOTUS to pass this with no challenge?

https://en.wikipedia.org/wiki/Child_Online_Protection_Act

I wasn't exactly pleasantly surprised when the extension it made me install switched my default search engine too. I guess in retrospect it makes sense, but at least I don't remember that being a prominent warning.

Courts only decided the monkey couldn't copyright the photo (the PETA case).

The copyright office claimed works created by a non-human aren't copyrightable at all when they refused Slater, but that was never challenged or decided in court. It's not a slam dunk, since the human had to do something to set up the situation and he did it specifically to maximize the chance of the camera recording a monkey selfie.

If I set up a rube goldberg machine to snap the photo when the wind blows hard enough, how far removed from the final step do I have to get before it's not me owning the result anymore? That's the essence of the case, had it gone to court, probably the essence here too.

My guess is the creativity needed for the prompt would make the output at least a jointly derived work regardless of any assignment disclaimers--pretty sure you can't casually transfer copyright ownership outside a work for hire agreement, only grant licenses--but IANAL and that's just a guess.

Fear of dietary cholesterol is overrated. You are not (directly) what you eat and that fear was as much deference to magical "Law of Similarity" as anything.

Blood cholesterol is different. At that point, however it got there, the build-up isn't great. I wouldn't lump statins in with the rest of your points.

I have aphantasia, and I also remember songs in multiple parts vividly. I won't go so far as to say it's eichoic--I can't, for example, turn around and just play a version of it on piano like some people I know, and I'm fairly sure I'm recalling an approximation in a lot of cases--but it's a detailed enough recollection I can "listen" to songs that way by recalling them. It's very much in contrast to my non-existent ability to recall even a familiar image.

I've considered cause/effect on this before and personally just decided it was probably coincidence combined with my poor visual memory making the other types seem that much more impressive. There's no particular compensatory mechanism I can think of that would explain remembering sound better because I remember vision worse.

Interestingly, I've never been any better at composition (i.e., imagining novel music) because of this. To the extent I've composed, I still pick stuff out a part at a time and figure out how it fits rather than starting with a finished sound in my head to recreate.

I would love a good replacement for Tree. I've never found another app that does what it does.

I think this is actually a pretty real concern. I've noticed my appreciation for specific instances of all sorts of media has tanked with wide availability.

I actually used to buy a lot of media so I hit this problem before streaming. As soon as I had a backlog big enough with each type of media that it wasn't straightforward to burn through it, it became a cloud of equally possible stuff with the result I wasn't particularly invested in any of it. Most people were smarter than me re: dumping money into bits on a disc, but now that streaming and/or free-feed libraries have hit most media types, I think the experience is becoming more common.

I think it's a different version of Paradox of Choice: all individualization between the various choices is lost when there's too many. With PoC, the problem is that then you have nothing left by which you can prioritize. In this case, the issue is the loss of all joy you'd have found in the differences.

What's helped a little for me is going on "kicks," like finding all the bands I liked that did EDM-metal hybrid, or all the found footage movies I liked, etc. Constraining the pool you're selecting from first makes it easier, and having a mission of some kind makes it easier still.

Should be able to tell from the suspension. If front extends before back, rocking the chassis backwards at all, then you hit something above the axle line.

This is really neat. It's similar to the BuJo rapid-logging-inspired system I handspun for myself around Markdown a few years ago that I outlined here:

https://news.ycombinator.com/item?id=21580133

I'd quit using that one since because too many Markdown editors have forgotten tabs are legal whitespace after a UL bullet, and that there are three different UL bullet characters (and it really doesn't help that the CommonMark examples page only docs `-` and `*`, even though `+` is part of the CommonMark spec too). In particular, without the tab support being implemented, there's no fixed gutter for the BuJo-style sigil and queries get much harder.

But I do miss the idea of those simple bullets. I may have to check out your extension.

This is why I use TKLs. I use a separate Leopold mechanical numpad placed on the left, so that the home row keys are more or less centered in my keyboard tray and under my monitor.

Also much nicer for playing Civ and other games that don't use WASD for camera control.

Also spreadable across multiple downloads (or base64ed Usenet posts...), which was very useful to some sectors back in the days of 28.8kbps connections.

They have annual subscriptions that get sharply discounted on a regular basis, where it comes out closer to $70 a year. I pay for that, since I usually do need the editing help, but the linked article certainly gives me pause.

Think 5200 is in the middle of your first two, since I believe architecturally it was a 400 without a keyboard (or more accurately, the 400 was basically a 5200 with a keyboard).

But yeah, that's super interesting too. I skipped Lynx in my console journey so wasn't as familiar with that, but I didn't realize the 3DO (which I did have) was loosely part of the talent family too. But yeah, now that I think about it, I guess Hawkins must have ended up tapping the talent pools freeing up from the ST/Amiga/GS generations since those died out right around the time 3DO was being developed.

It's even more interesting. Commodore hired a bunch of ex-Atari people for the Amiga while Tramiel was building his cadre for what became the ST. They basically swapped talent.

https://dfarq.homeip.net/atari-st-vs-amiga/