Let's pretend you didn't know there was a table called `crontabber`. There are wrappers in the `_load_structure()` method. See [here for example](https://github.com/selenamarie/socorro/blob/bug983807-reprocessingjobs-test-fix/socorro/unittest/cron/jobs/test_automatic_emails.py#L479-L482)
What that does is that it does almost what your code does. 

There's another method, which when I think about it, I prefer more that is to refer to the `tab.job_database` object. 
[Here's an example](https://github.com/selenamarie/socorro/blob/bug983807-reprocessingjobs-test-fix/socorro/unittest/cron/jobs/test_automatic_emails.py#L949)

The advantage of the `_load_structure()` method is that verifying the crontabber state is 100% agnostic of the crontabber API stuff. 

But going forward the best way is to probably to use the `tab.job_database` thing. It wraps the [StateDatabase](https://github.com/selenamarie/socorro/blob/bug983807-reprocessingjobs-test-fix/socorro/cron/crontabber.py#L122) class which behaves just like a python `dict` but actually talks SQL behind the scenes. I like this more because it means that we can hide the implementation. For example, we could write to a different database, file, nosql, etc. but since its API is that of a python `dict` use shouldn't change. 

Basically, pretend that you didn't know the results are written to a table called `crontabber`.