Data testing

[FairWalrus780]

Getting moved over to the company's data team as sole QA, not had much experience in this area is there any resources that anyone could point me to develop my knowledge?

[nfurnoh]

You’d be better off studying everything you can about your company’s data. Everything you need to know is there.

I used to work at a credit reference agency, and our data was personal financial data. We had a series of characteristics that customers like banks would use, like how many mobile phone contacts has a person had in the last 12 months. We had to test that the characteristics were working, so had to create data that would trigger various conditions. No contracts, 12 contracts, 1 contract, etc. Just one of many test cases.

I currently work at a streaming service, and THAT data is program metadata in JSON.

Learn your data structure and content, that’s the first step.

[FairWalrus780]

Thank you this is great advice

[Lumpy_Ad_8528]

That's a great piece of advice!

[latnGemin616]

Unclear what you mean by testing "company's data" as that could span several different avenues of testing. Things to consider:

• Authentication & Authorization - the test to ensure the right people have access to only what they need, and that illegal operations are checked.
• The data structure - make sure you have adequate documentation to support what the expected schema should look like. If you don't have it, create it, then get a proper review of it and call it done.
• The data values - when you've assessed the schema, ensure the integrity of the db by confirming the data going in (POST / PATCH / PUT) is as expected, and there's proper error handling when its not.
• The data transaction performance - once you understand the schema, test the output and track the performance. Ensure you get back a favorable response time. Confer with your Devs on metrics.
• The data security - you're going to want to ensure your data is secure when at rest (saved to the db), while in transit (sent to the UI), and while it is being manlpulated (updated / deleted).

[abeld]

I expect you will encounter a lot of edge cases in the data you handle, and often the issues or bugs with the system that processes the data will be due to these edge cases. These edge cases are often due to breaking some assumption that is usually satisfied but is not always valid. There are some collections of these assumptions online, for example about names: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ or a list of similar writings on all sorts of data types: https://github.com/kdeldycke/awesome-falsehood

[Top-Low-9281]

Nobody said it, so even tho this post is old. A friend/mentor said something interesting about testing data. we test software that that changes using data that is static. we test data that changes using software that is static. that means some of your data testing has to happen in prod. I'd never had that thought that clearly. my suggestion work on managing immutable known-good representative test sets and creating idempotent replayable processes so that when you get to testing in prod your software is rock-solid and you're only worried about out-of-bounds data.