Conveniently the test votes had real candidate name instead of Pokemon or something, also conveniently test votes were posted into production database, not QA.
^ Lesson number 1 for QA is to use demonstrably fake metadata. Lorem Ipsum is good and if you need realish metadata like email addresses, translate real ones (i.e. from adam@google.com to testaccount+adam.google.com@tester.com)
Also, prod and staging/QA/dev - never the twain shall meet.
It’s of course possible that “test data” was an excuse they made up after the fact. Maybe it’s a cover story to hide even worse incompetence (or maliciousness). Why did it require a candidate to notice that the sums between rounds were wildly different?
And wtf is a test ballot anyway? Are these physical ballots, or entries in the database? Neither inspires confidence in the integrity of this election.
> Also, prod and staging/QA/dev - never the twain shall meet.
You're expecting a lot from developers who were chosen because of their relation to elected officials rather than their domain expertise.
> The list of relatives stretches even to the [Board of Elections] computer programmers, including Rubén Díaz III, a Democrat who is the son of the Bronx borough president and grandson of a City Council member.
The flipside of this is that some defects can get through because assumptions made by the data used for QA/development might not be true for production but you don't find that out until the code is actually in production working with production data.
I think even for those who do not subscribe to any election fraud conspiracies, this will seriously shake confidence in the election. If a mistake like this went by unnoticed until the results were posted, what other monkeying about with the database goes on?
Also, prod and staging/QA/dev - never the twain shall meet.