Just curious. When SAS started pushing for automation tests to facilitate CI/CD did it also bring about the demise of many of the senior testers? If so who will make changes when UIs are modified? Did the layoffs affect many developers? Will they be doing the automations now?
17 replies (most recent on top)
Again, incompetence was never a firing offense. At the management level, it prevented employees from doing their best work.
And it made SAS a one-trick pony. We never created new revenue streams to replace the original.
As a result, in each of the past three years we’ve seen ~5% headcount reductions — through buyouts, attrition, public layoffs, and “stealth layoffs” of senior employees.
This is sad for all of us who worked hard to create lasting value.
But at least it’s gradual, minimizing impact to current employees.
And at least it’s clear. Particularly after the way that last public layoff was handled, no one can have any illusions about the future.
"He had me in his office one day and told me that HIS code never needed testing because it had never had a reported bug."
LOL. Right after I started at SAS I had a senior SAS Access for Teradata developer "Nobug" a pretty egregious ETL Defect I reported because no external customer had reported it yet.
After Sas bought a 3-D graphics software company I remember working in the group that was spun off the purchase. The department manager had written a minor level proc that did some sort of graphics - I don't remember exactly what but it was no big deal. He had me in his office one day and told me that HIS code never needed testing because it had never had a reported bug.
I never forgot that. A life lesson in self delusion.
The crux of SAS’ problem can be illustrated by an equilateral triangle.
The founder himself is the apex. The retention of incompetent nincompoops for years-to-decades the L base point, and the hiring/promotion of highly-paid execs (who in some cases have not bothered to learn/respect SAS' R&D DNA) the R base point.
The area of this triangle represents all the dysfunction and noise that has led to SAS’ demise beginning 25 years ago. One extremely tough former home-grown leader tried to address this and it was too much for even him. At this point it's fundamentally irreparable.
@3kfo+1odd2syB Regardless of what is being said by BH and others, none of this is about poor performers or improving quality. The tester layoff is a good example of picking the low hanging fruit. Older and probably going to retire anyway so push its along.
Everything we see happen is a direct result of bad management and decision making that goes back decades and it ultimately is due the decisions of one person because in the end, only one person makes any decisions of substance at SAS. But it's OK because he is kind to his employees.
They should pare back the art collective, otherwise known as Design.
One of many unusual aspects of SAS is that incompetence was not a firing offense. This was true in other departments, not just testing.
Management made no effort made to improve the quality of our work force. Rather, their goal was to retain those we had hired.
Of course, managers can never hire perfectly. So we all had to live with their mistakes.
Even today, this policy continues. There are testers remaining who cannot do automation. And some of those laid off were among our best.
SAS has good testers. You know who you are. You're the ones putting the entire weight of your test teams on your shoulders. This message is not directed at you.
I believe SAS did itself a disservice treating testers as a lesser group than developers. Disagree? At many other tech companies the hiring bar for testers is equal (or greater) to that of developers, the pay scales are the same, the value given to input in discussions is the same, etc. SAS did not create an environment where this was true.
In my 10 years at SAS I saw many many incompetent testers. You could hold their hand, show them which buttons to click or which test suites to copy and paste and change the values and they could repeat the process. This is useful only to an extent. We do not live in a world anymore where it's useful for someone to write 50 page word docs spelling out every button to click, what outcome it should produce, etc. They should be writing that in automation.
Also, I'm mostly not talking about testers with domain expertise, like those with Stats backgrounds testing the correctness of outputs of procs/actions. As some have pointed out that should have been automated for years.
Who needs testing? The customers will test it, report the bugs, and they’ll be fixed in next month’s release.
"As one dev manager said to me he has not seen any relevant bugs come through due to automation finding it."
ROFLMAO
Maybe The Next New Old Thing will come along and save us.
Most of the test automation will never happen. If management wanted automation, they would not have laid off testers -- or they’d replace them with younger, cheaper ones.
They’re doing neither, because what’s being readied for IPO is not the software. It’s the revenue stream.
Wall Street quants will model the revenue stream. Inputs to their model will include costs, sales, growth/decline, and duration.
Test automation will not be in their model.
For those of us who built and tested SAS software, it’s deeply sad; but this drives all decisions now.
“
As one dev manager said to me he has not seen any relevant bugs come through due to automation finding it.
“
Many of the most relevant bugs in a complex system like SAS (…and if your experience is mostly at the UX/UI level this complexity may seem unfathomable) are found by developers, studying their code carefully, walking through it under a debugger, and thank you to clever use cases/testing scenarios that push the dynamics of algorithm boundaries, etc.. At a higher level occurs when astute architects recognize areas were a complex system does not have correct boundary and cohesion properties.
No amount of micromanagement via things like Agile/SCRUM or “process improvements” via new test automation (SAS has had testing automation for 30 years) frameworks will change this.
SAS had considerable technical debt last time I checked. Until a clear actual vision is articulated and followed this will continue. No amount of Agile or process improvement/automation will fix this.
yeah good luck with that. Automation tests fail constantly not because it finds real issues with the product but because it is flakey and inconsistent. Then you have a situation where everyone ignores the failures because they think it's the automation acting up again. As one dev manager said to me he has not seen any relevant bugs come through due to automation finding it.
Retired here also, and finding this all very sad. I posted similar questions on previous threads, and got these answers:
“I think the plan is to cut expenses with no regard to the viability of individual product operations long term. It feels like we are looking at the end of year numbers and nothing else.”
— https://www.thelayoff.com/post/@fcue+1nEDyXdA
“From a senior manager, you must realize what position the company is at this moment. Sales could be better and there will be an IPO next year. Plain and simple, the company needs money and needs to lower the average age of its employees to be a more attractive IPO.”
— https://www.thelayoff.com/post/@8qjx+1nAfoEPz
Remember the buyouts. On the older SAS products, like SAS/STAT, many developers and testers were older also. Many of those people took the buyouts, and they were not replaced.
So is SAS willing to sacrifice development and testing, for the sake of reducing headcount? Yes. Yes, they are. And they’ve been doing this for several years.
"Tests are now completely automated and integrated into the CI/CD system. So, yeah, no need for testers anymore."
Yeah, no. That's not true. The tools necessary to do fully automated testing have existed for many years. SAS used a test suite called "Test Automator" that IIRC was home-grown as were many of SAS's other internal tools (sdssas, sdstest, Defects, Midas, Factrack, etc.). Several of the recently laid-off testers were probably very familiar with it, having used it for many years.
However, as others have said in several recent threads, SAS software doesn't expose the metadata (named UI elements or tags on UI elements) necessary for automated testing as a customer using the product, and never has. It was never a priority, and there probably exist several dozen (if not hundreds) of associated Defects, all of which have been dispositioned "Future" or "Not a defect" and buried under years of technical debt as the dev teams "burn down" their Defect count to zero before every ship event.
The kind of "automated testing" being done by the CI/CD pipeline is the same automated testing that was done by sdstest, with a few additions for products of the CI/CD pipeline itself.
No need for testers? Who would write additional tests that will be needed when the software is updated? And who would evaluate the test results? I spent ten years in Quality Assurance at SAS way back, and the results of even automated tests have to be evaluated.
This is a purely academic question for me, as I’m retired. I’m simply curious. Thanks.
Tests are now completely automated and integrated into the CI/CD system. So, yeah, no need for testers anymore.