The Project is a Highway Retro Format

     

I was recently asked to facilitate an agile retrospective for another project here at SEP. After reviewing their project, I realized I didn't want to do one of the existing retro formats I knew of, because I was feeling like there was something missing from some of the standard ones (such as Sailboat). I decided to experiment with making my own. Thus was "The Project is a Highway" retro format born!

I was inspired by the fact that the project was related to roads and leaned into the metaphor. Take a moment to look at the drawing above (created by one of our talented UX folks).

Here's each part of the model:

Tolls - These are prices you pay knowingly, usually to make the project better in the long run, or compromises that are required for business reasons (adding some tech debt to make a big milestone, using a certain technology to match the rest of the business, etc.) Are there any of these that might have been avoidable, possibly with different decisions in the past? Did any past decisions affect this work? There's nothing wrong with having some of these, but it's good to acknowledge why the project paid for them.

Straightaways - These are areas where the project went smoothly. What made them smooth, and can you get more of this in the future?

Potholes & Cracks - These are unexpected snags in the project, causing you to have a rough time, or to work around them and end up slowing down progress (unexpected end of life on a tool, for example).

The Destination - Did our destination change as we worked? Do we still have a vision of where the project is going? Do we all have the same vision? What comes next for the project that we should talk about?


After using this, I reflected on what, exactly, I liked about it over some other retrospective frameworks. One realization I had is that I like the Tolls metaphor specifically because it calls out that we sometimes make deliberate decisions to slow down feature work, which some other frameworks don't cover.

Testing Code Review

 The other week I was asked by someone on the Testers Slack for how I go about doing a code review from the perspective of a tester. I figured that I should share this in case others are interested in my thought process for it. This post will be my idealized thoughts on it, even if I sometimes shortcut a bit.

First thing’s first, know what you’re reviewing

First, a mea culpa from me. I have definitely skimmed this step more than I should in the past, and it usually means I need to go back and figure out what I missed.

What I mean by this is that you should take the time to review the story/requirements up front. If you’re not sure about a requirement or an acceptance criteria, ask the person whose work you’re reviewing. If you both have different understandings of the work, then talk to a Product Owner or some other domain expert.

Feel free to jump back to the story as reference.

Second thing’s second, focus on what the team relies on you for

If you’re a tester (or performing that role for the team), don’t focus on the code itself. Look at the tests that are there, then look for tests that you think should be there. Looking at the code is also useful, but not where you’ll add value to the code review.

Make sure to comment not just on the contents of the test, but also how it is constructed. Make sure that patterns and styles are followed correctly.

Miscellaneous thoughts

Most of my career has focused on system and UI level tests. I do sometimes review integration and unit tests fairly closely, but I tend to take longer on those (and the developers are typically more responsible for that level of testing). If you’re more focused on those levels, it probably makes more sense to focus on the code more than I do.

If your process is like ours, code reviews are open to everyone, but one person is typically the main ‘reviewer’ who looks into the code review more carefully than others. Typically, I mark myself as the main reviewer if the tests are a main focus of the review.

You Are Valid

Drink some water.
Eat some food.
Take your meds.
Take care of yourself.
You are valid.
You are loved.

These (or similar) are words you hear a lot from the LGBTQA community.

And there's good reason for it. Many queer folks have had traumatic experiences (warning, heavy topic, includes mention of sexual assault, assault, and suicide, especially in the links within the article) that have left them with cases of anxiety, depression, and other medical conditions that they have a hard time handling on their own.

So, a lot of kind and wonderful people make it a point to post these reminders regularly.

And really, who hasn't needed a reminder for something in their life?

I'll break each line down into why I think they're important:

Drink some water

    It's pretty easy to get dehydrated if you're not careful, and drinking water has plenty of health benefits.

Eat some food

    This helps keep you going. It's also important for those who have blood sugar issues to keep up their mood and energy level.
   

Take your meds

    If you have a mood disorder, it can be easy to forget to take your medication, including some that helps you to keep living! Many Queer folks use medication to improve their quality of life.
   

Take care of yourself

    Self-care is an important thing to do. Take a day off, read a book, listen to some music, seek help from others, professionally or otherwise. These are all important steps to take regularly in life.
   

You are valid

    Too many people in the LGBTQA community get told they are "just going through a phase" or "that's not natural". Letting people know that you acknowledge them for who they are can pick someone's day up.
   

You are loved

    This one is probably the most important one for me (and something I should say more often). People are deserving of love just by being. No one should be excluded from that, but some people in the LGBTQA community have been hurt by those who should be closest to them.


Finally, if you or someone you know are having struggles, please reach out. These may help (USA-Specific):

1-800-273-8255 - Suicide Hotline

877-226-3111 - Addiction Hotline

844-228-2962 - Eating Disorder Hotline

877-455-0628 Self Harm Hotline

https://www.thetrevorproject.org/

https://suicidepreventionlifeline.org/chat/ (for those who don't like phones, or can't call for whatever reason)

Lacking Motivation: How to Restart Your Testing Brain

I came in to work today and had one of the things I dread hit me:

A lack of motivation.

This is hardly new. Everyone's had a lack of motivation.

Sometimes it's chronic (in which case, I suggest researching why and fixing that if you can!).

Sometimes, like mine is, it's probably caused by a bit of a feel of repetitiveness in my work lately, combined with not having as relaxing a weekend as I wanted.

But somehow, this morning I still got a decent amount done.

In the hopes that it can help someone else in a similar spot, here's what I did:

Get Focused

First, I cleaned out my normal drinking cup and got some water. I've found that some minor cleaning or other non-mental work helps prep me for doing something mentally engaging.

Get A Quick Win

I had two tasks that were in my queue this morning. One was going to be long, monotonous (as I have to do the same checks across various platform combinations).

I took the other one. It was a straightforward bug, simple to test for, but with some neat little edge cases I could prod.

Springboard off the Quick Win

After I felt good about the main path through the bug, I started on those aforementioned edge cases. While I didn't find anything crazy, it did fire up my mind, bringing my motivation levels back up.

Now it's on to the bigger, more intensive task, with more confidence and energy than I could have given it otherwise today.


So, what do other people do when they're really unmotivated?

How to (Cala)bash your applications in iOS

This is the first blog post in a series for getting Calabash-iOS up and running on a Mac with Yosemite.

Some Background...

I was recently asked to kick-start an iOS testing effort for a project here at work.

Unfortunately, I'm not really a Mac person, nor had I used one in quite a while...let alone tested on one.

So what did I do? I immediately made several mistakes.

Mistake 1: Instruments

First, I tried out using Apple's built in tool for automated testing. While it's useful, it's not nearly as friendly as Calabash (thus the name of the post).

Mistake 2: Forgetting others had done this

After asking around, I was reminded that we had another group do work on iOS, including automated tests!

While it was a year or more back for most of the people who had worked with it, I found out through them about Calabash-iOS.

After digging into Calabash, I found it a more intuitive tool.

Basically, Calabash wraps Instruments, hiding some of the uglier parts, while providing some good functionality for testers to hook into.

Putting it all together:

I found an amazingly well-documented pair of blog posts (here and here) for installing everything you need to set up and run Calabash-ios through Ruby. I've copied out the relevant steps below.

Installing RVM and Ruby 

1. Use CMD+SPACE to open up Spotlight (the equivalent to run in Windows)
2. Search for Terminal (the Mac equivalent to command line)
3. In terminal, run the following line

   curl -L https://get.rvm.io | bash -s stable --auto-dotfiles --autolibs=enable --ruby 

4. Quit and relaunch terminal, then try the following commands:

type rvm | head -1

rvm -v

ruby -v

If all was installed correctly, the first command should return 'rvm is a function', and the other two should return their version numbers.

Installing Cucumber and Calabash 

1. In Terminal, navigate to your project directory
2. Run the following command to install calabash

gem install calabash-cucumber

3. Once that is finished, run the following command to generate the files and folders calabash needs

calabash-ios gen

4. Open your project in xcode, and verify that you now have a duplicate of your scheme with a suffix of '-cal'
5. In xcode, go to Targets > Build Phases > Link Binary
6. Add "Security.framework" there
7. Select the new -cal project, select a simulator, then run it.
8. There may be a prompt to accept incoming network connections. Allow that if it displays.
9. The following should appear in the console output. If so, everything is installed correctly:

Creating the server: <LPHTTPServer: 0x8076530>
Started LPHTTP server on port 37265
Bonjour Service Published: domain(local.) type(_http._tcp.) name(Calabash Server)

You should now have a fully-functional set of calabash tools to explore!

I'll make another post about actually writing Calabash tests, and getting them running.

The Possibilities are Endless...But Your Tests Shouldn't Be

Many years ago now, I was fortunate enough to attend a talk by Cem Kaner about testing. It was a defining moment in my testing ideology's development. The talk involved several points, but a majority of it focused around return on investment.

As it turns out this appears fairly often in the testing field.

This leads into the discussion of test automation. Test automation can have a great ROI, but not always. You can end up spending hours, days, or even weeks automating low-risk and low-importance parts of your project with intricate tests that break constantly, when a manual test would have been far simpler, easier to maintain, and freed up time to grapple with more important problems.

Here's some things to keep in mind for ROI in automating a test:

• How often should the test be run? If it's a throw away test or an exploratory test, it probably shouldn't be automated (though some of the setup can be).
• What is being tested? If you're checking for text on a page, then it's almost always a good candidate for automation. If you're checking that screen elements are in their proper places, or that audio quality is where it should be, that is probably better done with human eyes.
• Are physical devices or objects required for the test? For instance, in a login, is there a One Time Password generator that has to be used? If so, you may be able to write a simulator (or disable it for some tests), but at some point, it's best to use the actual device to make sure that nothing is wrong.
• How fragile is the test? Some tests are fragile because the tested area is still under development. It may be best to re-prioritize that area for later. Other times, the tested object may have some non-deterministic quality that requires constant adjustment. In this case, visual verification may be best.

If you have any other good tips, comments, or disagreements, I'd love to see them in the comments below!

Security, or 'What you have, what you are, what you know'

After reading this blog post by Laurie Gavin, I felt I should post something in response considering my limited time in the security world with a former company.

Learning your 1, 2, 3s

Most people log in to websites or their computers using a 1 factor authentication system. Usually, this is your username and password combination. It's a 'what you know' authentication factor. Technically, it's two pieces of information, but that doesn't really make it more secure.

Issues  with 'what you know' systems:
They're guessable or brute-forcible in some circumstances
They require commitment of memory from the user
If reused, weaker systems can be used to get data from stronger systems

Biometrics, as mentioned in Laurie's post, are usually used in 2 or 3 factor authentication. They represent the 'what you are' factor. This is generally a bit more secure (assuming it is implemented correctly), seeing as you hopefully rarely leave pieces of yourself at home.

Issues with 'what you are' systems:
Your body changes over time, this can cause false negatives
They can still be hacked, though it is more difficult.
There may need to be workarounds for those without the required body parts (missing fingers, hands, or even eyes).

One-Time Passwords, smartcards, and other tokens form the 'what you have' security factor. This is usually a physical item (though can be a bit of software for soft tokens) that the system scans/reads. These sorts of authentication were designed to help prevent someone half the world away from impersonating you.

Issues with 'what you have' systems:
Physical objects can be lost, stolen, or damaged, requiring replacement
Sometimes they can be duplicated (or the data on them duplicated)

Note that any of these factors have vulnerabilities, but using 2 or more provides a layered authentication system, requiring more work to get into your account. If you ask me (and you probably didn't, but I'll tell you anyway), we need to move to at least a two-factor authentication system for any important accounts. There have been far too many leaked passwords to make me comfortable with 1 factor authentication anymore.

For more reading.