#TW30DaysOfTesting – Day 29: Nice to not be in an echo chamber

This challenge may not make sense to most people reading this blog, so let me start by explaining it a bit. My.ThoughtWorks is an internal communication tool where we have the opportunity to create content, share ideas, and get exposed to a diverse set of opinions on topics ranging from low level machine learning to design patterns and current human rights causes from around the world. From what I hear, many companies that get to a certain size start this type of communication forum and it provides great value, and my.TW is no different. However, in creating the 30 days of challenges, I was thinking about how much we consume each other’s outputs, but how much less frequently we provide feedback (or extension on) to them. Some of this is time or interest, but I know (from personal experience) that some of this is also from how daunting it can be to respond to a post where there are over 4,000 extremely smart and outspoken individuals on the other end who may be driven into the debate.

While I am an active member of the testing and women in tech channels on my.TW, I am more hesitant to write on the infamous software development channel (arguably the most useful and active channel) or some other more highly specific channels like our security channel. Already in this 30 days I have posted to Software Development about collating a list of podcasts and that has received tremendous support and been extended to so many new and interesting ideas which encourages me to engage even more.

So today, I have been inspired by a post in the security channel about how to engage the business in cyber security which points to a very interesting article in HBR entitled “How Cybersecurity Teams Can Convince the C-Suite of Their Value“. The post is from 4 days ago and has a single reply so far which also points to threat modeling with executive sponsors as a good way to extend interest in cyber security. Below is my reply to the thread:

Thank you for sharing this article. I find it really interesting to see a case study of how other companies are tackling these challenges. And while I agree and support our focus on threat modeling as a way to inform businesses of their risks in the security space, I think that this article is pointing at some really new an innovative ideas that we could look to also trial.

In particular I really liked the proactive approaches that the Facebook team took. They remind me of my interest in creating “safety nets” for future defects instead of just wrapping tests around current code. An example of this for me is when we are doing end point testing. Just putting in tests for each end point requires us to remember to add the test. Instead, I look for ways to scan for endpoints so when a developer is creating a new one that is one less thing that they need to keep on their mind. Another example of this would be teams that run the security scans in their build looking for vulnerable dependencies and other risks. Can we try and cultivate other examples of where we are doing work like this?

And at the risk of dividing this thread I want to also raise a point we discussed at the last TWASP meeting. As a QA I am often in a position to raise these risks and am also often feeling they are not well received as they are viewed as abstract. One request I made to the room, and now here, is if we could create something more impactful to showcase to clients when we find a vulnerability. For example, when I find reflection JS injection risks, I tend to showcase it with a popup. This is proof it exists, but in my experience this has been met with a bit of an eye roll and acceptance that if someone wants to create a pop up on their own computer…fine…let ’em. Also during the TWASP meeting I was shown just how powerful the reflection attacks can be but am unsure if I could recreate it. Do we have (or could we create) a repository that could showcase really business critical examples for the OWASP Top 10 when they are identified on a program?

Advertisements

#TW30DaysOfTesting – Day 28: If you don’t have anything nice to say…you probably aren’t looking hard enough

Oi. This has come on quite a day! But as I mention in the title, there is almost always a shining spot and it is worth sharing that encouragement with people as they struggle through the challenges.

So today’s task…test a new integration point which has taken almost 3 weeks to wire up.

I am feeling fairly stuck in the mode of “trying to make it work” rather than really trying to challenge assumptions and push on boundaries. That is never a place I like to be in, and it probably a blog post in it’s own right. But suffice to say, there is a lot to be upset with today while testing this story.

But!

The developers were brilliant while producing this story 🙂 They knew that the data setup would be a struggle, and we had talked about how that would need to be improved before story sign off. Thankfully, they not only agreed with that need, but really gave it a great effort. They created (and checked into source control) some Postman scripts. Not only that, they thought to parameterise them and use pre-request scrips to allow shared variables to only be set up once.

No. This is not an ideal story slicing. No. This is not an ideal implementation. And no. This is not a warm fuzzy feeling as we move towards completion. Lucky for me, I have a team where I can pass on my sincere thanks and praise for how much they value building a quality culture on our team. I know that with that type of attention, we can sort through the challenges and create a fantastic product!

#TW30DaysOfTesting – Day 27: Long time no see

This is one of my favourite of the challenges for this 30 days. I find there to be such great camaraderie built when I am on a project with amazing people, especially when we are on the road and trying to build a bit of a life in a new city, but then all of a sudden you separate! The relationships I have built have translated into wedding invites, group vacations, and lots and lots of work related debates and support.

Today I decided to reach out to an old friend that I actually first met in relation to the new hire program at ThoughtWorks. She was a graduate hire not long after I had been through the program and we started to chat about that and about life after returning from the training. Since then I have been lucky enough to be staffed near her (yay social events!) and even on her same project (though still not on the same team).

Aside from just wanting to say hi to an old friend, the reason I chose to reach out and say hi to Aubry was because she is on the project I left when I moved to the UK. It was a big engagement and had so much potential but also had a very long timeline. They are currently in a push for go live and I am super excited to hear how things are going.

Other reasons I find myself reaching out to old teammates…

  • Quick hellos
  • Recon on what they are working on and if they need a new teammate (wink wink)
  • And of course the other way to see if they would want to join my current team
  • Questions about old experiences I want to use as case studies in my current project
  • Opportunities to speak at new conferences (oh heyyyy James Spargo / TeshBash Philly!)
  • Congratulations for recent go-lives or other accomplishments
  • So many more…

So I hope you all take the time to say hi to a past friend as well, it is truly a wealth of support and learning that I try to take advantage of as much as possible.

#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.

largemindmap
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!