Five for Friday – June 15, 2018

A few points of interest from my week.

  • My quote to ponder is from Jerry Weinberg – “Unless and until all members of a team have a common understanding of the problem, attempts to solve the problem are just so much wasted energy.”
    Take a moment to reflect how often you’ve seen this yourself firsthand.
  • I’ll also share five-quotes-in-one from this Forbes article on 5 Quotes That Teach You Everything You Need To Know About Leadership Storytelling.
  • For a variety of reasons, I’ve been revisiting the posts from Roy Osherove on 5Whys.com – most of the posts are years old, but most are also still relevant and worth reading.
  • Apparently, it’s webinar season.
  • I had a chance to talk with the CTO of Wevo this week – I think the concept of the company is fantastic (using ML to predict better design), and I think they’re a company to watch.

Five for Friday – June 8, 2018

I’m back from a quick trip to New York City where I managed to give two workshops and a keynote without boring anyone to death. Here are five of the things I found interesting between talking, working, and learning.

  • A lot of news recently about depression and its long impact has put this quote from Henry Rollins in my head. “I’ll never forget how the depression and loneliness felt good and bad at the same time. Still does.”
  • To me, good retrospectives and learning are critical to software (and team) success. I found Retromat this week – a site that gives you random activities to help you get more from your retrospectives.
  • The Engineering Manager has an alternate view on The Manager Readme. I admit that I like the directness and brevity of the readme he eventually came up with, but also feel that the author missed a large part of the point.
  • This list of Falsehood Programmers Believe About Hiring is painfully true, and something to ponder for any of us in charge of hiring.
  • For the first time in quite a while, I’m reading fiction – science fiction to be exact. I’m reading Leviathan Wakes – the first book in the Expanse series. I watched the first season of the TV series, and liked it a lot – but I’m enjoying the book even more.

Five For Friday – June 1, 2018

Some interesting bits from the week

  • I took a pause on reading Why We Sleep (great content, not my favorite writing), but will continue to plow through it between more readable books.
    I’ve moved on to something I bought a while back, but finally just started – Accelerate, by Forsgren, Humble, and Kim. I’m fifty pages in, and enjoying it a lot. It ties into the Modern Testing Principle #2 pretty well so far.
  • A bit related to sleep – but a whole lot more, is this article on Killing the Eight Hour Workday.
  • Amber Race did a wonderful thing and combined The Big List of Naughty Strings with Postman tests (and wrote about it)
  • I met Constance Armitage in Brighton earlier this year, where she taught me a bit about drawing. She drew a wonderful comic describing her experience at Testbash
  • Finally, in case you missed it, you should know about the I’m a Teapot error on npm last week.

My Latest Experiment

I thought it would be worth writing this up and sharing.

Last week was, for me, at least, time for another Windows update. With this one, my mouse stopped working – or to be clear, it started becoming unusable. The x coordinate speed was 1/3 of what it should be. With three monitors, it was pretty painful. I was also frustrated that the update reset some of my settings, pinned items to my taskbar without asking me, re-enabled disabled services, and basically did too much stuff that I thought it shouldn’t do.

So I gave up.

Most of my work is / can be done in a web browser. There are a few exceptions (more on these later), but I was willing to try something new. So, I installed Ubuntu 18.04, and for the past week, have been using it as my main home machine (also note I’ve been working from home 4-6 hours a day since then).

So far, it’s been nearly perfect. Of course, all of the browser apps I use daily (jira, gmail, google suite, etc.) work perfectly. I was also quite happy to see that just about all of the native apps I use have versions that run on Ubuntu (like Audacity, Slack, Spotify, and Zoom). With a bit of finagling, I was even able to get Open VPN working so I can access Unity resources. Overall, the app experience has been perfect for me.

Hardware support is also good (or great, with one exception noted below). I believe the Ubuntu installation queries my windows installation for some hardware, as it detected the wacom tablet I have that is not currently plugged in – but everything that I do use (bluetooth headphones, audio, logitech camera) work perfectly.

The ONE annoyance remaining is that once a day or so, I’ll lose a monitor. I have a Geforce 1060 driving three 24″ monitors. The card is (obviously) capable of driving all three, but once a day, one will drop, and no longer be detected by the OS. I’ve tried forcing it via tools (xrandr), but nothing short of a reboot brings it back. This behavior happened with both the nouveau drivers, and the latest generic drivers from nvidia. I’ll see over time how much this happens and how much this bothers me.

I built this machine for games, but I’ve drifted back to doing most of my gaming on Xbox, so I think it will continue to work out, but will be interesting to see if Ubuntu works out as a daily machine for the long term.

 

Five for Friday – May 25, 2018

Wow – where did that week go? Here are few things I found worth pondering this week.

  • There will be a full blog post with details, but I had one too many pieces of hardware fail after an ill-timed Windows update, and a few too many settings changes after the same, and I flipped out a bit.
    The good news is that I was able to get everything I needed to run in order to do my job running on Ubuntu in only a few hours.
  • I’m giving a presentation to a small group of peers next week on data analysis, and I’m reminded of this quote by Josh Wills at Slack.
    “Data Scientist (n.): Person who is better at statistics than any software engineer and better at software engineering than any statistician.”
  • Yet another great post from Michael Lopp on professional growth – Your Professional Growth Questionnaire
  • I’ve mentioned Radical Candor here before, but this is a great post on giving feedback – A Manager’s Guide for Effectively Giving Feedback
  • It’s GDPR day. I won’t hyperlink GDPR, but I will give you a link to The GDPR Hall of Shame

Five for Friday – May 18, 2018

Five things on my mind – or interesting this week:

  • I recently re-read a chunk of The Lean Startup, and highlighted yet-another-quote-about-failure-and-learning.
    When blame inevitably arises, the most senior people in the room should repeat this mantra: if a mistake happens, shame on us for making it so easy to make that mistake.” — Eric Ries
  • …which leads well into this article (it’s from last month, but I just found it this week), on what it really means to Go Fast and Break Things.
  •  I tweeted to my web provider last week about getting free SSL (they currently charge a minimum of $8 a month for SSL on angryeasel.com). The bot(?)-driven replies and emails leads me to believe that web hosting is a highly competitive market. Overall, it looks like I can save a few bucks a month AND get ssl up and running. So far, leading contenders are Interserver and Chemicloud. I am, of course, open to other options (needs are hosting of two wordpress sites, domain email, and at least 10GB of storage.
  • It’s almost World Cup time, and it was interesting to see that a simulation done by UBS predicted that Germany would win (they’re probably right), but more interestingly, they gave Italy a 1.6% chance of winning. For my non-football/soccer readers this is interesting because Italy did not quality for the World Cup.
  • And finally, it’s yet-another well written article on the Netflix Tech blog – Full Cycle Developers at Netflix?—?Operate What You Build

The users guide to working for me

A while back, inspired by Roy Rappaport’s manager readme, I created my own. Unfortunately too late for most of my Unity hires, but a fun reflection exercise anyway. I originally had this on our internal wiki, but I recently moved it to my github site as a more permanent location.

A few of you already saw this go public last week in the hackernoon article, but for total transparency, you’re welcome to view my “manager readme” on my github site here.

Five for Friday – May 11, 2018

It’s time for the weekly visit inside things going through my head (and browser) this week. A bit of self-promotion in the last two bullets, but I hope you find these interesting anyway.

  • I’ve been thinking a lot lately (on many fronts) about change – and resistance to change, and I’m reminded of this quote by Arnold Bennett:
    Any change, even a change for the better, is always accompanied by drawbacks and discomforts. “
  • I liked this article by Jurgen Appelo on The Sense and Nonsense Of Empowerment. For those of you who are managers, I’m curious to hear what you think.
  • There are really only two (four if you count Windows on my home PC, and my Xbox One) Microsoft products I use much anymore. One is Excel – but only when I need to do analysis or create visuals that Google Slides can’t handle.
    But Visual Studio Code has become my favorite code editor – and it keeps getting better. They release monthly, and every release has multiple valuable features and fixes. To be fair, I don’t write much code these days, but when I do, I’ve been turning to Code every time.
  • I was honored and happy to be included in Abstracta’s list of the 75 Best Software Testing Blogs. I was impressed that they actually poked around and found out what Angry Weasel means to me, and the list includes a lot of great resources.
  • In the I think this is really cool category, Ministry of Testing made a poster (and an accompanying article) of the Modern Testing Principles. Print it and post it (and forward me the feedback :}).

The Test Automation Snowman

I was nothing short of blown away over the past few days, when some comments I made on twitter about UI automation caused a lot of folks to raise their eyebrows.

Here’s the tweet in question.

Feedback (blowback?) ranged from accusations of harmful blanket statements to lectures on how what I really meant was “checking”, not testing – with a handful of folks who seemed worried that the world I was describing was too scary compared to the world where they lived. Testing evolves at different speeds in different places, so the last point, at least, was expected. But I stand by the sentiment in that tweet.

The test automation pyramid is a model for thinking about distribution of your tests. Mike Cohn first (I think) wrote about it here. In my opinion (and observation), there is an unhealthy obsession in software testing with writing “automation” (where “automation” means UI automation – i.e. using tools like Selenium to manipulate the UI to test the system under test). A few folks recently have complained about the pyramid (“it’s not a pyramid, it’s a triangle!”; “There are more than 3 types of testing”, etc.).

“All Models are wrong, some are useful” — George Box

It’s a good model, with a lot of practical application. Two key takeaways from the pyramid model are:

  • Write tests at the lowest level where they can find the bug
  • Minimize the amount of top/UI level tests

I’m passionate about the second point for three main reasons:

  1. UI Tests are flaky. This was true 25 years ago when I first wrote UI automation, and it’s true today. They’re just not as reliable and trustworthy as lower level tests.
  2. Despite the fact that reliable UI Tests are difficult to write, we (industry) seem to think that UI automation is a reasonable entry point to the world of coding for “manual” testers. UI automation is a horrible way to start programming. Shell (or other) scripts to help set up test environments or generate test data would be a much better use of time (and achieve more success) than learning to code by writing UI tests.
  3. UI tests are s l o w. This is fine if you have a handful of tests, but a huge issue if you have hundreds, or thousands of UI tests.
    Note – if you have a large amount of testing that can only be done at the UI level, that’s a big red testability issue you should probably address before investing in expensive testing.

Let’s assume for a moment that the problems with UI automation stability have been solved (companies like testim.io have used ML to make some strides in this area, and despite the entry path problem I mentioned above, there is improvement in automation tools and tester skills). If we go with this assumption, then point #1 – and possibly point #2 above are no longer an issue.

Point #3, however, is not solvable. Tests that automate the UI are slow. Way slow. Like a glacier stuck in molasses slow. I once wrote a UI based networking test to create a folder, share it, connect to it, write files to it, delete files, and then unshare the folder. That test took a little less than two minutes. Problem was, that I needed to test that process for every character possible in isolation (due to issues with DBCS code pages on non-Unicode Windows where details would fill pages of no longer relevant information). On Chinese windows, for example, this was (IIRC), somewhere near 8000 characters.

I wrote an API level test that tested the entire code page – including varying lengths of folder and share names that ran in under 5 minutes (and less than a minute for Western code pages). Of course, we still did spot checking (both exploratory, and via some UI automation), but testing at the level closest to where we could find bugs was the most efficient – both in proximity and speed.

Another view of tests I like is the size model from google. Rather than dwell too much on what makes a test a unit or integration test, think of tests in sizes – where tests of a certain duration are classified at different levels. This model works well (and solves the pyramid complaints I’ve seen recently), but it doesn’t have a visualization.

So – without further babbling, I created this alternate view – The Test Automation Snowman.

Use it, or ignore it. But I still beg you to consider writing far fewer UI based tests.

Five for Friday – May 4, 2018

It’s Star Wars Day! Here’s what I found interesting this week.

  • Quote I’m pondering (or quote within a quote, as it’s the authors of The Coaching Habit who are quoting Bernard Shaw):
    “Bernard Shaw put it succinctly when he said, “The single biggest problem with communication is the illusion that it has taken place.”
  • Book I’m reading now: Why We Sleep: Unlocking the Power of Sleep and Dreams
  • I’m big on learning from failure – but I found this article on Blind Spots in Learning and Inference has a lot of interesting points on blind spots often made when looking at failures (focusing on two widely famous failures).
  • Are you kidding me? More CPU Flaws?
  • I taught a workshop earlier this week on web testing tools. We spent a chunk of time on Postman, but I wanted to give credit to Danny Dainton, as I borrowed from (and referenced) his github repository on All Things Postman. Thanks Danny.