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.

Five for Friday – August 17, 2018

I made a quick trip to Iceland this week, where I still had time to come across a few interesting things to share.

Experimenting with Mobile Automation

As I type this, I realize I have a mildly embarrassing gap in my testing career. I don’t recall ever writing any automation for mobile applications.

Maybe that’s not exactly true – nearly 20 years ago, I wrote some automation in C++ to test Windows CE, and some applications that ran on it…and technically that was an OS used to power Windows Phone for a while (among other devices) – so I guess the gap is that I have never played with Appium. We used Appium when I worked on MS Teams for (some?) mobile automation, but I wasn’t directly involved.

Today is my chance.

TestProject Experiment Number Two

After my success playing with recorded test automation (I really want to call this recorded test assistance) for web, I decided to try the same thing using TestProject to test a mobile application.

Getting Started – The Setup

I was mentally prepared to install the Android SDK (or at least ADB), and spend a bunch of time getting a connection set up, but holy crap – was it always this easy?

I already have the TestProject agent running on my computer (for running the web tests), so all I had to do was select Android as my target, and everything else just worked.

Overall, the setup wizard is extremely easy to follow, and worked amazingly well. My phone was already in developer mode, so all I had to do was configure USB debugging, (optionally) disable a few animation features (for testability), and the TestProject web app connected to my phone and showed a mirror on screen in seconds. I thought for sure that I’d spend an hour or more getting this going, but I was wrong.

Granted – I don’t have much experience here other than half a dozen sessions debugging over ADB, so this sort of thing may be the norm now, so all I can say is setting up a remote development session can’t get much better than this.

The wizard is pretty much the same as the web wizard with one cool addition. Once the connection is configured, I can browse the device packages to choose which one I want to test:

I decided it would be fun to play with some automation for the Twitter app. There’s an option to reset the app before starting, and there’s even a default step added to reset, but for my experiment, I deleted that step.

As in my tests on, I’m just going to record selecting the top 4 elements from right to left and see what happens.

Note that the steps here are able to pull more friendly names from the package, so the test steps are pretty readable as is.

Creating Tests

Using the same test strategy as I did with web tests, I then added validation to ensure that the correct screen showed in the right place.

For each screen, I just used the “Validations” design element to confirm the existence of a particular control. There are probably better ways to do this, but for my quick test, it’s fine.

Similar to what I wrote for web tests, I have some actions with validation.

The Element Locator

If you’ve written automation in Appium or Selenium (or other frameworks that rely on IDs, XPaths, etc.) you are already familiar with the game we play to find elements.

One of the other handy features of TestProject is a simple, but useful element locator that makes it easy to discover if the element you’re working with is currently visible. In the example below, I’ve clicked the Find button in the test designer to show me the Twitter Home button.

Pretty cool!

As a nice aside, notice that the screenshot above (unlike the other screenshots), my phone screen fills the emulator (vs. the other screenshots where it fills 70% or so of the emulator screen). The TestProject team fixed the issue practically moments after I reported it.

A Few Words About Automation

Let me be the first to point out that this isn’t particularly great automation, and that the validation I’m doing probably isn’t what needs to be tested at the UI level for Twitter.

When you write UI automation, use it to find bugs that can only be found at the UI level. If it’s a special visual effect that can only be detected via human eyes, then use human eyes to validate the effects.

Of equal importance is your strategy. Don’t start by deciding what to automate. Instead, start with what you want to test – and then use automation to assist your testing. I’ll refer again to my article on the TestProject site that expands on these ideas in more depth.

All that said, it seems to me that I could very well use TestProject for proper targeted UI tests where they were needed, and that it would serve me well.


I’m still surprised by how easy it was to get up and running testing a mobile app, and the test steps were pretty straightforward and intuitive.

One of the areas where mobile automation really helps is in making sure applications work across a variety of devices. I only have one phone, but TestProject does support working with multiple connected devices to a single desktop. You just connect a USB Hub with a suite of devices, and you have an instant test lab. It’s also worth mentioning that an account can have multiple agents assigned to it. This enables executing tests not only on your desktop (and devices connected to it), but also on remote agents (and devices connected to them) in different locations anywhere in the world. It could be fun to see if TestProject could target a big virtual and real mobile test farm like BitBar, but there’s plenty of flexibility and potential right out of the box.

As with the web tests, I’d love to see a way to view / edit the underlying code, but my curiosity was less with mobile apps – perhaps because my knowledge of Appium is much less than my knowledge of Selenium.

Overall, it seems like a pretty usable and robust choice for most mobile automation tasks.

One more investigation to go where I’ll see how TestProject does with some coded tests.

Five for Friday – August 10, 2018

  • Jerry Weinberg passed away earlier this week, and I’ve taken some time to re-read parts of many of his books, where I’ve been constantly reminded of his leadership knowledge. I grabbed this quote from Becoming a Technical Leader to share
    People don’t become leaders because they never fail. They become leaders because of the way they respond to failure.
  • I spent a chunk of my early career in globalization testing (which reminds me that my last wikipedia edit was to fix this section of the software testing article). Netflix, in yet another valuable post, describe their approach to pseudo-localization.
  • We all knew this was coming. Here’s what you need to know about California’s new data privacy laws.
  • Modern Testing Principles overlap a reasonable amount with the Three Ways of Devops – which is probably why I found this article on the Three Ways of DevSecOps interesting.
  • And finally, speaking of security, here’s something to remind you how much we all suck at software security. How I gained commit access to Homebrew in 30 minutes.