Lots of Tabpy activity

Looking back over the last few weeks I have had a ton of meetings.  One of the products my team owns is Tabpy and I have spent a good amount of time over there.

Specifically, I have been performing some code reviews coming in from the community (thanks gang!) and even had a call with one of the developers.  I also checked in some documentation changes over there to update some error messages to help make setup errors a bit more clear.

Also on the Tabpy front, we have had some team wide customer calls about how companies are using Python integration and how we can help them meet their goals.  Behind the scenes, we are taking notes, designing stories and entering a set of items to track this work in our backlog.  And yes, we are working on these items already, but I (obviously) can't share specifics.  That is simply a frustrating aspect of blogging about testing.

Questions, comments, concerns and criticisms always welcome,

John

Filling holes in test coverage

One of the tasks in my plate is to find and fill holes in test coverage.  A good question - which I am going to avoid for now - is how features ship with holes in coverage.  Instead, I want to focus on holes that get created over time.

For instance, my team owns the Trend Lines feature in Tableau.  Here is a sample image we have used to test for years:

You can see the multiple trend lines drawn, each with a confidence band around it.  We validate that we do not alter this expected visualization with each new version of Tableau using a simple image comparison.  We also validate the math behind this feature but I want to focus on the image for now.  This test has been running and passing for years.

So how can debt accumulate with this scenario?  One way it cropped up was adding a version of Tableau that works on the Mac.  Initially, when this test was created, only a Windows version of Tableau existed.  Since that point, we have added Tableau for the Mac, Linux (via server) and different flavors of server (Windows and Linux).  So now we have to verify we draw correctly on each new platform.

The hole gets created when some new supported configuration is added.  When we added Mac support, we obviously ran all our tests.  In this case, the Windows test did not break since we changed nothing for Windows.  And because we did not add a test for the Mac, the non-existent test did not fail (again, obviously).  But we never added that test so a hole existed.  We are filling that gap now, as well as Linux tests.

Questions, comments, concerns and criticisms always welcome,

John

Updating the tasks I posted from 2 weeks ago

Two weeks ago I posted a laundry list of to do items.  We are an agile team with a  2 week sprint cycle, so it seems natural to follow up on these.

Again, in no particular order:

1. We are getting some beta feedback on our features and are working on fixes for those items.  --- I contacted the person that submitted a key piece of feedback and showed him a proposed change.  He thought it was much better, so remain tuned.

2. Some of our unit tests use integration points to set up before the test runs. 
1. This is ongoing work.  In the past 2 weeks, I have refactored 4 tests.
2. I also had to update a new test we added because the path to one of the files "is too long."  Sigh.

3. Spent 2 hours performing backlog cleanup.  Consolidating related items, assigning tasks to stories, etc…

4. I actually tested Tableau :)

5. I also had time to jump over to Tabpy on github and perform a code review and merge there.

FWIW, 2 and 4 will be focus areas for the next sprint.  Let me know if you find these updates interesting.

Questions, comments, concerns and criticisms always welcome,

John

Top 3 Outlook tips to help with day to day life

Outlook has SO much functionality built into it that it can get overwhelming at times - meetings come in, reminders fire, emai pops up, etc.. etc… etc..

But there are some actions you can take to make your life much easier.  I share these with each new team I go to and want to put them here as well.  For Outlook "old-timers" (to which I belong since I was there for Outlook 97) these may seem obvious.  If you have never heard of these before, these may really help.

1. Create  a "cooling off" rule.  I have a rule set to delay all mail I send by 2 minutes.  This helps me a few times per year when I notice a typo at the last second, see that someone else replied while I was pressing send, or otherwise make some goof I need to correct.  Here's how



1. Open the Home tab | Rules | Manage Rules and Alerts…
2. Select Apply rule on messages I send | Next
3. 
   
4. Conditions is the next tab.  I leave this as is since I want this to apply to all my mail, so I click Next.  I get a popup that says this will apply to every message I send, and since that is exactly what I want, I click Yes.
5. Now I get the action I want Outlook to take.  I select Defer delivery by a number of minutes and change the link to 2:
6. 
7. Now all mail will wait in the Outbox for 2 minutes after I press send.
8. Exceptions can be useful.  You may want the rule to be Delay all mail by 2 minutes unless is it High Importance, so you can set exceptions like that here.
9. Click Finish and the rule is saved.
2. Second tip is helpful when an email thread is spiraling out of control.  Right click it and select "Ignore".  You will get an alert reminding you that this item and all replies, etc… will be moved to Deleted Items.  Nifty.
3.  Finally, I work remotely now and then and it is helpful to force Outlook to sync.  Yes, it syncs automatically, but if I know I am about to lose my wifi connection, I can force it to sync by hitting F9.  This is more useful in soothing my conscience, but it is a habit that mentally helps me so I keep doing it.

1 and 2 are the biggies.  They don't help every single day, but when they do help, they make a HUGE difference.

Enjoy!
 
Questions, comments, concerns and criticisms always welcome,
John

Back to work

Last week I had a trip to Palo Alto and this week I had a few days of internal training (which was quite good).  Now it is back to work.

And by work, this week I wanted to simply post a "laundry list" of tasks on my plate.

So, in no particular order:

1. We are getting some beta feedback on our features and are working on fixes for those items.  Stay tuned for more details on this as we get the work completed.
2. Some of our unit tests use integration points to set up before the test runs.  Refactor those to be closer to unit tests.  This gives a few benefits:
1. Slightly faster build times.  This work generally results in less code which generally builds faster.
2. Easier to know what happened when a test fails.  If a test has to complete three setup items before running the test (item four), then a failure reported could be one of the 3 setup items or a failure of the code you wanted to test.  In fact, the odds are 3/4 that your code is working fine, but something else in setup failed.  Less tasks to do make it easier to identify the source of a reported failure.
3. Our team had sprint planning this week.  I think I mentioned we do 2 week sprints.
4. We scrubbed our backlog to keep it current and reprioritized items as needed (see item #1 above for an example of what might cause planned work to be re-prioritized).
5. Two days of training (Changing your Viewpoint types of things)
6. I actually tested Tableau :)

Questions, comments, concerns and criticisms always welcome,

John

A quick jaunt to Palo Alto

The bigger organization within Tableau of which I am a part has a rather large team at our office in Palo Alto.  We had an All Hands meeting on Monday this week and I was able to attend in person.  I always like visiting Silicon Valley and decided I would ramble a bit about why this week.

1. The number of tech companies there is astounding.  Everywhere I look I see Microsoft, Amazon, Apple, iAm, Sophos, Salesforce and so on.  It just brings out the geek in me.
2. The shuttle we used was a Tesla.  Repeat: the shuttle was a Tesla.
3. The weather there is typically nicer than Seattle.  One exception: I was in San Francisco once and went from hail in the morning to 95 degrees in the afternoon.  Cue the Mark Twain quote.
4. It's always nice to step away from my desk now and then to get some new thoughts going.
5. Meeting the entire team in Palo Alto lets me a face with a name.

I also talked with a few folks that are facing some of the same challenges our team is facing.  Maybe we can collaborate to face them and not waste time duplicating work - nothing to do with Palo Alto, just good business.

All in all, an enjoyable trip worth the time investment.

Questions, comments, concerns and criticisms always welcome,

John

A code coverage analogy

One of the tasks I have on my plate is code coverage tracking.  I've written about this in the past and today I want to go over an analogy on the usefulness of this statistic.

First I can point out it is relatively easy to track.  We have plenty of tools to do this for us, get reports, etc…  But just because it is easy to track does not mean it is all that useful.  I can track the contents of my glove compartment each day, but I think we can all agree that this would not be a useful piece of data to have.  There is not much I would do differently on a day to day basis based on the contents of the glove compartment.

Code coverage, on the other hand, can be useful.  It tells me how much code I have to validate that is not covered by automated tests - it tells me a risk level.  By itself, it is not enough (look up Mars ClimateExplorer as a terrific case study).  It does help make a decision, though. 

Here's my analogy:  code coverage is to a test engineer as a patient's temperature is to a doctor.  It is one useful metric that can help isolate risk.  By itself, a 98.6F temperature does not tell a doctor that a patient is healthy.  It only can help eliminate some possible causes of illness - certain stages of the flu, for instance.  No doctor could reasonably base a diagnosis on one temperature measurement.  It is one statistic among many others such as blood pressure, heart rate, etc.. that can help lead to a more accurate diagnosis.

Likewise, just because I have a 98.6% rate of code coverage, I cannot pronounce a feature risk free and ready to ship.  I also have to look at scenario pass rates, international/localization status, accessibility, performance goals and so on. 

Too often we get trapped in a mindset of "this statistics by itself is useless so let's not bother tracking it."  While the first half of that sentence may be true (and is, for code coverage), the second half of that sentence does not follow.  If given a choice of having a patient's temperature included in a checkup or not having the temperature included, doctors will always want to track that statistic.  It helps give part of a bigger picture.

And that is exactly what code coverage does.

Questions, comments, concerns and criticisms always welcome,

John