Training a new MI/BI tester

🗄️ Archive
1

Hi all,

At my workplace I have a pair of apprentices who have joined my team, and I have been asked by the manager to be their teacher, coach and mentor.

Now, the problem I have with wanting to get them aware of testing and how to apply it, is the field of testing that I’m in and the team they’re in.

The team is MI/BI (depending on what others call it). So it is all databases and reports. No API’s, no GUI’s, no input fields. It will be testing either the data being migrated into the data warehouse, or testing the query used to build a report.
I’m still relatively inexperienced within MI, so whilst I can make them aware of ETL and what a data warehouse is for, I’m not going to be able to make them a master of MI testing.

I have shown them 30 Things Every New Software Tester Should Learn | MoT, as I make sure to show that to everyone new in the team.
I gave them a brief overview of the types of testing, so unit testing, functional testing, automation, performance, accessibility, as even though they won’t be doing all of it, they have an awareness it exists.

Last week I gave them a practical exercise, where I listed requirements for a report that I wanted built, asking for things like first and last name, date of birth, balance, account number. I then gave criteria for when a customer should or shouldn’t be displayed on the report.
I asked them to work out what tests they would do against the report, and then write SQL to return the data. One of them has some experience with SQL, the other has little, but has been practicing.
They came back with what tests they would do, poked holes in the requirements they were given, and then started working on the SQL. By the end of the next day, after some minor pointers from me, they were happy with what they had produced, as was I.

Ideally I would like to do something similar, to get them used to querying multiple tables, but also thinking about what they would test, raising questions if requirements aren’t clear enough, and also getting them used to working together. I said for the exercise they can work alone or together, and asking developers for help on tables or how to do things isn’t cheating, as that’s what would happen when working on a project. This isn’t an unrealistic interview scenario where they are locked alone in a room and no support given.

What type of things would you do to help teach them more about testing, and the ability to put it into practice?

Over time they will do both testing and development, with the development mainly being making lots of gradually more complicated SQL, if that makes any difference.

Thanks all!

1 Like
2

I think the route you are going down with them sounds good and the things I can think of are just variations on what you are doing. Give them exercises where the requirements need challenging or don’t give enough info.
For working together see if you can come up with an exercise that builds upon one already done by the other trainee. So one has to learn from the other about the work they did and the other trainee practices explaining their code/working to other people.
Last one is something I have done at work when teaching people SQL, set them a very challenging piece of SQL to write, once they have completed the writing part of it get them to switch hats and analyse what they have written from a testing perspective. Given the challenging nature of writing the SQL they will likely have abandoned the idea of testing their code to just get it done which will lead to assumptions being made and possibly shortcuts taken. Can use that as a teaching piece about the differences in a dev/building mindset compared to a testing mindset.

2 Likes
3

Hello @ThePirateTester and good luck with your task. A couple of things that might help are; (sorry its a bit of a long post!)

Four Hour Tester has some simple exercises on assumptions and is really good to help not take things at face value.


My visual heuristic on testing (sorry for the self-promotion)

I’m also training a new tester and below are some details from the plan I’ve come up with. If you think it is useful I can post more.

Overall Scope of training

  • Thinking like a tester (including community)
  • Language, Communication and Feedback
  • Testing Fundamentals
  • Exploratory Testing
  • Advanced Techniques
  • New to the company

On the job learning. As part of day to day working I believe a new tester will pick up the following so these are not covered specifically in the itinerary.

  • Ways of working (Agile; FrAgile; Scrum; Waterfall; Continuous Delivery; Incremental and Iterative, Pods/Tribes/Teams, Agile Passport)
  • Tooling (Team City, Octopus Deploy, TFS, MTM, SQL Server Studio, Soap UI, Selenium)
  • Products and systems
  • Living Documentation (feature files, Gherkin, Pickles)

Scope

Thinking like a tester
Why test? (Risk modelling)
What are we testing (client side/server side, data integrity, processing?)
Community (Ministry of Testing, blogs etc.)
Basic Thought Techniques (5 whys, Risk, what if, mind mapping. What could happen given every possible, practical scenario?)
Basic Personas
Assumptions (Mary had a little lamb – my workshop)
Biases
How much is out there (PToT)
Strategies, approaches and plans
Why bugs don’t matter and value adding, actionable insights and working together does
Using compassion and empathy in testing

Refs:
http://blog.xebia.com/mapping-biases-to-testing-confirmation-bias/

http://www.debonogroup.com/six_thinking_hats.php

Try Googling – Thought Techniques; Personas in software testing; Cognitive Biases; Ministry of Testing

3 Likes
4

Sorry for the slow response - only just saw this in the Club digest email. Sorry also to bang my own drum so much (many links to my blog below), but I’ve done ETL development and testing in the past so some of it might be useful. sigh I’ve tried posting this but only on posting am I told it’s <= 2 links per post. So I’ll split it up. sigh again. The posts with links in have been flagged as spam, so I’ll have to be more circumspect and less helpful in how I link to things. My blog is https://randomtechthoughtsblog.wordpress.com and I’ll link to things by saying what to search for there.

A big area (which you might have or not face) is data quality, and people new to the field often take good data quality for granted. How many assumptions can programmers make about the input data? Will rows need to be rejected if they are bad? Can duplicates be ignored? Can missing values be filled in with a default? Are joins between tables always inner joins, or do they have to be outer joins to cope with nulls or foreign key mis-matches?

This is summary of some ways I’ve tested ETL in the past - search for “Testing data preparation for a BI database”. It has implications for how rejects are handled, which leads to design for testability.

Another way of framing it is to think of each row of the input file as being analgous to one attempt at filling in all the fields on a web form (one column in the file -> one field in the form). So you can try all the normal ways of breaking a form - text in a date field, everything empty, everything too long etc. Then you can zoom out to file-level tests - empty file, binary rather than text file, v. long file, duplicate rows within the file. Then zoom out further to cross-file tests - duplicate files, files coming in very quickly (if it’s busy process file X when file X+1 arrives, will X+1 be ignored or processed later?)

1 Like
5

I don’t know what platform you’re using:

  • If it’s SSIS then there are some intro to SSIS articles on my blog too, search for “From Excel to SSIS”
  • If you’re using SQL Server then tSQLt search on my blog for tsqlt. tsqlt is sometimes really useful (beyond the normal unit test stuff) because it temporarily removes all constraints like columns being non-null, foreign keys etc, and allows you to re-introduce only the contraints that you want for right now.
6

I think it would be useful to make sure they know how to debug some SQL. Things like breaking it down into smaller and smaller pieces until you get to a bit that does what you expect (even if it’s trivially small) and then re-introducing bits gradually. So things like stripping out joins or bits of where clause, testing the inner-most bit of nested queries etc, often by commenting out bits you don’t want.

Re. your comment about clear requirements - I completely agree, particularly if the MI goes on to visualisations. It appears that I’ve been put on the naughty step for posting too many links to my blog. So the best I can do is say to search on my blog for “Visualisations and the stories behind them”, which I hope is useful.

Something I learned the hard way re. data dumps. If you take a dump from your database and put it in Excel so you can explore the data more easily, and/or compare snapshots of the data over time (particularly if you save it to CSV so you can use normal diff tools), remember to save the SQL too!

Sorry for the rambling scatter-gun of stuff, particularly if it’s stuff you already know. If anything’s unclear or I can help further please let me know.

1 Like