#TW30DaysOfTesting – Day 26: Getting comfortable with mindmaps

Mindmaps are a tool which I have heard about and dabbled in for at least a couple years now. While I have always wanted to see them work for me, I just haven’t quite found them to be natural within my workflow. When I use a tool to create them I feel bogged down by how it is structured or non-intuitive shortcut keys. When I do them by hand I have a mix of issues with my handwriting and with not being able to erase or edit once its been written. That being said, I have always found them to be valuable and interesting as a thinking tool. I think this is why I thought to use them again more recently on my current project.

In my current project we are “adopting and adapting” a product from another region. One large module we needed to adopt was the file storage system for a user’s documents. This includes functionality like saving/deleting/copying/moving as you would assume. But when you dig in deeper there is creating new folders, restoring deleted files, renaming files, adding notes, and the list goes on.

Once the developers wired the whole module up there were a lot of questions around if that means the feature works. Being my usual cautious self I decided to list out the risks and in turn the testing options to verify this. I laid them out a bit like the three bears and as you might assume the business picked the medium route. The more intense route included needing data/user permissions to be clarified significantly more, and also included development work as it would have wrapped automation around the current behaviours. The smaller route was really just a gut check and may have caught the big things, but relied on end of lifecycle certification testing to catch anything more hidden. The middle route meant that I would dig into every nook and cranny we could identify, but that only a single user permission and a priority set of 3 document types. This clearly is not 100% coverage, but it seemed like the right call on cost/value for the team.

While the product owner had identified the features they could as user stories, I was not familiar with the original feature and wanted to dig in more. I decided to explore the original team’s site and see if there were any more features we should be testing. During this exploration, I created a mind map with Freemind. After a couple days I found that my perceived issues with the tool fell away and I all of a sudden felt like it sped up my work significantly. I could link externally to the user stories I was creating to track my work and I could also link internally within the map so that I did not duplicate nodes when it was the same toolbar on multiple pages.

In the end, I colour coded the mind map to indicate where the original product owner stories were covering, where some test cases we dug up from the other team covered, and where I identified additional work to be done. This set me up to have a really frank conversation with the business about the cost and time frames for the testing as well as visualise why even with the middle route of testing, there is significant risk given the size of the feature.

Mindmap to indicate test coverage for a folders feature in our application. Red indicates the areas totally uncovered (approx. 1/3 of the map).

Since then I have been creating smaller mindmaps for each feature as I test it. I use the mindmap to write down my targets for the testing and some different data cases I may need to create. I then identify any behaviours I notice along with screenshots and annotations of them so that we can review and decide which of them are defects in our adoption, global defects across products, or enhancements that could be applied globally.

This has proven to be an amazing way to showcase the testing effort and everyone has really loved having more of a discussion around testing instead of the historical way which included the business signing off test cases before they could be run. I am now actively looking for other ways to use mindmaps effectively and I am excited to next create a mindmap which describes my current responsibilities and activities so that as I onboard a new QA/Scrum Master it can drive our conversations.


#TW30DaysOfTesting – Day 24: Introducing friends

Today is about mixing groups of people who may not otherwise cross paths by keeping in mind that first statement around making testing communities, not tester communities. One very cool initiative being driven out of the ThoughtWorks office is HackBrexit. It was created out of the passion around the Brexit vote and was kicked off with a weekend hackathon and has since given birth to a biweekly evening event hosted in out London offices.

They have had amazing support and energy but continue to benefit from an array of skills not just development. Therefore, I am going to invite one of my friends who is a Technical Writer to the event on October 5th to see how she can get involved and as well!

#TW30DaysOfTesting – Day 23: Helping out from content generation

Today was about helping someone else test better. The whole point of this challenge being open to all roles is that everyone does testing in their day to day so there are always a lot of opportunities to do help others.

In this case, I had a meeting set up with a content creator for our application and it was a prime time to do some testing. The project I am working on is very content driven and at the same time has a very long pipeline from creation to publishing. This means that while the most important part of the application is content, it is also the part that has the longest feedbacks. The first time we got new content a lot of really interesting things were uncovered and a couple months later are still unresolved. One example is how we handle bullet points (we were getting actually an HTML generated bullet point and an icon bullet point which was clearly not expected).

We are up for another round of new content types to be generated and so I asked one of the creators if we could spend some time together before the process got too far along. The new content is a type of flow where the reader will need to make decisions which will impact the next step. One thing that the content creators were already implementing was an attempt to drive more iterative development. They were doing this by first creating a flow without any decisions, then with only on decision that is binary, and then continuing to build up. This was fantastic and we were able to review the progression which was really well done.

Where helping actually came into play was discussing what was going to be in each step of the flow. We started to talk about how the differently formatted content (URLs, bullets, bold, italics, etc) made such an impact on the previous content, and how we could do better this time around. We spent the remainder of the meeting identifying realistic use cases for different special characters and formatting so that we could build in the testing/verification for what we would not be handling as well.

It was a great meeting and a fun afternoon of testing the ideas before any bit of software was written. This is actually one of my favourite ways to test and I have seen some of the best return on investment with introducing people at these early stages to thinking in a specification by example way. So fun!

#TW30DaysOfTesting – Day 22: Alone we can do so little, but together so much

My one way to help out the UK region is such a cop out…it is THIS!

Even throughout the engagement of this challenge I have had people discuss how they would like a stronger QA community, yet they are not participating in the day to day challenge. I think that sometimes it is easier to discuss about generic dreams for things, but the real challenge is in getting something started. Here was my straw man, and I am so excited to be receiving feedback and ideas for how it has been effective, but also where it needs to be tweaked.

So…to be a bit more actionable for the future. What I will do to help support our region is not just treat this challenge as a one off event. I will collect and apply feedback to recreate it in another form and continue to create a space for collaboration and learning!

This is in direct response to some of my personal annoyances with how I have wrapped up previous events. There are times I make such a push for a certain event or moment that by the time it is complete, I have very little gas left in the tank to create substantial outputs. The number one example of this was the fantastic workshop Lisa and I did TestBash Brighton earlier this year. I am so grateful that it has been reaccepted to European Testing Conference and that Bhagya has agreed to come on board as a pair for the event. This has given us a chance to refine the original talk, but also we are hoping to finally create the open source materials so that more people can recreate the training with their own offices and teams.

Hoping to make this the new trend!

#TW30DaysOfTesting – Day 21: Ouch, I wouldn’t want to use that either

I know that accessibility and usability are two different aspects to an application. But are they?

So today I want to call out an element that I know was created due to design requirements. The element is only intuitively usable by a mouse as the keys used to navigate the dropdown are all a bit off (e.g.: you can not use arrow keys in the drop down, you must use tab to change options). And it is downright impossible to use by voice over technology (found for free on all Mac computers). To showcase this, I have recorded a short screencast that captures this but I can’t seem to upload it (Twittter doesn’t accept .mov files and wordpress is requiring a paid upgrade!).

(EDIT: Got it uploaded! https://twitter.com/a_bangser/status/778891979002355712)

Over and above the mildly infuriating upload issue, it is just really important to always be reminded that while Visual Design, User Experience, and Accessibility all matter independently, they are all far lower value when they do not at least consider the other two.

A very nicely designed sidewalk, and the user experience created dirt path next to it. (https://guycookson.com/2015/06/26/design-vs-user-experience/)



#TW30DaysOfTesting – Day 20: Why did it take us this long??

Looking back at one of my personal goals for introducing 30 days of testing was the lack of cohesiveness within our testing community. We have so many amazing people doing amazing things, but because of commitments to regions, office, and clients we can find ourselves sometimes unaware of other people’s work.

I remember very clearly being just about a year in and feeling pretty confident. So when I saddled on up to the communal working table in the Chicago office and saw an unfamiliar face I introduced myself…”Hi, I’m Abby. Are you new to TW?” It is hard to forget the deadpan look back (don’t worry, now we are friends!) and the response of…”Hi, my name is Jimmy and no. I have been here 6 years.” Whoops. Definitely taught me to make no assumptions, but also was only the first time of many more where I was surprised by finding a new amazing person that I logically should have crossed paths with many times already.

Luckily for this challenge, that still exists. Today I formally introduced myself to a QA in the San Francisco office named Leonardo. He has about 1 more year experience at the company than I do, and I have seen him pop up on the QA mailing list from time to time, but being in different North American regions, we just have never met directly.

Here is to new friends!

#TW30DaysOfTesting – Day 19: Tool supported testing

Today I am going to actually write about a tool my team introduced recently but I am going to spend some time getting to know better.

Our team is producing the front end for a very complex, big data, back end. We spend a lot of time with JS and CSS and are finding that the focus on Visual Design is very high, but not always robust between different screen sizes or when different elements get added to the pages. Over the course of the last 6 months, we have spent a lot of time pushing, and re-pushing, pixels to get aligned with a photoshop design (of which we can not inspect since developers do not get photoshop licenses).

We tackled the long feedback loops with a couple of different collaboration wins, including daily screen shares/phone calls with the Visual Designer and weekly in person pairing sessions. But there was still a concern that each time the designer looked at our site, something else got pushed. Now I had a sneaking suspicion that while some of this was regression, it could not possibly all be regression, yet we had no way to compare what was asked for and what was current since a lot was done in Photoshop files and/or by voice.

Enter visual regression testing.

Sigh. I already know that I have lost a large group of you because visual regression testing can be flakey, high cost/low value, etc, etc, etc. I too am very skeptical, but this is by far the best use case I have seen and the dev team is actually who suggested it for us so it is team bought in.

So we put a card in our backlog and we spiked out some options and ended up implementing BackstopJS. I hadn’t heard of it before, but it seemed to meet our needs and was quick to get running so we figured we would give it a shot.

So far we have felt some of the pain of a relatively new tool, as well as some of the pain of visual regression testing, but we are about to put it to the test as we shift focus from one set of screens to another. With this shift, we will be refactoring a lot of SCSS files to limit duplication, and in order to move fast, we need to have confidence that the original set of pages are not changing. Sound familiar? Yup. Pretty much the textbook definition of when you need to introduce testing.

So today I am going to dig into the tool a bit more, and in particular try to tackle an issue we are seeing where the element we want to screenshot does not get found on first try and can create false negatives.