> ParticleDB 1.1.4 claimed to be a Postgres-compatible database ... Instead, we found a library of confusion
> exhibited frequent, profound transactional anomalies in essentially every way we could measure. We routinely observed the loss of committed writes, internal consistency violations, G1a (Aborted Read), G1b (Intermediate Read), and P4 (Lost Update). In the append workload, successfully appended values would routinely disappear from later reads of a given key. Our test suite inferred every kind of cyclic anomaly including G0, G1c, G-Single, and G2-item, but many of these can be attributed to more basic issues, like write loss. These issues occurred with a single server and without faults, and affected every transaction mode, interface, and WAL mode tested
I'm part of the ParticleDB team. We took these findings seriously and have spent the past few months addressing them and strengthening our testing. We now run sustained Jepsen workloads daily alongside our own test suites. We've also narrowed the supported transaction modes to focus development and testing on core correctness.
Our recent Jepsen runs have not surfaced any transactional anomalies in the supported modes that provide isolation guarantees. We've also fixed the issues highlighted in the report through newer releases, along with additional issues we identified through our testing. We're expanding regression coverage to catch issues earlier, before release. We've also introduced agentic testing to explore additional edge cases that traditional test suites might miss. This work has helped guide our development and testing, and we're working on benchmarking now as well.
> We now run sustained Jepsen workloads daily alongside our own test suites.
Why would anyone believe you when you say this? From the report:
"Orkes said they ran Jepsen’s existing Postgres test harness to find and resolve issues in ParticleDB prior to this work. However, that same test harness failed immediately when run against ParticleDB 1.1.4. Orkes also stated they tested ParticleDB with SQLancer, which generates far more complex queries than the ones we tested. It is therefore perplexing that nearly every feature we tested exhibited glaring errors, and that our findings seemed to come as a surprise.
Most databases have a test suite which exercises at least basic examples of each feature, and it is customary to run those tests before release, if not continuously. Where were those tests for ParticleDB? How does one add support for NOT NULL constraints without a test which tries to insert at least one NULL value? What development process adds a CHARACTER(10) type without trying to write a string of (e.g.) five characters?
Our findings suggest structural deficiencies in the ParticleDB QA process. Perhaps tests were not run prior to release. Perhaps the test suite was run, but failed to exercise basic functionality. Perhaps engineers entrusted Large Language Models with the work of testing."
Why did you pay Aphyr to find all these holes in ParticleDB? Didn't you know about them before? I wish you the best, but this doesn't sound reassuring.
Fixing clearly identified issues is table stakes. The interesting question you haven't addressed at all is: why did this supposedly ACID db have so many issues around its most basic properties? Smells of a design issue.
Honestly best thing to do is to delete this and wipe out its existence and start a new project from scratch and rebuild the reputation for the company.
No one in their right mind will use this product ever.
these were tests done on pre release builds and some experimental concurrency modes as well.... The engine has since been redesigned and all of these issues have been fixed..
Its also faster than Redis for KV, also numbers show this should be top on clickbench, official submission is in progress
Why should anyone believe that? I mean it might be true, I don't know. But if such a report turns out many fundamental issues it doesn't quite sound plausible that a redesign would suddenly not have any issues anymore. It might have fewer issues, it likely will have different issues as well though.
This is like paying for a pentest of a treehouse, and claiming that this implies the updated treehouse with a working padlock instead of a novelty lock is in the same league as a bank or a data center.
It makes mongodb from the report a decade ago look good.
Most Jepsen tests leave me with the impression "databases are damn complicated and difficult to get right". My thoughts with this particular report are "I'll never ever touch this DB if I can help it".
Jepsen is a fantastic tool - and one every database engineering team should have in their arsenal - but it proves the presence of bugs, not the absence of them. It is not formal verification, just a more rigorous form of existential testing.
I was referring to this claim from before the Jepsen report, which they have of course now quietly removed:
> ParticleDB’s home page advertised that ParticleDB was “formally proven” with a TLA+ proof. However, during our collaboration no TLA+ specification was available.
Bro you've got to be kidding. pre-release builds? Aphyr directly addresses this in this analysis. Furthermore, given the absolutely ridiculous nature of some of these bugs, and the low confidence exhibited by the authors in the fixes, how can anyone assume that suddenly things are correct? The database was so janky that it sounds like most of the time was spent on basic bugs that a decent set of unit-tests would've caught. Who knows what wasn't uncovered because the db was so broken to begin with?
I mean did you see the "primary key equality" thing? Holy shit.
> ParticleDB’s home page advertised that ParticleDB was “formally proven” with a TLA+ proof. However, during our collaboration no TLA+ specification was available. It is unclear what properties might be proven, or whether they described ParticleDB as built.
> Given the severity and extent of the safety errors we found, and the process which produced them, Jepsen recommends users halt further deployment of ParticleDB and migrate to other databases as soon as possible. Consider checking and/or rebuilding database state from more reliable sources, if available.
I guess that's what happens when you vibecode a database...
> We present 96 issues in ParticleDB, ranging from the pedestrian (crashes, deadlocks, data loss, etc.) to the piquant (partially-invisible rows which could not be deleted, WHERE 4 = 5, dropped tables re-emerging in distorted forms, confused columns, strings turning into integers, and so on).
Definitely seems worse than usual (looking back most databases seem to have <10 issues total, and the majority seem "mild") - since it's a database for AI was it also likely vibe-coded or just new? Then again even if new, I wouldn't expect so many issues in a stable release
I’ve come to learn an interesting dichotomy in software:
Some software is correct by construction, in the sense that the overall design makes sense and the cases that don’t work are generally local bugs.
Some software is incorrect by construction, and it tends to work by some combination of luck and by carefully working around the incorrect design in most or all code paths that could expose the incorrectness. (AI can be quite effective at finding the relevant places to insert workarounds.)
ParticleDB sounds like the latter category. Plenty of large projects have portions that are in one category and portions that are in another.
As an aside, for the last day or two, I’ve been contemplating that the Linux kernel’s handling of folio pinning seems to be in the incorrect-by-construction category. Good times. No, I haven’t found a hard-to-fix bug that I would credibly characterize as a security or likely accidental corruption issue [0], but this seems mostly like luck.
[0] I do appear to have re-discovered a bug that some massive Anthropic dump from a couple months ago also found, and it’s getting fixed. If your application does “fixed” io_uring I/O or certain types of iommu-based or maybe RDMA on a memfd, you might plausibly encounter it on rare occasions. I didn’t bother making a reproducer.
Congrats to the particledb team for getting this far and thanks to @aphyr for the analysis.
It takes gumption to build a new storage engine. I remember when etcd[0] first made it's way into @aphyr's cross-hairs. We took all of the input very seriously because we knew that a data store which is untrustworthy is useless.
Resolving these issues likely won't be easy, but if you can get to the point where you walk away from Jepsen unscathed the trust in your software will be greatly amplified.
It’s wild how bad it is. Not surprising for a vibecoded database, but why did they hire Kyle for a test, instead of first doing ANY testing themselves?
Imagine asking for a review before checking with the brutally powerful agents we have today all the low hanging fruits. And, at the point we are, you can likely go at incredible levels of automated bugs seeking and do the whole test in house.
It is months that I find subtle bugs far more complicated than the most immediately findable issues in the report. Together with the rest of the world. So there must be something wrong with their AI usage.
And you still have to make sure all the real constraints are in. I had to fix a proven correct distributed algorithm that just happened to believe updates were done atomically and with no latency.
(Edit for clarity: this is quoted from the linked article)
You could write predicates over non-existent columns:
root=> SELECT * FROM t
WHERE definitely_not_a_column = 4;
a | b
---+----
4 | 5
(1 row)
Or ask if 4 = 5
root=> SELECT * FROM t WHERE 4 = 5;
a | b
---+----
5 | 6
(1 row)
Good on them for being good sports I guess, but after reading this I would never touch a piece of software built by anyone involved with this company. The sheer hubris of their claims combined with the specific reality of their broken garbage software (with the contradicted marketing claims and hallucinated documentation) is literally breathtaking.
It must have been darkly amusing to see all these defect tickets coming in, only for them to frantically shovel each one to increasingly overworked LLM agents to apply pig-lipstick while the humans in charge oh-so-slowly start to realize their software quality is not quite what their glazing agents had been telling them and that what they have on their hands is basically sub-mongo-quality slop. What a world we live in, huh?
I won't push back on it being garbage, but I would suggest that if enough people did it that way it would be the new normal, and apologists would fall out of the woodwork, e.g. [1]
I complain that mainstream SQL engines have no problem returning less than the total number of rows if you first query WHERE column = NULL and then query WHERE column <> NULL. Your example queries remind me of that.
I am rather receptive to the argument that SQL is a fractal of bad design. But complaining that SQL engines implement well known SQL semantics according to spec is silly.
> WHERE column = NULL and then query WHERE column <> NULL
With respect, your statement seems to indicate that you simply haven’t heard of or don’t understand the three-valued-logic semantics behind SQL.
NULL means what it means and is conceptually foundational to SQL. Comparing it to anything returns UNKNOWN, the “third value” besides true and false. And WHERE needs a TRUE predicate. So your implied fault that they “have no problem“ really is just a matter of you not understanding the tool you are complaining about.
To match against the NULLness of a value you must use special purpose operators. In this case
Since the library claims to be postgres compatible, I wonder if its developers ran the existing postgres jepsen suite against it (possibly with some adjustments). Or why not.
Especially now, where you could probably just ask AI to adapt the existing suites to the cosnistency claims this database makes, and get something useful out of it. While certainly not as good as a professional test, I'd expect it to at least find some low hanging fruits before going for the expensive and public official Jepsen test.
"Orkes said they ran Jepsen’s existing Postgres test harness to find and resolve issues in ParticleDB prior to this work. However, that same test harness failed immediately when run against ParticleDB 1.1.4. Orkes also stated they tested ParticleDB with SQLancer, which generates far more complex queries than the ones we tested. It is therefore perplexing that nearly every feature we tested exhibited glaring errors, and that our findings seemed to come as a surprise."
I am not sure I would want my database tested by a vendor who feels it their duty to provide color commentary on my software development methodology in a public report, no matter how rigorous their evaluation.
Is/was ParticleDB open source? There is a Github link on their website, however the only public repo in their org seems to be the Golang client library.
No, they’re aware they don’t possess copyright on the source code because it has not one scintilla of human effort, so keeping it secret is the only legal way to protect it! :)
I wonder what the internal testing pipeline looked like before this. A codebase with that many fundamental issues suggests either no integration tests were written or they were all mocked out to pass green. It seems strange that a team would market a system as formally proven without actually running the workload through even basic consistency checks themselves first.
That part is the weird bit to me. If the existing harness breaks right away, that's the signal to stop and fix things, not to book an outside audit. Running the suite in CI on every build would have caught a lot of this.
> Running the suite in CI on every build would have caught a lot of this
yeah, provided:
1. test cases are being designed to cover functionality
2. test cases are implemented correctly - i.e. they actually fail if the implementation is defective
3. the tests aren't all commented out
4. the test suite fails if a test fails
5. CI actually detects test suite failure
6. failing tests block changes from being merged (apart from initial triage to stabilise the suite)
Presumably a few of these things weren't being done -- I'd bet 1 & 2 were skipped or implemented so poorly that they were worse than having no tests at all -- checking nothing but giving a false illusion that some kind of testing had happened.
Five years ago, outsourcing your software development (including QA) to the lowest bidder might have gotten you results like this -- if you didn't explicitly require automated tests as a deliverable, you wouldn't get any, or if you got some they'd be vacuous and not test anything.
Brutal!
> ParticleDB 1.1.4 claimed to be a Postgres-compatible database ... Instead, we found a library of confusion
> exhibited frequent, profound transactional anomalies in essentially every way we could measure. We routinely observed the loss of committed writes, internal consistency violations, G1a (Aborted Read), G1b (Intermediate Read), and P4 (Lost Update). In the append workload, successfully appended values would routinely disappear from later reads of a given key. Our test suite inferred every kind of cyclic anomaly including G0, G1c, G-Single, and G2-item, but many of these can be attributed to more basic issues, like write loss. These issues occurred with a single server and without faults, and affected every transaction mode, interface, and WAL mode tested
Writing databases is an EXTREMELY fun learning endeavour but it is truly difficult to do correctly.
Once I started writing one (I could say I still am) because I was unhappy with most of them and also, to see how hard it could be
Alas! It turns out it's really hard to do it right.
I'm part of the ParticleDB team. We took these findings seriously and have spent the past few months addressing them and strengthening our testing. We now run sustained Jepsen workloads daily alongside our own test suites. We've also narrowed the supported transaction modes to focus development and testing on core correctness.
Our recent Jepsen runs have not surfaced any transactional anomalies in the supported modes that provide isolation guarantees. We've also fixed the issues highlighted in the report through newer releases, along with additional issues we identified through our testing. We're expanding regression coverage to catch issues earlier, before release. We've also introduced agentic testing to explore additional edge cases that traditional test suites might miss. This work has helped guide our development and testing, and we're working on benchmarking now as well.
> We now run sustained Jepsen workloads daily alongside our own test suites.
Why would anyone believe you when you say this? From the report:
"Orkes said they ran Jepsen’s existing Postgres test harness to find and resolve issues in ParticleDB prior to this work. However, that same test harness failed immediately when run against ParticleDB 1.1.4. Orkes also stated they tested ParticleDB with SQLancer, which generates far more complex queries than the ones we tested. It is therefore perplexing that nearly every feature we tested exhibited glaring errors, and that our findings seemed to come as a surprise.
Most databases have a test suite which exercises at least basic examples of each feature, and it is customary to run those tests before release, if not continuously. Where were those tests for ParticleDB? How does one add support for NOT NULL constraints without a test which tries to insert at least one NULL value? What development process adds a CHARACTER(10) type without trying to write a string of (e.g.) five characters?
Our findings suggest structural deficiencies in the ParticleDB QA process. Perhaps tests were not run prior to release. Perhaps the test suite was run, but failed to exercise basic functionality. Perhaps engineers entrusted Large Language Models with the work of testing."
Why did you pay Aphyr to find all these holes in ParticleDB? Didn't you know about them before? I wish you the best, but this doesn't sound reassuring.
Fixing clearly identified issues is table stakes. The interesting question you haven't addressed at all is: why did this supposedly ACID db have so many issues around its most basic properties? Smells of a design issue.
Honestly best thing to do is to delete this and wipe out its existence and start a new project from scratch and rebuild the reputation for the company.
No one in their right mind will use this product ever.
I wonder if it’s vibe coded by amateurs
these were tests done on pre release builds and some experimental concurrency modes as well.... The engine has since been redesigned and all of these issues have been fixed..
Its also faster than Redis for KV, also numbers show this should be top on clickbench, official submission is in progress
Why should anyone believe that? I mean it might be true, I don't know. But if such a report turns out many fundamental issues it doesn't quite sound plausible that a redesign would suddenly not have any issues anymore. It might have fewer issues, it likely will have different issues as well though.
Because this is why companies pay for jepsen tests. Not because they enjoy to be destroyed in jepsen report, but to fix the issues.
This is like paying for a pentest of a treehouse, and claiming that this implies the updated treehouse with a working padlock instead of a novelty lock is in the same league as a bank or a data center.
It makes mongodb from the report a decade ago look good.
I'm not saying it is proof it is done. But most likely they are working on it
Most Jepsen tests leave me with the impression "databases are damn complicated and difficult to get right". My thoughts with this particular report are "I'll never ever touch this DB if I can help it".
Ok sure, so an LLM told you all the bugs are fixed and it’s faster than Redis, just like how it told you before that it was formally verified?
Please try to resist the urge of being a meat proxy.
> before that it was formally verified
Jepsen is a fantastic tool - and one every database engineering team should have in their arsenal - but it proves the presence of bugs, not the absence of them. It is not formal verification, just a more rigorous form of existential testing.
I was referring to this claim from before the Jepsen report, which they have of course now quietly removed:
> ParticleDB’s home page advertised that ParticleDB was “formally proven” with a TLA+ proof. However, during our collaboration no TLA+ specification was available.
https://github.com/ClickHouse/ClickBench/pull/2952
Bro you've got to be kidding. pre-release builds? Aphyr directly addresses this in this analysis. Furthermore, given the absolutely ridiculous nature of some of these bugs, and the low confidence exhibited by the authors in the fixes, how can anyone assume that suddenly things are correct? The database was so janky that it sounds like most of the time was spent on basic bugs that a decent set of unit-tests would've caught. Who knows what wasn't uncovered because the db was so broken to begin with?
I mean did you see the "primary key equality" thing? Holy shit.
> and all of these issues have been fixed..
You can't be sure until they test it again
I look forward to the second report from Jepsen for the new implementation then.
> ParticleDB’s home page advertised that ParticleDB was “formally proven” with a TLA+ proof. However, during our collaboration no TLA+ specification was available. It is unclear what properties might be proven, or whether they described ParticleDB as built.
> Given the severity and extent of the safety errors we found, and the process which produced them, Jepsen recommends users halt further deployment of ParticleDB and migrate to other databases as soon as possible. Consider checking and/or rebuilding database state from more reliable sources, if available.
I guess that's what happens when you vibecode a database...
> We present 96 issues in ParticleDB, ranging from the pedestrian (crashes, deadlocks, data loss, etc.) to the piquant (partially-invisible rows which could not be deleted, WHERE 4 = 5, dropped tables re-emerging in distorted forms, confused columns, strings turning into integers, and so on).
Definitely seems worse than usual (looking back most databases seem to have <10 issues total, and the majority seem "mild") - since it's a database for AI was it also likely vibe-coded or just new? Then again even if new, I wouldn't expect so many issues in a stable release
The discussion section of the report is very damning.
[dead]
I’ve come to learn an interesting dichotomy in software:
Some software is correct by construction, in the sense that the overall design makes sense and the cases that don’t work are generally local bugs.
Some software is incorrect by construction, and it tends to work by some combination of luck and by carefully working around the incorrect design in most or all code paths that could expose the incorrectness. (AI can be quite effective at finding the relevant places to insert workarounds.)
ParticleDB sounds like the latter category. Plenty of large projects have portions that are in one category and portions that are in another.
As an aside, for the last day or two, I’ve been contemplating that the Linux kernel’s handling of folio pinning seems to be in the incorrect-by-construction category. Good times. No, I haven’t found a hard-to-fix bug that I would credibly characterize as a security or likely accidental corruption issue [0], but this seems mostly like luck.
[0] I do appear to have re-discovered a bug that some massive Anthropic dump from a couple months ago also found, and it’s getting fixed. If your application does “fixed” io_uring I/O or certain types of iommu-based or maybe RDMA on a memfd, you might plausibly encounter it on rare occasions. I didn’t bother making a reproducer.
Congrats to the particledb team for getting this far and thanks to @aphyr for the analysis.
It takes gumption to build a new storage engine. I remember when etcd[0] first made it's way into @aphyr's cross-hairs. We took all of the input very seriously because we knew that a data store which is untrustworthy is useless.
Resolving these issues likely won't be easy, but if you can get to the point where you walk away from Jepsen unscathed the trust in your software will be greatly amplified.
0: https://aphyr.com/posts/316-call-me-maybe-etcd-and-consul
Finding issues is normal. But the bold claims they had on their website is what makes this a bust.
It’s wild how bad it is. Not surprising for a vibecoded database, but why did they hire Kyle for a test, instead of first doing ANY testing themselves?
No doubt because the LLM said it was ready to pass Jepsen.
^^ this is funny, but I think that's likely how it has happened.
Imagine asking for a review before checking with the brutally powerful agents we have today all the low hanging fruits. And, at the point we are, you can likely go at incredible levels of automated bugs seeking and do the whole test in house.
My understanding is that Orkes did, in fact, ask AI agents to test ParticleDB in-house prior to our collaboration.
It is months that I find subtle bugs far more complicated than the most immediately findable issues in the report. Together with the rest of the world. So there must be something wrong with their AI usage.
> ParticleDB’s home page advertised that ParticleDB was “formally proven” with a TLA+ proof.
Perhaps they meant formerly, probably just a speech to text problem
TLA+ doesnt prove the code. if they never read the proof, then how do we k ow that it proved the right things?
And you still have to make sure all the real constraints are in. I had to fix a proven correct distributed algorithm that just happened to believe updates were done atomically and with no latency.
lol, reminds me of the common misreading "provably safe" / "probably safe"
Shipping a bug like "WHERE 4 = 5" returning rows says it all to me
https://github.com/particledbai/jepsen/issues/18 is utterly humiliating. I can’t believe they kept going after getting that report. I would die of shame.
(Edit for clarity: this is quoted from the linked article)
Good on them for being good sports I guess, but after reading this I would never touch a piece of software built by anyone involved with this company. The sheer hubris of their claims combined with the specific reality of their broken garbage software (with the contradicted marketing claims and hallucinated documentation) is literally breathtaking.It must have been darkly amusing to see all these defect tickets coming in, only for them to frantically shovel each one to increasingly overworked LLM agents to apply pig-lipstick while the humans in charge oh-so-slowly start to realize their software quality is not quite what their glazing agents had been telling them and that what they have on their hands is basically sub-mongo-quality slop. What a world we live in, huh?
I won't push back on it being garbage, but I would suggest that if enough people did it that way it would be the new normal, and apologists would fall out of the woodwork, e.g. [1]
I complain that mainstream SQL engines have no problem returning less than the total number of rows if you first query WHERE column = NULL and then query WHERE column <> NULL. Your example queries remind me of that.
[1] https://medium.com/dailyjs/the-why-behind-the-wat-an-explana...
I am rather receptive to the argument that SQL is a fractal of bad design. But complaining that SQL engines implement well known SQL semantics according to spec is silly.
NULL means what it means and is conceptually foundational to SQL. Comparing it to anything returns UNKNOWN, the “third value” besides true and false. And WHERE needs a TRUE predicate. So your implied fault that they “have no problem“ really is just a matter of you not understanding the tool you are complaining about.
To match against the NULLness of a value you must use special purpose operators. In this case
Since the library claims to be postgres compatible, I wonder if its developers ran the existing postgres jepsen suite against it (possibly with some adjustments). Or why not.
Especially now, where you could probably just ask AI to adapt the existing suites to the cosnistency claims this database makes, and get something useful out of it. While certainly not as good as a professional test, I'd expect it to at least find some low hanging fruits before going for the expensive and public official Jepsen test.
The company says they did. From the post
"Orkes said they ran Jepsen’s existing Postgres test harness to find and resolve issues in ParticleDB prior to this work. However, that same test harness failed immediately when run against ParticleDB 1.1.4. Orkes also stated they tested ParticleDB with SQLancer, which generates far more complex queries than the ones we tested. It is therefore perplexing that nearly every feature we tested exhibited glaring errors, and that our findings seemed to come as a surprise."
Seems to me that “we ran the Jepsen test” is just something an LLM thought would sound good on a DB’s website.
Aphyr does great work, Jepsen always kicks it out of the park :)
Every database vendor should pay to get their software Jepsen-tested.
I am not sure I would want my database tested by a vendor who feels it their duty to provide color commentary on my software development methodology in a public report, no matter how rigorous their evaluation.
Great to implement a DB just like human memory, unstable, and untrustworthy.
Is/was ParticleDB open source? There is a Github link on their website, however the only public repo in their org seems to be the Golang client library.
https://github.com/orgs/particledb-ai/repositories
SDKs are MIT license CLI tools and Studio will be also be MIT License
Server is not open source for now but free for developers
“No.”
Afraid to show the slop?
No, they’re aware they don’t possess copyright on the source code because it has not one scintilla of human effort, so keeping it secret is the only legal way to protect it! :)
I am wondering how this was allowed to be tested from a corporate strategy point of view of the company Orkes.
This is such a huge reputational hit, seems like a terrible outcome for a Series B company funded by big name VCs
What does this say about their main product?
> how this was allowed to be tested
I can see it happening if they genuinely had no idea of how defective / non-existent their internal QA & testing processes were.
Slop DB written in Rust. They probably changed the landing page after the bad results, you can still see the old one: https://web.archive.org/web/20260518203012/https://particled...
"Written in Rust · Formally Verified · PostgreSQL Compatible"
Fatality
-https://github.com/jepsen-io/particledb is currently 404 (probably still private?)-
EDIT: It's up now
Sorry about that--yes, it's still private. Hoping to have that resolved shortly.
Looks like it's up now. I'll put that link in the toptext as well. Thanks!
I wonder what the internal testing pipeline looked like before this. A codebase with that many fundamental issues suggests either no integration tests were written or they were all mocked out to pass green. It seems strange that a team would market a system as formally proven without actually running the workload through even basic consistency checks themselves first.
That part is the weird bit to me. If the existing harness breaks right away, that's the signal to stop and fix things, not to book an outside audit. Running the suite in CI on every build would have caught a lot of this.
> Running the suite in CI on every build would have caught a lot of this
yeah, provided:
Presumably a few of these things weren't being done -- I'd bet 1 & 2 were skipped or implemented so poorly that they were worse than having no tests at all -- checking nothing but giving a false illusion that some kind of testing had happened.Five years ago, outsourcing your software development (including QA) to the lowest bidder might have gotten you results like this -- if you didn't explicitly require automated tests as a deliverable, you wouldn't get any, or if you got some they'd be vacuous and not test anything.
[dead]