Skip to main content

A reflection on Let's Test 2015: Part II

Here's the link to A reflection on Let's Test 2015: Part I

The sessions (Part II)

Below does not include all of the sessions I went to nor all aspects of the session I mention


Visual Creativity: Using Sketchnotes and Mindmaps to aid your agile testing - Dan Ashby and Christina Ohanian

Before this session I stumbled upon Christina drawing out her sketch notes from the previous session and marvelled at how fascinating it was. Sketch notes were only something I'd only ever seen on the net. They were gorgeous and a clever way to communicate information.

When she told me that she was going to have a session on this - I was all in.

We 'warmed up' by drawing whichever image came to mind when Dan said a word. It was interesting to see how a lot of people could interpret the same word differently. For example: "Time" could be a clock, a watch or an hourglass.



After this we got down to the nitty gritty and started drawing some sketch notes based on some requirements from Trello. It was tough - I drew a blank with quite a few words but got there in the end :)

Afterwords, we tested Trello using mindmaps with the groups we were sitting in. Not only was this a great way to help us learn how to communicate information using mindmaps, it ended up being a good indicator of how useful our sketch notes were.




Exploring Web App (In)Security - Bill Matthews and Dan Billing

We learned about the THREAT model and then how to apply it. We also learned STRIDE and split up into groups to brainstorm ways we could use STRIDE to 'attack' the test website that Dan and Bill had created for this session. I must admit some parts of STRIDE were easier to brainstorm for than others (For me personally, information disclosure was a whole lot easier than repudiation).

I absolutely loved the hands on aspect of this session. It was great to learn about stuff that I'd often heard mentioned, like SQL injections and Tampering, but never had an opportunity to do (in a safe environment of course).

In this session we got constantly reminded about the importance of being ethical and making sure what we're doing is legal, should we want to pursue security testing in the future. For us to flex our security-testing muscles, Bill and Dan pinpointed us to some Bug Bounty websites where, if you find some security flaws in their software, you get some compensation (etc.).


Feedback Bootcamp - Tobias Fors

A few days after this session the first thing that comes to mind is someone kicking down a door and saying "Feedback time motherfuckers". This is NOT how to create an opening when giving feedback to someone.

In this session, we learned not only how to give feedback but also to receive feedback. I loved the fact that the lessons learned in this session could be applied in all work contexts (not just for those who work in testing).

We did a few activities to learn how to give and receive feedback - one of which was to write a Haiku as a team. Part of the activity was also to decorate the piece of paper on which we wrote the Haiku. Afterwards we were asked to give feedback to each-other and also to receive the feedback. People were also allocated the role of the observer. One interesting thing I observed was that some people have a tendency to go on a bit more than they should. When it comes to compliments, I felt it could "weaken" the compliment somewhat.


Key Takeaways


  1. Being surrounded by a bunch of people who are passionate and excited about software testing is a great way to reignite your love of testing.
  2. Having a conference with well-organised, interesting sessions was great - but it's the conversations I had with people at meals and the friends I made that I'm most grateful for.
  3. Attending both sessions that I felt are within my comfort zone and sessions that were outside of (my comfort zone), meant I really enjoyed being challenged.
  4. I seriously recommend any testers who want to 'rediscover' testing and be surrounded by passionate people who also want to learn - should definitely go to Let's Test 2016 

Comments

Popular posts from this blog

Getting started on a testing project

I started on a new project a few weeks ago and thought it would be a good idea to share a checklist for what new testers on a project need and some good starting questions when you, as a tester, are new on a project Checklist for what new testers on a project need (Note, your project may not include all of the below) Note to check if user credentials are needed for any of the below

My Most Used Test Heuristics (with examples)

First, what is a heuristic? A heuristic is a guideline ,  it is fallible.  Therefore, it will give you a good idea of what behaviour you should see BUT it isn't definitely what should happen - it's up to you to confirm that the behaviour you are seeing is correct.  In a previous blog post I shared a step by step guide on  how to test without requirements/little requirements.    But I figured it's good to share my most used test heuristics that I use for testing without requirements. They are: Consistency with History Consistency with User Expectations Consistency within Product Let's take a look at each of them along with some examples to illustrate the concept. 1. Consistency with History  The feature's or function's current behaviour should be consistent with its past behaviour, assuming there is no good reason for it to change. This heuristic is especially useful when testing a new version of an existing program. (Source: developsense) Example: Whitcoulls, a