Categories
Agile Software Dev

Rapid feature delivery using “Fast Follows”

I’ve mentioned previously that I like using “Now”, “Next”, “Later”, “Never” as a way to prioritise the system features we’re delivering.

But we often get in a situation where we want to deliver a “now feature” quickly, but we find something that we need to do on it that we don’t want to want to group with the “next” features. To steal a term startups use and reinterpret it: we call these “Fast Follows”.

“Fast Follow” is a startup strategy that aims to build a company by copying an already proven business model- and executing quickly to “follow” the moves of the predecesor.

https://worldaccordingtocarp.wordpress.com/2010/01/21/the-fast-follow/

Fast follows allow us to quickly ship “now” features into the hands of our customers knowing we have a mechanism to follow quickly with an enhancement or bug fix.

Do you do “fast follows”? What do you call them?

Categories
Remote Work

Back in the office

I’ve been back in the office for a few weeks now. Only about 10% of our company can work in the office and even then only about that percentage are keen to return (at present).

I find myself enjoying work again and regaining the ability to mentally separate work from home has been energizing me for when I am at work. Also having people around motivates and recharges me at work.

I read an interesting article written by Justin Qin, a year 8 high school student, who reflects on returning to school after many weeks of home-based learning:

“Lockdown and home schooling had been a lonely environment for me — even with two energetic brothers for company, and Instagram on repeat.

And after days at a time like this my friends and I chatted constantly when we saw each other, flushing out the loneliness of isolation and reviving the joy of face-to-face chat even though we had to maintain that all-important distance.

Being in the classroom, and the ease of talking to my teacher and other students, makes school a place where I can actually learn and be engaged.

My school day was spent stuck at a desk at home, with tiny breaks and no time to chat to friends as we transitioned between lessons. I often felt as if I had not stood up for hours at a time.

The result was that learning from home was seriously affecting my physical and mental health.

Mentally, I wrestled with finding the meaning of my life when so much of it was spent alone at a desk.

Physically, I ate significantly less food than normal.

With these struggles I cannot see a strong future for online classes replacing school.”

Justin Qin on returning to Year 8 at School #

When I look at my LinkedIn feed it’s full of articles, comments and observations that many people can’t see themselves returning to the office in the near, or far, future.

I put this down to one of two possible things:

  1. People are still in the “honeymoon” period of full time working from home; and/or
  2. People are confusing working from home with having flexible working conditions

“The first six months were a dreamlike period, where everything you’d ever hated about office life – underlings, overlords, sharing bathrooms with people who you’re thankful aren’t your family – morphed into amusing memories.”

“It’s all fun and games at first, a novelty, the home work thing, and being close to your own fridge is great, but the slow evaporation of the mental distance between your home life and your work one is an insidious one.”

Stephen Corby : You might love working from home now, but give it a year

As I’ve stated previously, I personally don’t find myself healthy, happy or productive working from where I live. I prefer to separate work and home, and to have people I’m working with around in real life.

But I’ve also said we need more flexibility in the way we work, working from home doesn’t have to be the only way we can have flexible working conditions.

I’ve also seen a somewhat disturbing trend to encourage everyone to act like they’re working remotely even if they’re in the office:

“If everyone sits at their desk on an individual video call screen, the playing field is equal. Everyone’s faces are easily distinguishable, it’s easy to know whose turn it is to talk, and it simply puts everyone’s input on equal footing.”

6 Rules To Live By When You Work In An Office But Have Remote Team Members

I’ve tried doing that and the audio feedback from having someone sitting near you talking on the call and also near you is terrible, it’s loud and distracting for other’s in an open plan office, and it feels weird to pretend we’re not in the office when we are.

Conclusion

I still think it’s too early to declare that ever working from an office again is not going to happen. As I have previously stated – it’s been good to show employers that employees can still be productive when given workplace flexibility – however I think there will be recognition that working 100% in physical isolation from colleagues isn’t necessarily a good thing.

“A world in which people who want to can do a bit of both, working home alone some of the week and sharing an office with other humans the rest of the time, might just be the perfect balance, for those lucky enough to swing it”

Stephen Corby : You might love working from home now, but give it a year

Categories
Specification by Example

Given/When/Then with Style?

Gojko Adzic has started a series of challenges on the Specflow blog where readers can submit solutions to common problems writing automated tests using gherkin (Given/When/Then).

The first challenge is:

“What’s the best way to describe a Given for a value that’s not supposed to be there? For example, starting the specification from a point of a user who does not yet exist in a database, or a product that’s not been set up. “Given a user that doesn’t exist” sounds vague, but “Given user John that does not exist” sounds silly – how can we talk about John if he doesn’t exist yet?”


Gojko Adzic
Given user John does not exist
When John tries to register
Then the registration is successful

Given user John exists
When John tries to register
Then the registration fails

How would you improve the scenario of our example to solve the challenge of this week?

Gojko Adzic

Interestingly this problem highlights the issues I found using Gherkin to specify business rules and examples I previously wrote about:

“I’m not keen on writing specifications in gherkin (Given/When/Then) as I think it’s too generic and frequently makes the feature specifications too verbose – and takes emphasis away from the critical parts.”

Example of lightweight feature documentation

I prefer bullet points and tables.

I’d specify the above scenarios as follows.


User Registration

Rules

  1. A user can only register a single account per unique email address
  2. A user’s email address is their username
  3. A user can register using their Google or Facebook account without having to enter a username or password
  4. A user must enter a password unless they are registering using Google or Facebook
  5. Passwords must contain at least 4 letters and 4 digits
  6. Passwords are maximum length of 10 and can contain any ASCII characters

Registration Scenarios/Examples

ScenarioExample Email AddressResult
New user signs up with a new email new.customer@hotmail.com✅ Registration Successful
New user signs up with a new email and invalid password new.customer@hotmail.com❌ Registration Unsuccessful – Validation Error Displayed and no account created
User attempts to sign up with email already registered email for account with password existing.customer@hotmail.com❌ Registration Unsuccessful – Reset password page displayed with email prefilled
User attempts to sign up with email already registered email for account with Google log-inexisting.customer@gmail.com❌ Registration Unsuccessful – Log in with Google page displayed

It’s tempting to put passwords into the above table, which is what I originally did, but I’ve found it’s better to specify those separately (in the same document).


Passwords Scenarios/Examples

Password ScenarioExample PasswordValid/Invalid
Less than 8 characters123
Less than 4 digitsaaaabbbb
Less than 4 letters123456aa
No emoji – ASCII Chars Only1234abcd💀
More than 10 characters123456abcdef
10 Characters with ASCII1234abcd%$
4 digits and 4 lettersabcd1234
Special characters don’t count as lettersabc$1234

Summary

Whilst these scenarios aren’t gherkin I don’t think they need to be. They could be taken by developers and written as unit tests alongside the code. I wouldn’t have an e2e automated test that tests this logic at this level – it’s complex and an expensive waste of time.

I’ll be interested to see the follow up posts about the best way to specify these in gherkin, as I can’t see a clearer way than just using bullet points and tables 🙌

Categories
Automated Testing Test Automation

Karate: Test Automation Made Simple?

I’ve heard this test automation tool mentioned a few times lately: Karate: Test Automation Made Simple. The idea behind the tool is all one needs to write is gherkin feature files – no step or glue code is required.

I thought I’d give it try to see how it works. My example repository is on GitHub.

Background

Karate allows you to define automated tests in gherkin (Given, When, Then) which are executed directly as either Web Browser or API tests.

Examples

A web test looks like:

Feature: Web Browser Automation using Karate

Background:
   * configure driver = { type: 'chrome' }

Scenario: Demonstrate webdriver usage
  Given driver 'https://webdriverjsdemo.github.io'
  When waitFor('#elementappearschild')
  Then assert exists('#elementappearschild').exists
  Given driver 'https://webdriverjsdemo.github.io/leave'
  When click('#homelink')
  And dialog(true)
  And waitFor('#elementappearsparent')
  Then assert exists('#elementappearsparent').exists

and an API test looks like:

Feature: API test example using Karate
  Background:
    * url 'https://webdriverjsdemo.github.io/'

  Scenario: get all users should return array of one user
    Given path 'users.json'
    When method get
    Then status 200
    And match response == '#[1]'

  Scenario: get a user should include name and age
    Given path 'user.json'
    When method get
    Then status 200
    And match response.name == '#string'
    And match response.age == '#number'

These tests are fully self-contained, there’s no need to write step definitions or any other code.

Test Execution

There’s a few ways to execute tests. There’s a command line standalone executable you can run passing in details of your tests which are parsed and run. This is a straightforward way to quickly get started, although it seems things like configuring different URLs/environments is more complicated. You can also set it up as a full Java project with IDE and debugging support.

Nice 😇

  • Provided standalone executable makes writing and running your first test super quick – including a VSCode plugin to run/debug
  • In built parallel test execution support (although I couldn’t get it to work)
  • Can easily mix API and web browser automation in same script
  • Don’t need to write “code” just follow an API and write a gherkin steps

Not sure 🤔

  • I couldn’t get parallel execution of tests to work well using the command line execution argument for Chrome browser tests
  • I’m still not sure about using plain gherkin files to define implementation detail such as css selectors and API end points 🤔
  • I’m not sure the best way to get this running in CI: probably using the executable? I didn’t spend time on this.

Summary

Whilst Karate is a unique testing tool, I am not sure how well it would scale to a med-large software project considering things like configuration and reusability seem difficult to implement in plain language gherkin files. For a small project or perhaps some throwaway test scripts I think it would be a fun way to write these types of tests.

Categories
Meta Wordpress WordPress.com

Why self hosted?

This site still runs the latest version of WordPress but the main difference between this site and my old Watirmelon.blog one is this one is self hosted and not on WordPress.com like my old site was since 2006.

“Why self hosted after 14 years?” I hear you ask. I did work for Automattic who runs WordPress.com for over three years and I am a huge fan of its products and platform but there comes a time when long-standing bugs/missing features weigh you down and make you switch away from something you love.

The first bug was a security limitation on all WordPress.com sites whereby you can’t embed any content from another WordPress.com site.

See I want to embed content from my own site in my knowledge base, but on WordPress.com it isn’t possible – and it just silently fails and falls back to sad looking text hyperlink.

An awesome WordPress embed

WordPress.com offers an awesome feature to email new content to subscribers but the inability to change it from anything but immediately was a constant anxiety inducer: if I accidentally hit Publish before being completely ready it would immdiately email 1000+ subscribers with no undo 😕

I now use MailPoet which enables configuration of when to send emails to subscribers – I send an email once a day at 1pm local time if I have created any new content since it was last sent. This alleviates my publish anxiety as I know I have until 1pm each day to fix it before it’s emailed.

I also really wanted to add an automatically generated table of contents to each page in my knowledge base – there was no way to do this on WordPress.com.

One thing I realised by moving to self-hosted is just how much WordPress.com offers without any plugins. I didn’t realise WordPress doesn’t offer in built site stats – that’s a WordPress.com thing.

I try to avoid WordPress plugins since they’re notorious for slowing down your site, however I did end up a small list of handy things that I need:

  1. Akismet Anti-Spam: name says it all 🐷
  2. List Pages Shortcode: to show child pages of a page in a page – just works on WordPress.com
  3. LuckyWP Table of Contents: table of contents
  4. MailPoet 3
  5. Site Kit by Google
  6. SyntaxHighlighter Evolved
  7. Widget Context
  8. Wordfence Security

One thing I can’t do at the moment is automatically publish to Twitter and LinkedIn, but due to my Publish Anxiety anyway I use a manual process for that.

The final question you may ask is why I didn’t use the Business Plan on WordPress.com that allows most plugins and would have solved most of my issues?

This site runs free of ads and creates zero income or revenue for me. The Business Plan would enable some of the features I mentioned above, but it’s AUD$396 per year. My employment income has fallen due to the economic impacts of COVID-19 and I can’t justify that cost when my current managed host costs approx AUD$50 per year to host the same site (8 times less).

Categories
Agile Software Dev

Example of lightweight feature documentation 📃

In response to my article about BDD in 2020 I saw this question on Twitter:

I thought it would be easier to write an answer here and provide an example.

I’m not keen on writing specifications in gherkin (Given/When/Then) as I think it’s too generic and frequently makes the feature specifications too verbose – and takes emphasis away from the critical parts.

Here’s a made-up example of some lightweight feature documentation that would be generated during the development process. The important thing to note is the actual documentation artifact generated isn’t as important as the collaborative process that is involved in generating it. This is often about asking the right questions and adding more examples until there’s nothing that is unclear.

The document isn’t a template – the actual documentation varies based on conversation, problem and context.


Example: Royalty Payment Splits

Background

  • Royalties need to be paid in full on disbursement to artists.
  • A royalty payment can be made to an individual artist, or a group of artists.
  • When making payments to an individual artist they get 100% of royalties (no rounding)
  • When making payments to a group of artists this needs to be split by the percentage splits defined in the system which always add to 100%
  • When splitting a payment across a group of artists and it doesn’t split evenly into cents, the system currently randomly splits the cents between artists to balance out the rounding over time
  • This causes issues for both automated tests which need deterministic behaviour, and artists who are confused why they get slightly different amounts if their royalties are the same.

Scenarios / Examples

ScenarioRoyalties OwedCurrent Royalties Paid New Royalties PaidTesting
Single artist gets 100% of whole payments$100.00$100.00$100.00
Single artist gets 100% of payments including cents$66.67$66.67$66.67
Two artists with 50% each for a payment that can be split evenly $100.00artist 1: $50.00
artist 2: $50.00
$50.00
Two artists with 50% each for a payment that can’t be split evenly$100.01$50.01 / $50.00 is randomly assigned to artist1/artist2artist 1 $50.01
artist 2
$50.00
Two artists with 50% each for a payment that can be rounded to ten cents – no rounding$100.30artist 1: $50.15
artist 2: $50.15
artist 1: $50.15
artist 2: $50.15
Three artists with third splits can’t be split$100.00amounts of $33.33, $33.33 and $33.34 randomly assigned to group members artist 1: $33.34
artist 2: $33.33
artist 3:
$33.33
Three artists with third splits can’t be split – more than a single cent difference$100.00amounts of $33.33, $33.34 and $33.34 randomly assigned to group membersartist 1: $33.34
artist 2: $33.34
artist 3:
$33.33

Business Rules

  1. Royalties need to be paid in full on disbursement to artists.
  2. A single artist gets a whole payment.
  3. When payments can be split evenly to a group of artists (to the cent) they are split that way.
  4. When payments can’t be split evenly to a group of artists, the payments are split into an even split and the remaining cents are distributed to the members in whole cents.
  5. The first member in the group – based on earliest date/time added to group – gets the higher amount, followed by the second, third etc. based on earliest date/time added.
  6. Payments aren’t rounded to ten cents or five cent amounts, only whole cents

Questions/Decisions

QuestionDecisionMade By
Do we want to round to five or ten cent distributions?No, we’ll always round to the centProduct Owner via Slack #
How do we distribute based on membership of group?We’ll use the date time added to the group (first gets most)Team during kick off meeting

Summary

I think trying to force the above information into gherkin (Given/When/Then) statements would make it less readable and provides no added benefit – whilst Given/When/Then encourages consistency sometimes you just need structured thought that is most relevant to your context. The above document isn’t a template – it varies for the problems we’re trying to solve.

Categories
Agile Software Dev

BDD in 2020

It’s 2020: can we officially declare Behaviour Driven Development (BDD) dead?

How did we get here?

“There is no trap so deadly as the trap you set for yourself.”

Raymond Chandler, Long Goodbye

BDD’s lure was the promised land of collaboration between business and technology defining expected behaviour as executable specifications (automated tests). These automated tests defined our software development processes: outside-in software development, behaviour driven development, acceptance driven test development and specifications by example.

BDD’s trap was a bunch of Cucumber specifications written after the fact that create another layer to automate tests in a browser, hidden away in source code which are seldom, if ever, seen by the business, and either too comprehensive, flaky and expensive, or narrowly focused but lacking in enough detail for a complete executable specification of a system.

Sure BDD tests can drive things besides the browser, but the overhead and complexity of maintaining these outweighs the benefits they serve, especially when there is still a need for more expensive integration/e2e tests anyway.

So what actually works in 2020?

I’ve found this process seems to work really well for modern software development in 2020:

  1. Every new piece of work has a kick-off discussion with the product owner, the tester and the developer(s)
  2. The tester usually facilitates this meeting and aims to produce written lightweight documentation during the discussion containing the following information: background info, scenarios, business rules, examples (edge cases), questions and decisions.
  3. This documentation is enough for development work to begin, and the tester to plan how they’ll test it.
  4. The documentation is updated as work progresses: questions arise and decisions are made (and documented).
  5. The developer(s) is/are responsible for making sure there is automated test coverage for these business rules at the cheapest level of testing, these are typically automated unit and/or automated integration tests. These aren’t written in business readable language, they’re test code alongside production code.
  6. The developer also needs to ensure any existing automated end-to-end (e2e) tests are updated for the work that is happening – CI builds highlight these impacts/failures.
  7. When the feature, or a working part of the feature, is ready for testing the developer and tester do a quick handover/walkthrough making sure what was done is what was discussed.
  8. The tester uses the lightweight documentation as a basis for their testing, but adds extra rigour in testing edge cases/unknowns, other impacted areas, different browsers, performance, and devices and anything else they think could be risky.
  9. Bugs that are found and determined by the product owner to be crucial are fixed immediately, some bugs become “fast follows” which are the next thing to ship. Some bugs aren’t fixed.
  10. The tester gives a walkthrough to the product owner and sometimes UX designer to make sure what’s been done is acceptable – if the feature is new/risky it’s launched to a subset of customers and can be disabled at a flick of a toggle.
  11. When an entirely new feature is added to the system and it’s important enough to warrant an (expensive) automated e2e test – the tester works on adding that in amongst their other work. This isn’t a blocker to release and provides a safety blanket for future changes. This isn’t a comprehensive specification of the system – it’s an e2e automated test that covers a business critical flow over multiple moving parts and again doesn’t need to be business readable.
  12. The specifications/documentation lives on in a wiki page and can be referred back to when testing future changes to this feature, or when support tickets or bugs are found in production.

BDD isn’t working for us, what can I do now?

  1. Make sure you commit to having kick-offs and encourage robust discussion creating lightweight documentation as you go – remove uncertainty and create clarity by making and documenting questions and decisions.
  2. Keep your lightweight specifications up to date as you go – don’t worry about making them executable – let people write automated tests in the way that is the most efficient for them.
  3. Only use automated e2e tests to cover key user flows in the most efficient way – don’t use these to create/maintain comprehensive living documentation.

Also See:

Categories
Meta

Welcome to my new site 🙌

Welcome to my new site. I thought it was time I gave it a new name: RIP WatirMelon 💀

My focus over coming months alongside my regular blogging will be building up a comprehensive software testing (and more!) knowledge base which will act as a source of information about different aspects of software testing. An example:

If you previously subscribed by email, you’ll need to do that again. See this page for details.

Welcome 👋

Categories
Agile Software Dev Project Management

The importance of a decision log 🎋

It’s no secret that I love writing and love documenting things. This is where I’m a bit different to a lot of people I work with who prefer writing code to documentation.

I have a lot of project management responsibilities as part of my current role, and I’m a big fan of “fixed time/variable scope” as a way to get rapidly get important things done. This works in that we can say to our product owner how long do you want to spend on a feature, which then enables us as a development team to do everything we can to get as many things done in that time.

There’s two things I have found that are crucial to succeeding in this approach:

  1. Documenting and maintaining a list of up-to-date things that need doing that is constantly refined and re-prioritized based on discoveries; and
  2. Documenting decisions as they take place in some form of “decision log”

A decision log isn’t for blame. The reason a decision log is crucial is it allows us to decide, document and move on. This enables velocity since we don’t ruminate on decisions. It’s also good during conversations where you feel “déjà vu” as we often forget what we’ve decided previously, and it’s easy to refer to our log and say “we’ve already talked about this and we decided this for that reason”.

I like the simplest decision log that will possibly work for your context. Ours is a Confluence page with a table in reverse chronological order (so the newest decisions are at the top):

QuestionDecisionMade By / WhereDate
Do we want to limit the max records?We should limit it to 50. That’s a sensible limit and we can adjust based on feedback.Product owner during Slack Conversation (link)28 April 2020
An example decision log

This doesn’t mean we can’t change our mind, flexibility is crucial, we just need another decision log entry to show we changed our minds 😊

How do you make and document decisions? Are you a fan of fixed time/variable scope?

Categories
Continuous Delivery Continuous Integration Software

Visualising Technical Debt (with the Debt Boat)

Being successful in software delivery requires a team to constantly balance technical debt and feature delivery. Teams often fall into the trap of delivering features too rapidly at the expense of ever increasing technical debt, or delivering a over-engineered solution at the expense of not delivering things within reasonable time-frames and before any real world usage.

This is one of the key issues facing most software delivery teams I have worked on as there are often different appetites for delivery vs debt throughout an organisation.

I was trying to come up with a way to present technical debt in a visual format that could be easily understood by different people: management, stakeholders and a development team.

One thing we value is shipping things: getting our products in the hands of customers so they can get value from them. Accumulating technical debt, both customer facing and “under the covers” may allow us to rapidly get features to our customers, but eventually the debt grows and affects our ability to deliver.

In the “shipping” theme I came up with the Debt Boat: a way to visually represent things that build up and eventually slow us down. I like splitting technical debt into both feature debt: things our customers want but we chose not to do, and system debt which is technical things our customers (or product owners) can’t see (below the water line) but increasingly slow us down.

We originally had this boat on our team’s physical wall to show there’s only so much technical debt we can take “on board” before we sink.

Now that we’re 100% remote (for now) I’ve created a Jamboard version. I’ve shared the template here – you can easily make a copy if you think your team would find this helpful.

Click to view on Jamboard