Five for Friday – October 5, 2018

Here are a few (five, actually) things I saw this week and liked.

Five for Friday – Friday, September 28

Here are a few of the things I found interesting this week.

  • I thought this article about “hacking” British Airways was sort of interesting – but mainly that they glossed over the real hack – “It is likely that the hackers had access to the site, and modified the code to insert a backdoor.” 
    Read and make your own judgement.
  • Camille Fournier (author of the wonderful book, The Managers Path posted this article on engineering productivity.
  • Ben Kelly says, You probably need fewer testers than you think (and he’s probably right)
  • Saw this on twitter from Cassie Kozyrkov on Speaking at conferences. It’s really good (especially compared to the usual posts on this topic)
  • Finally, I tweeted about this, but it’s worth calling out here too.

Five for Friday – September 21, 2018

I had this weird empty feeling all afternoon, and it just hit me. I (almost) forgot to post my five interesting finds from the week.

Five for Friday – September 14, 2018

Here’s stuff I found interesting. Some of it published recently – some is not. 

  • I posted earlier this week about painful observations of “stand-ups” turning into horrible status sentences. Seth Eliot pointed me to this great post by Henrik Kniberg that covers my peeve better than I did.
  • I’ve been reading Option B by Sheryl Sandberg and Adam Grant. I’ll avoid personal feelings and just say that it’s well-written, and I’m enjoying it.
  • I loved The Children’s Guide to Kubernetes. Heck – even I can understand it.
  • I frequently (consistently?) state that a retrospective is the single most important meeting your team can have. While this article (4 Reasons Why Your Scrum Sprint Review Isn’t Effective) focuses on the scrum sprint review ritual, the concepts apply to any retro.
  • Continuous Testing for Devops Professionals is out. I’ve read 90% of it (I was fortunate enough to be a reviewer), and think it’s pretty good.

Status and Progress

Status meetings are boring. More importantly, status meetings are unneeded. Meetings are for discussion, and updates on status rarely require that (until, of course, they do). Nothing – nothing is more painful than sitting through a meeting where people go around the table and say, “Today, I’m doing X”. 

Hopefully nothing alarming so far.

A lot of teams have adopted Scrum for project management. One of the rituals of Scrum is the daily stand-up where traditionally, 3 questions are asked:
1) What did you do yesterday?
2) What are you doing today?
3) What is blocking you?

And a lot of times during the stand-up meeting, most people say something like, “Yesterday, I worked on the fizz filter. Today, I’m working on the fizz filter. Nothing is blocking me.”

And then the next day at stand-up, they say, “Yesterday, I worked on the fizz filter. Today, I’m working on the fizz filter. Nothing is blocking me.”

Eventually, since the answers to questions 1 and 3 never change, standup information is “optimized” to something like this:

Today, I’m working on the fizz filter.”

…and this repeats until they’re (eventually) done with the fizz filter.

Something is wrong, right?

Somewhere in the rituals of scrum or agile, teams who operate like this lost the importance of communication and collaboration – they go through the motions of “agile”, but fail to get the immense value that’s easily within their grasp.

If you’re tied to the canonical three questions of scrum, then at the very least you owe it to your team to improve the way in which you communicate your status. Discuss details; include something you learned (maybe you were blocked, but figured it out); think about how other team members may be able to help you. You can also make a big dent in the scrum-as-status-reporting problem if you break your work items into things that can generally be done in a day or less.

Yesterday, I worked on the database connection for the fizz filter. I had a challenge getting the ODBC connection set up, but Janet gave me some tips and I got the problem solved. Today, I’m going to write a test suite for the fizz filter database connection. I may need some help learning the new test runner, but other than that, I should be good to go”

If you want to go further, Brent Jensen taught me a question that I now use to drive any project management meeting I’m in. This came up while discussion managing a team using kanban (which I believe, when used correctly, far exceeds scrum as a project management framework), have task owners answer one question:

What needs to be done to move this task to the next column?

The question is automatically contextualized by the kanban column containing the task. Answering the question reveals questions, dependencies…and even status. 

The question from Brent is wonderful, but the the main point here is that your status messages (barf) or status meetings (double-barf) aren’t helpful for you, your team, your software – and ultimately, your customers. The great news is that it’s easy to do better.

What needs to be done to move this task to the next column for your team?

Five for Friday – September 7, 2018

Friday snuck up on me, but the interesting links and thoughts kept coming. I hope you find something of interest here.

  • I’ve been re-reading (re-re-reading?) Radical Candor, and this line poked me enough to write down. If  you’re a people manager – or even if you just value relationships, it’s something to keep in mind.
    “Make sure that you are seeing each person on your team with fresh eyes every day. People evolve, and so your relationships must evolve with them. Care personally; don’t put people in boxes and leave them there.” 
  • There are some hints of Modern Testing in this article by JP Lambert on why there are so few agile testers.
  • I liked (mostly) this article from Jason Wong on followership.
  • I’ve been talking about technical debt with a lot folks on my teams at Unity, and then Trish Khoo posts this great article on a Technical Debt Playment Plan.
  • I just finished binge-watching Halt and Catch Fire. It’s a nice dramatization of the rise of the PC, online communities, and the internet, but the story and acting are really, really good. Chuck it in your queue on Netflix and give it a shot.

Five for Friday – August 31, 2018

  • I’ve referred to Pat Lencioni a lot here – but this quote from The Advantage has been high on my radar this week:
    “The single greatest advantage any company can achieve is organizational health. Yet it is ignored by most leaders even though it is simple, free, and available to anyone who wants it.”
  • I enjoyed this article – A practical guide to becoming a terrible manager.
  • …and also this article (or collection of ideas) on how to define high quality code.
  • This is a really good article on strategy – including this painfully accurate opening line – “The root of most strategy challenges is simple–too many managers don’t know what strategy is”.
  • Finally – one of my heroes retired from professional soccer this week. Thanks for everything, Clint.

Portland, October 2018

I mentioned this on twitter, but it’s worth calling out here directly as well. I will be talking about modern testing (and giving a workshop on web testing tools) at the Pacific Northwest Software Quality Conference in early October, 2018 (full details on the PNSQC site).

This isn’t my first time to PNSQC – I was there in 2009 and 2010 where I made presentations to support these papers:

While I despise the Timbers, I do love Portland, and it’s a really wonderful city to visit, and I welcome the excuse to spend a few days there.

Also worth mentioning is that I’m attempting to take a break from conferences in 2019, so PNSQC will be the last conference (in-person, at least) I attend for the foreseeable future. So – if you’re looking for a good test and quality conference in a fun city – or you want to hang out with me (or even both), I hope to see you in Portland.

Five for Friday – August 24, 2018

Yet another view into what I found and liked this week.

  • I’ve been a fan of singer-songwriter John Wesley Harding (nee Wesley Stace) for a few decades (he played at my 40th birthday party!). He did a remake of his own song (Scared of Guns) for an Appleseed compilation – which you can hear here.
  • If you’re wondering why the thing you think is Agile software development isn’t working, this article may help you figure out what’s going on.
  • I re-tweeted this yesterday, but as someone who has done something in a lot of these languages, I can’t stop giggling when I read it.
  • As a recently converted – but happy Linux (Ubuntu) user, this news from Steam on games for Linux is really interesting.
  • I don’t often promote test conferences, but I know the folks behind the European Testing Conference, and it’s definitely one worth checking out.

Coding with TestProject

This is my third post on TestProject. The previous posts are Getting Started with Test Project and Experimenting with Mobile Automation.

The last thing I wanted to explore a bit with TestProject is directly writing some code for some (potentially) more advanced testing. Currently, the TestProject SDK supports Java, but SDKs for JavaScript, Python, C#, and Groovy are under construction. Fortunately, Java is a language I’m at least partially competent in, so I feel comfortable giving it a shot.

The Application Under Test

To keep things simple, I just used the TestProject Example page at

To start, I cloned the latest samples from GitHub, and grabbed the TestProject Developer SDK. Note that there’s a link on the bottom of the SDK page link above that allows you to copy your developer key. You’ll need that to get started as well.

The next steps are documented well in the for the web project (TestProject Java SDK – Quick Start for Web). Short version is that to get the samples to run, you need to make sure the build.gradle file knows where the SDK jar file lives, and add your developer key to the test runner java file.

I could write a series of blog posts with details on gradle and java build command lines, but I probably wouldn’t answer questions here as fast as a google search. Once you can build the test and test runner you can upload the test to TestProject using the New Test Wizard to upload your .jar file.

For this blog post, I’ll be playing with the BasicTest sample. I cloned the sample repo, and built it as is.

My Test Package now shows up on the Web page (note that I temporarily changed the test name to match the full namespace name of the test – and that the package includes the Extended Test from the sample project as well. From here, I can add tests and run them the same as we did with the Recorded / Designed tests discussed in the previous posts.

Coded Automation

The coding constructs in TestProject should feel pretty familiar to anyone who’s written Selenium or a derived language before. You instantiate a web driver, tell it to do things with elements, and write some verification code.

The entire basic test is this:


I think it’s pretty straightforward to read – even if you’re not a “coder”.

These two lines:

…start WebDriver and navigate to our page-under test.

The next two lines initialize the Page Objects on the profile page and fill out the fields there. (please – if you write web automation, use Page Objects. TestProject gets serious points from me for including Page Objects in their sample) – and then login to the page.

And finally, there’s some verification to ensure the page is saved.

This is a sample, but it’s worth mentioning that the oracle for this test isn’t great.

As testers, we’ve all seen pages that display the proper text, but don’t do _everything_ we expect. On one hand, I’d lean toward a more robust verification – OTOH, writing a massively complex verification function is part of why I get scared of a lot of UI automation.

Play Time

Cool so far, but let’s muck with this a bit and think about how we can use the power of the computer to do a bit more testing.

In a much longer blog post, I would create an array of structures containing names, addresses, etc. and loop through them ensuring that all could be entered correctly. I’d pick canonical examples from different locales to ensure (or help with) globalization, and probably add a handful of contrived examples as well (sql injection, cross site scripting, etc.). Note that I did try logging in with a user name of <script>alert(‘ruh-roh’);</script> with no problems.


First thing to do is wrap the whole function in a loop. Other than adding a loop construct, I’ll track a count of failures (so I can just return pass / fail once).


I wrote a tiny helper function to create a random string from characters in the ISO Latin Alphabet. I could just as easily used UTF-16.

I’ll use this to create a random first name and last name of (arbitrary) lengths 10 and 20.

At this stage, I have a test that loops, trying different names…but there’s one thing interesting on the following page I want to investigate.

The web page grabs the name I entered on the previous screen and displays it. I want to write a test to verify that the name is correct.

Probably the easiest thing to do at this step is right click on the text, choose Inspect (assuming Chrome), and then either grab the id and find the text element by id, or choose Copy and Copy XPath (I find XPath to often be ugly, but in this case it’s very clean).

Based on that bit of investigation, I added the following bit of code to

It grabs the full text of the greeting element, and returns true if the string contains the name. Pretty darn straightforward.

My slightly more interesting basic test now looks like this.

Of course, there are thousands of other test and verification options open at this stage, but to me, the TestProject stuff has been extremely easy to use and highly intuitive.

But Wait… Addons

I’m not going to be able to do the idea of Addons justice, but to me, this is a big differentiator with TestProject.

Addons are sharable components that perform a specific task. My dumb name generator could be spruced up to actually draw from a database of real names and be uploaded as a shareable component that anyone can use. I expect, in fact, that as TestProject grows, that the number of Addons – and their value will increase immensely.

Also note that the jRand addon from the TestProject Community addons is a nice shortcut for a lot of this particular test scenario. It generates a random (and usable) value for just about any sort of entry field you could think of, including sentences, paragraphs, birthdays, addresses, altitude, credit card details and more.

There’s definitely a lot of potential for good code reuse with the addons concept.

And Finally…

I covered a lot, but not nearly as much as I should have. If you play with the coded tests in TestProject, I suggest going through the docs on github, and not my walkthrough above, because I probably forgot just enough steps (some on purpose) to throw you into a pit of despair.

But I do suggest giving this framework a shot. As always, remember that my suggestion is to automate at the Web UI level only to verify things that can only be found at the UI level. Used correctly, I think this automation framework and supported web tools can give a lot of value to a lot of software teams.