Showing posts with label testbash. Show all posts
Showing posts with label testbash. Show all posts

Tuesday, 5 July 2016

Introverts and Extroverts - stop labeling yourself.

This post maybe a little controversial and uncomfortable to some readers.  As social creatures we like to label ourselves as certain types.  We like to be part of groups, tribes and social circles. The issue is when we, or others, use these types to defining ourselves and limit our potential.

The focus of this article is looking at two specific personality types which always seem to pop up in conversations.

'Oh I am an Introvert"

'They are they the life and soul of the party, surely they are an extrovert'

If we ignore the fact that most personality testing are flawed, especially Myers-Briggs
"Generally, although not completely unscientific, the MBTI gives a ridiculously limited and simplified view of human personality," Nothing personal: The questionable Myers-Briggs test - Bean Burnett - The Guardian - March 2013
 Then what we are left with is the human desire to 'fit in' and be part of a group.  At the same time by using these labels we can provide excuses for our behavior.

What does it really mean when we say Introvert or Extrovert.

The merriam webster dictionary defines them as follows:
Introvert -  a shy person : a quiet person who does not find it easy to talk to other people
http://www.merriam-webster.com/dictionary/introvert
Extrovert -  a friendly person who likes being with and talking to other people : an outgoing person
http://www.merriam-webster.com/dictionary/extrovert
For those people who know me personally, how would you label me?

I am sure the majority would define me as an extrovert, an outgoing person who like to socialize and talk to others.

However there are times and situations in which I can by shy and find it difficult to talk to others.  For example at large social gathering I can become very inward.  A recent example of this was at Testbash in Brighton where they organize a social event by the beach.  I find these situations very difficult and draining.  I put on a brave face but inwardly I just want to run and find a quiet corner  and be by myself.  The classic signs of an introvert?  Then the next day I am on stage in front of 200 plus people giving a talk and feeling wonderful, relaxed and enjoying the moment.  Wow now I am classed as an extrovert!

For me the key here is we need to stop limiting ourselves by defining our behavior with a label.   Depending on the context you can be an introvert or extrovert, and there is nothing wrong with that.  However if you use these labels to the extreme you could limit opportunities, growth and fulfilling your true potential.  Throw away the label and use your instinct to drive what you want to achieve and then anything could be possible.

Oh and a message to those who work in HR please stop using personality tests to meet some unreasonable arbitrary 'will they fit' tick box.  You may be excluding people just because of how they feel on that day rather than based upon the merits and skills  of the individual.

Wednesday, 16 March 2016

A list of games taken to Testbash

Testbash in Brighton was yet again a highly organised and community based testing conference.

Signup for the Ministry of Testing Dojo to see the talks, which should be available soon.

At a pre-testbash meetup in Brighton I was asked by Rosie if I would not mind bringing some of my collection of games along. That may have had something to do with having a big interest in games and how they can be useful for testers to improve creative and critical thinking skills.

After the conference I had a few requests for a list of the games that I brought along to the Testbash gaming evening.  To provide a reference I have created this page to list the games I brought along and some I did not due to limited luggage space.  All the links are for the UK version of Amazon unless otherwise stated.

Dixit

A wonderful abstract communication game with highly detailed artwork.  The purpose of the game is to describe the card you have to enable some of the players to have a good idea of what your card is.  There is a twist, you want to communicate so only a few people get it, but provide enough information to make sure that no-one does not get it. If everyone guesses your card or no-one guess your card then no points are awarded. A useful game about communication and providing enough information. It comes with many expansions which can be seen when looking at the main link.

Quirkle

Quirkle is a cross between dominoes and the card game SET (See below).  You place tiles that meet a set of rules.  The tiles placed in a single line have to be either same colour, different shape OR same shape different colour.   You score double points for getting a set of six, a quirkle!  A great game but needs good lighting and a lot of space!  One of my current go to games for a bit of fun and lateral thinking skills.

Quirkle Cubes

Quirkle cubes takes that concepts of quirkle and adds a random element and the ability to use a different strategy.  Unlike the original quirkle you can now see other players hands and can choose on your turn to roll some of your cubes to change the hand you have. This version require a lot more thought about tactics.

SET

This seems to be the 'go to' testers game of choice.  A game of visual perception, where you have to find a set of three that matches the rules of the game.  A set is three cards where either the feature is the same or the feature is different on all cards. A feature is either colour, shape number or shade.

Fluxx & Star Flux

A card game of ever changing rules where the object is to have cards, keepers, that meet the goals.  However the goals can and do change along with the rules as well. I do have the board game version of this which is fun since the board changes as well as the rules and goals.

Fluxx Dice

Fluxx dice is an expansion for the fluxx card game which adds an extra dimemsion. By rolling the dice you change the draw and play rules every single hand. Adds a great new random dynamic to the game.

Ice Dice

Ice dice or ice pyramids is a set of dice and pyramids which can be used for a variety of games. The most common one for testers is to play Zendo. This game is where a master sets a rule and shows an example of the rule and an example that does not meet the rule.  The student has to try and work out the rule by building their own pyramids and ask if it meets the rule or not.  A wonderful deductive game to challenge the mind and expand the investigative skills of testers.

Colt Express

One of my favorite games at the moment.  Each player has a bandit trying to take loot from a train whilst avoid the marsh and other bandits.  Each player has aset of action cards that they select at random.  These actions cards such as punch, fire, move, steal and so on are player during a round.  A round has a series of turns.  Some of the actions are played face up for all to see and some are placed face down.  At the end of the turn section, the action cards are played one at a time and the action carried out for that player.  It is fun to watch as some thought goes into what actions to play depending on where your bandit is, however it never quite works out as your expect.  This to me has alot in common with coding, we create what we think works only to find it ends up in a big mess.  Highly recommend this game for all testers!

Blink

A fast paced game where there are no turns.  You try to place your cards down that match the play decks by matching either colour, shape or number.   The first to get rid of there cards wins.  An ideal game for improving your pattern spotting skills.  One of the reasons I got this game was based upon an article by James Bach - Quick Oracle - Blink Testing.

Frenzi

This card game needs a lot of space to play and can become very hectic.  All the cards are placed on the table and then they are turned to the other side, they are double sided cards. Each player gets a rule card which shows what they need to have facing up at the end of the round.  They could be looking for a color, number or shape.  The first round is colour, then shape and finally number.  A timer is set and everyone starts to turn cards over using one hand.  The aim is to have as many of the cards facing up that matches your own rule. This is a quick and face paced game where it quickly becomes manic! You need lots of room to play this game and it is based on quick visual perception.

Rory Story Cubes

Rory story cubes are little dice with pictures on each face.  The dice are rolled then the players one at a time pick up a cube and using the picture that is face up start to tell a story, they leave it on a cliff hanger for the next player to pick a cube and continue the story.  Once the last cube is selected the person who picks this provides an ending to the story. These cubes are great for creative play and improving story telling skills.

Story Wars

A wonderful game in which two teams battle it out to convince an impartial judge why their character(s) should win. They is magical lands, characters and special weapons to use.  This game is useful for those wanting to improve their influencing and convincing communication skills.

This is quite an expensive game at the moment, I picked it up in the USA for $15.   You can obtain a PDF to printout for free from the manufacturers website see here.

Disruptus

I have previously done an in depth review of this game on this blog spot. See here.

Dobble

A quick game of spotting the same item on a different card.  You place two cards face up and the first to spot the same image on both cards wins those cards.  A clever game where every card has an image that is on another card. What makes it tricky is the images could be bigger or smaller or rotated.  Another game that improves the visual perception of the players.

Loonacy

This is another visual percetion game where the players try to match one of the two characters in their hand with the game cards.  There are no turns and the first to get a match keeps goig until they have no cards left and are declared the winner.

Cubu

Cubu is an intense game of following a sequence of colours and numbered squares with the aim to get rid of all your cards before the other player does.  This game requires a lot of concentration to be able to workout which way would be best for your sequence and to throw a proverbial spanner in the works there are action cards which can force you to miss turns, pick up more cards and other actions that inhibit your chances of winning.




Monday, 30 March 2015

Tesbash 2015 - Workshop Day

I was fortunate to be invited as a speaker at Testbash this year and had a wonderful yet tiring time.  There were lots of community based activities alongside the usual presentations.  The following is based upon some of my notes taken during the event and from my ever fallible memory.

This year Testbash made a change and decided to have a day of workshops however before that there was a pre-Testbash workshop meetup.  Walking in there were many familiar faces and some new ones, it felt like meeting up with old friends.  At these kinds of events I try to make an effort to sit with people I have never spoken to or met before.  There is nothing worse than coming to a meetup for the first time and not knowing anyone or being too shy to talk to others.  Sometimes it can be intimidating for those who are new and seeing everyone engaged in conversation as if they have known each other for years.  

One great aspect of many testers is their ability to make friends and be quite social.  I sat with one group of people who had traveled from Glasgow which consisted of Paul, Christine and sorry I have forgotten the other ladies name.  The conversation centered on testing in financial organizations and trying to implement what they had learnt on the RST -  course they had attended that day with Michael Bolton.  We had an interesting discussion about starting small and expanding out to others and implementing by showing success.   I talked about my experiences in doing this and we agreed that to implement RST learning in big organizations can be daunting but possible.

After this chat I brought out a few games I by chance had in my bag.  We settled on playing Loonacy which is a simple matching game with no turns.  This is a fun game and Christine was really good, Paul not so good.   Then it was time to get my beauty sleep for the big day of workshops.

Building an Itinerary for Exploratory Testing - Karen Johnson

The first workshop of the day was by Karen Johnson called ‘Building an Itinerary for Exploratory Testing’.  This workshop was packed with content and to really do it justice would require a lot more than two hours.  I have attended previous workshops by Karen and always feel relaxed, her gentle style of teaching is amazing and she makes everyone feel inclusive.  This as a presenter is a difficult task to achieve and Karen is one of the best I have experienced.   In this workshop it was no different.  The first part of the workshop involved learning about three different techniques that can help you build up an itinerary for exploratory testing.   Karen started by explaining that sometimes we get stuck coming up with ideas for exploratory testing. Karen stated there are tools available that can help you generate exploratory testing ideas, such as personas, heuristics and tours. 
  
Personas:

The first tool/technique that Karen introduced was personas.  This is where you place yourself into a certain type of person or user.  Rob Lambert has a great article on using personas in testing.  Personas are a useful way to place yourself in to the mindset of somebody else and can provide you with different perspectives on how to test the product.   One key aspect of personas is that they should not just be a one line description; it should be a story about the person with some background information. 

A couple of tools mentioned during this part of the workshop for creating personas included the following:

Heuristics

Next up from Karen was Heuristics, mainly ones using mnemonics to help trigger test ideas. I have in the past found many of these useful when testing.  Karen mentioned she has a set of cards that contain a set of these heuristics and mnemonics.

These cards can be found on her website - http://karennicolejohnson.com/2012/07/testing-mnemonics-as-a-card-deck-v2/.  I created an expanded set based upon the idea form Karen - http://steveo1967.blogspot.com/2013/06/test-ideas-cue-cards.html

Another resource that Karen mentioned was the use of The Quality Tree Cheat Sheet -  by Elisabeth Hendrickson, James Lyndsay , and Dale Emery.

People found this one very interesting and useful

Others mentioned included:

During this section Karne mentioned Test charters and recommended the book by Elisabeth Hendrickson called Explore it - A review of the book can be found here: - http://steveo1967.blogspot.com/2013/11/book-review-explore-it-by-elizabeth.html.

In this book Elisabeth has a template for exploratory testing charters:

Explore (target)
With (resources)
To discover (information)·

Where:
Target: Where are you exploring
Resources: What resources will you bring with you
Information: What kind of information are you hoping to find?

Tours

The final tool/technique that Karen introduced was testing tours.  This is where you are given a scenario and then use this to guide your testing.  First up was Michael Kellys FCC CUTS VIDS tour - http://michaeldkelly.com/blog/2005/9/20/touring-heuristic.html
  • Feature tour: Move through the application and get familiar with all the controls and features you come across.
  • Complexity tour: Find the five most complex things about the application.
  • Claims tour: Find all the information in the product that tells you what the product does.
  • Configuration tour: Attempt to find all the ways you can change settings in the product in a way that the application retains those settings.
  • User tour: Imagine five users for the product and the information they would want from the product or the major features they would be interested in.
  • Testability tour: Find all the features you can use as testability features and/or identify tools you have available that you can use to help in your testing.
  • Scenario tour: Imagine five realistic scenarios for how the users identified in the user tour would use this product.
  • Variability tour: Look for things you can change in the application - and then you try to change them.
  • Interopeability tour: What does this application interact with?
  • Data tour: Identify the major data elements of the application.
  • Structure tour: Find everything you can about what comprises the physical product (code, interfaces, hardware, files, etc...).

This was followed by James Whittaker exploratory testing tours
  • The Guidebook Tour
    • Guidebooks for tourists identify the best hotels, the best bargains, and the top attractions, without going into too much detail or overwhelming a tourist with too many options. The analogous artifact for exploratory testing is the user manual, whether it is printed or implemented as online help (in which case, I often call this the F1 tour to denote the shortcut to most help systems). For this tour, we will follow the user manual’s advice just like the wary traveler, by never deviating from its lead.
  • The Money Tour
    • Every location that covets tourists must have some good reasons for them to come. For Las Vegas, it’s the casinos and the strip, and for Egypt it’s the pyramids. For exploratory testers finding the money features leads directly to the sales force. Sales folk spend a great deal of time giving demos of applications and are a fantastic source of information for the Money tour. To execute the tour, simply run through the demos yourself and look for problems. As the product code is modified for bug fixes and new features, it may be that the demo breaks and you’ve not only found a great bug, but you’ve saved your sales force from some pretty serious embarrassment.
  • The Landmark Tour
    • As a boy growing up in the fields, meadows, and woods of Kentucky, I learned to use a compass by watching my older brother. The process was simple. Use the compass to locate a landmark (a tree, rock, cliff face, and so forth) in the direction you want to go, make your way to that landmark, and then locate the next landmark, and so on and so forth. As long as the landmarks were all in the same direction, you could get yourself through a patch of dense Kentucky woods.
    • The Landmark tour for exploratory testers is similar in that we will choose landmarks and perform the same landmark hopping through the software that we would through a forest. Choose a set of landmarks, decide on an ordering for them, and then explore the application going from landmark to landmark until you’ve visited all of them in your list. Keep track of which landmarks you’ve used and create a landmark coverage map to track your progress.
  • The Intellectual Tour
    • I was once on a walking tour of London in which the guide was a gentleman in his fifties who claimed at the outset to have lived in London all his life. A fellow tourist happened to be a scholar who was knowledgeable in English history and was constantly asking hard questions of the guide. He didn’t mean to be a jerk, but he was curious, and that combined with his knowledge ended up being a dangerous combination … at least to the guide. When applied to exploratory testing, this tour takes on the approach of asking the software hard questions. How do we make the software work as hard as possible? Which features will stretch it to its limits? What inputs and data will cause it to perform the most processing? Which inputs might fool its error-checking routines? Which inputs and internal data will stress its capability to produce any specific output?
  • The FedEx Tour
    • FedEx is an icon in the package-delivery world. They pick up packages, move them around their various distribution centers, and send them to their final destination. For this tour, instead of packages moving around the planet through the FedEx system, think of data moving through the software. During this tour, a tester must concentrate on this data. Try to identify inputs that are stored and “follow” them around the software. For example, when an address is entered into a shopping site, where does it gets displayed? What features consume it? If it is used as a billing address, make sure you exercise that feature. If it is used as a shipping address, make sure you use that feature. If can be updated, update it. Does it ever get printed or purged or processed? Try to find every feature that touches the data so that, just as FedEx handles their packages, you are involved in every stage of the data’s life cycle.
  • The Garbage Collector’s Tour
    • Those who collect curbside garbage often know neighborhoods better than even residents and police because they go street by street, house by house, and become familiar with every bump in the road. However, because they are in a hurry, they don’t stay in one place very long. For software, this is like a methodical spot check. We can decide to spot check the interface where we go screen by screen, dialog by dialog (favoring, like the garbage collector, the shortest route), and not stopping to test in detail, but checking the obvious things (perhaps like the Supermodel tour). We could also use this tour to go feature by feature, module by module, or any other landmark that makes sense for our specific application.
  • The Bad-Neighborhood Tour
    • Every city worth visiting has bad neighborhoods and areas that a tourist is well advised to avoid. Software also has bad neighborhoods—those sections of the code populated by bugs. Clearly, we do not know in advance which features are likely to represent bad neighborhoods. But as bugs are found and reported, we can connect certain features with bug counts and can track where bugs are occurring on our product. Because bugs tend to congregate, revisiting buggy sections of the product is a tour worth taking. Indeed, once a buggy section of code is identified, it is recommended to take a Garbage Collector’s tour through nearby features to verify that the fixes didn’t introduce any new bugs.
  • The Museum Tour
    • Museums that display antiquities are a favorite of tourists. Antiquities within a code base deserve the same kind of attention from testers. In this case, software’s antiquities are legacy code. Older code files that undergo revision or that are put into a new environment tend to be failure prone. With the original developers long gone and documentation often poor, legacy code is hard to modify, hard to review, and evades the unit testing net of developers (who usually write such tests only for new code). During this tour, testers should identify older code and executable artifacts and ensure they receive a fair share of testing attention.
  • The Back Alley Tour
    • In many peoples’ eye, a good tour is one in which you visit popular places. The opposite of these tours would be one in which you visited places no one else was likely to go. In exploratory testing terms, these are the least likely features to be used and the ones that are the least attractive to users. If your organization tracks feature usage, this tour will direct you to test the ones at the bottom of the list. If your organization tracks code coverage, this tour implores you to find ways to test the code yet to be covered.
  • The All-Nighter Tour
    • Also known as the Clubbing tour, this one is for those folks who stay out late and hit the nightspots. The key here is all night. Exploratory testers on the All-Nighter tour will keep their application running without closing it. They will open files and not close them. Often, they don’t even bother saving them so as to avoid any potential resetting effect that might occur at save time. They connect to remote resources and never disconnect. And while all these resources are in constant use, they may even run tests using other tours to keep the software working and moving data around. If they do this long enough, they may find bugs that other testers will not find because the software is denied that clean reset that occurs when it is restarted.
  • The Supermodel Tour
    • For this tour, I want you to think superficially. Whatever you do, don’t go beyond skin deep. This tour is not about function or substance; it’s about looks and first impressions. During the Supermodel tour, the focus is not on functionality or real interaction. It’s only on the interface. Take the tour and watch the interface elements. Do they look good? Do they render properly, and is the performance good? As you make changes, does the GUI refresh properly? Does it do so correctly or are there unsightly artifacts left on the screen? If the software is using color in a way to convey some meaning, is this done consistently? Are the GUI panels internally consistent with buttons and controls where you would expect them to be? Does the interface violate any conventions or standards?
  • The Couch Potato Tour
    • There’s always one person on a group tour who just doesn’t participate. He stands in the back with his arms folded. He’s bored, unenergetic, and makes one wonder exactly why he bothered paying for the tour in the first place. A Coach Potato tour means doing as little actual work as possible. This means accepting all default values (values prepopulated by the application), leaving input fields blank, filling in as little form data as possible, never clicking on an advertisement, paging through screens without clicking any buttons or entering any data, and so forth. If there is any choice to go one way in the application or another, the coach potato always takes the path of least resistance.
  • The Obsessive-Compulsive Tour
    • OCD testers will enter the same input over and over. They will perform the same action over and over. They will repeat, redo, copy, paste, borrow, and then do all that some more. Mostly, the name of the game is repetition. Order an item on a shopping site and then order it again to check if a multiple purchase discount applies. Enter some data on a screen, then return immediately to enter it again. These are actions developers often don’t program error cases for. They can wreak significant havoc.

Once this was finished Karen then got everyone into groups and asked them to come up with test ideas using these techniques and tools to test a website or a mobile application.

Observing the groups it was interesting to see that some used mind maps to document their ideas, others used lists, and some created test charters using the template by Elisabeth Hendrickson and one group story to create user stories.  Whilst observing it became clear that many of the groups found the cheat sheet a useful tool for coming up with ideas whilst others found the tours a good way to come up with novel ideas to test the application. 

At the end Karen brought all the groups together to do a debrief.  During this part of the workshop many came to the conclusion that each of the techniques that had been introduced provided them with far more test ideas that they could have thought of without the techniques or tools. Some of the discussions focused on which technique people preferred with many having a presence for either tours or heuristics.  It was asked why people did not like the personas as much and the majority stated it was hard to come up with people for the sessions; however in their own contexts it may be easier.

To conclude this was a fantastic introduction to some great exploratory testing techniques given by an experienced and knowledgeable presenter.  The style of training that Karen used in the workshop was a calm and unassuming one which made everyone warm to her and the session.  If you get an opportunity to attend a workshop by Karen I would highly recommend you do so.

Creative and Critical thinking workshop

The next workshop I attended was the Games and Tools to Encourage Creative and Critical Thinking within Testing one.  When I say attended I meant presented.  I cannot say much about the workshop in terms of attending it; however I do hope people enjoyed it.

For more details of some of the content I wrote a series of article (seven) the first of which can be found here: - http://steveo1967.blogspot.com/2013/03/creative-and-critical-thinking-and.html

Some of the tools and techniques used during the workshop:

After this session I needed to relax a little and gather my thoughts so I did not attended the next workshop

Next there was an open session where we played some games.

I introduced the following games:


If you want to learn more about these games then if you see me at testing events let me know.

In the evening there was another meetup “Pre Testbash Meetup” where over 60 testers got together and chatted.  The best part of Testbash is not the workshops or presentation but the community feeling of these meetups.  I met old friend and found new ones.  Guna (https://twitter.com/alt_lv) was a shining star and someone who is fun to talk about anything not just testing.  We end up talking about my tee-shirt whichwas based upon the work by the artist Jenny Parks - http://www.jennyparks.com/.  In fact Guna tweeted afterwards about the artist, what a great memory! I bumped into many testers I had not seen in a while including Vernon ‘tutu’ Richards (https://twitter.com/TesterfromLeic), Danny Dainton (https://twitter.com/DannyDainton) Dan Billing (https://twitter.com/thetestdoctor) and many others sorry if I have not mentioned you.

One interesting person I chatting with who I feel is a future testing star was Emma Keaveny (https://twitter.com/EmJayKay80).  Her story into testing is a wonderful and emotional journey.  I do hope one day Emma will start a blog post and tell others her inspiring journey.  I am sure it will be an interesting read and contain colorful language. 

I did not expect this post to become so big so it has become two parts, the workshops and the key presentations.  Watch out for the key presentations post soon.


Tuesday, 6 January 2015

Update and Plans for 2015

I noticed that it has been awhile since I last posted on my blog, since then I have had an article published in Stickyminds about the role of Testers in Agile Environments.

The end of 2014 was a little bit crazy, I ended up in hospital for a few days towards end of November and only really started to recover just in time for Christmas.

So my plans for this year are in the short term get the next chapter of my book, about critical thinking,  completed.  Hopefully this is the year I get the book fully completed, when I first started writing the book I thought I would have had it completed within a year.  How wrong was I! I find writing the book to be rewarding and therapeutic but at the same time I put pressure upon myself to get it completed.  Once I have finished my book writing journey I will add a longer post here about the journey.

The book "The Psychology of Software #Testing" is available here.

I have other plans for this year including a few blog articles that I intend to complete,with the following provisional titles:


  • Code Coverage is Not Test Coverage
  • Note Taking and Cornell Note Taking
  • How We Learn (based on upcoming workshop for Lets Test 2015)
  • Asking the right questions


I will also be speaking at a few events this year.



I hope to see both new and old friends at these events and if you do see me please come and say hello.

PS - I will have an article published in Testing Planet Magazine soon on an alternative coding approach for testers.