I’ve written about the Phoenix Checklist before here and think the list is so important that I include a quick reference on my site here.
I wanted to print the list out for quick reference at my desk so I decided to create a couple of mind maps. I like using mind maps for quick reference stuff. It suits my mind. I know of a few people who have taken the checklists, printed them and then laminated them. Good stuff.
Anyhow, here’s the mind maps I created and printed.
One of the things that strikes me about the book Running Lean
I really liked the way the author focused on the Lean Canvas idea for distilling and communicating ideas about your business. It sometimes felt overkill but overall it was useful and I’ve already seen some value from having a go at writing down my ideas.
The book also serves as a way of questioning your ideas about your business with particular respect to whether or not you have an audience that will actually buy your products.
For example the author, Ash-Maurya, states:
“Failing to build a significant path to customers is among the top reasons why startups fail”
Throughout the book Ash talks a lot about finding the right audience and the right product – it’s the basics of getting success in the market – but Ash also talks a lot about why it’s important to only build the minimum to satisfy this audience and market needs.
There is some talk about work in progress, Kanban boards and daily flow, but not enough to make it worth buying this book just for those topics. Instead, this book takes a more holistic approach across many functions and elements of a business so it glances over many topics but does give a nice wide view of running a lean business.
There are some interesting work hacks (i.e. – how to get stuff done) in the book also but again, there are other books with more depth in time management, productivity and work ethics.
I don’t believe this book is for those wanting a deep dive on certain areas of running a successful and lean business. Instead I believe it is for those who want an introduction and some techniques, tools and models to use to decide, plan and act on their business, and for this audience this book is very good indeed.
There are some interesting ideas and insights in to how to get continuous flow working in your business as well as ideas on how to ensure you’re best prepared to ship software.
I really enjoyed this book but I think that if you read around lean anyway you will already have gained most of these insights. Saying that, the Lean Canvas is a neat tool for helping you think about and organise your thoughts around your business. It can certainly help you drive out the audience for your business and some of the ideas around what it is you are offering and for what price.
Overall a pretty good book. Very well written too and great for those who are thinking about heading down the lean route or are looking for ways to optimise their existing business.
This review was part of the O’reilly blogger review programme.
Last week we had the pleasure of inviting James Lyndsay to our offices in rainy Basingstoke for a two day course on “getting a grip on Exploratory Testing”.
The whole test team were there for the two days and we worked through a number of elements of Exploratory Testing, right from time managements and focus to techniques and approaches. James is incredibly knowledgeable and his experience was tapped by the team for the two days.
Each of the team took away a number of insights, but here are my own personal observations:
The two day course was insightful, very well delivered and fun. There were lots of hands-on practicals and James tailored the content for our needs here at NewVoiceMedia. Overall it was a great two days and I know the team very much enjoyed it. We just need to put our learnings in to practice, something I am already seeing the guys doing.
One of the books that has made a big difference to how I’ve been thinking about teams, people and the dynamics that go on as people create software is a book called The Jazz Process
The book is written by Adrian Cho who both works in an agile team and plays Jazz, so he’s in a good place to talk about the parallels between the two. The book has slow points and low points, but on the whole it’s pretty good at explaining how teams can work better to produce good software.
In a bid to clear my house of books I’ve decided to give my copy of the book away to the person who gives me the most interesting answer to this question:
If you were to form a jazz quartet (that’s a group made up of four people) who from the Testing world would you choose and why?
Answers here please:
I attended the Agile South Coast Meetup last night in Southampton, the first one I’ve been to in about 3 years. It was good to meet up with the guys again and despite a small crowd it was an interesting evening. The first part of the talk was about change models and then the second part talked about how we could change the group and move it forward. I for one didn’t realise it was a group committee planning session but never-the-less some interesting discussions were had.
The group can be found on LinkedIn here and Twitter here.
Mike Williams kicked off the introduction followed by Plamen Balkanski who talked about making a difference using the change management 3.0 model by Jurgen Appelo.
Plamen talked about why we should make change happen?
He cited a prosci study 2009 which showed that teams that can change were successful.
Plamen also mentioned a number of excellent books about motivation, change and inspiration including Drive
How did we get here?
Plamen mentioned the three major changes in management
Management 1.0 – i.e Taylorism
Management 2.0 - same frameworks plus add on like, TQM and Six Sigma
Management 3.0 by jurgen appelo – which talked about Complexity.
Plamen introduced the following ideas from Management 3.0
1. Energise people
2. Empowering teams
3. Align constraints
4. Develop competence
5. Grow structure
6. Improve everything
He then moved on to talk about change management 3.0.
He talked about dancing with the system if you cannot control it. And then moved on to talk about the Deming Plan. Do. Check. Act framework.
Talked about the adkar model
- awareness
- desire
- knowledge
- ability
- reinforcement
He then talked about stimulating the network and the innovation adoption curve (initiators, innovators, early adopters, early majority, late majority, laggards)
He also then moved on to talk about the 5 i’s (Information, identity, incentives, infrastructure, institutions)
As you can see we talked about a lot of useful models and frameworks which were then put in to practice in the second half of the sessions as we worked through each model with reference to Agile South Coast user group. There were some good ideas generated for the future and how the group can move forward.
If you’re in the South region of the UK (Hampshire, Dorset etc) and interested in scrum, agile, lean etc then it’s worth joining the group and getting involved.
Imagine you are being asked to give an estimate for the completion of a piece of work. Imagine that this group includes Testers, Product Owners, Programmers and representatives from different departments. Imagine that you are going to have to haggle, negotiate and barter to get the time you think you need to do a good job.
Now imagine that I could give you a little trick that *could* help you get the number of days you actually want.
The above scenario is a common occurrence for many teams. We are often asked to give estimates for work.
Some teams use techniques like the Delphi method, rubbing the goat (don’t worry, it’s safe for work), like for like (same estimate as programmers) and a variety of other techniques. These are all valid and I’ve seen each one work; including the goat.
Now imagine this. As you are in the process of estimating you have the direct ability to dramatically influence what others agree on simply by shouting out a number (or holding up a number in Planning Poker (first round)). This number could be anything, but the more extreme the better (at least for this imaginary situation).
Simply by offering a number you have the ability to create an “anchor”.
I’ve been studying a lot about “anchoring” and how this relates to price and numbers. Anchoring is a bias (cognitive one) that occurs when people place too much emphasis on a piece of information. Michele Smith wrote a good blog post on anchoring and testing here.
So let’s look at this from a generic example point of view.
You are looking to sell something to someone. In this instance the price is not listed. You think this “something” is worth about £2000; that’s what you want to get for it.
So you throw in a crazy high price of £5000. The buyer laughs and nearly chokes. So you smile and say comforting words, then come back with a price of £3000.
According to much of the research in anchoring the above scenario would likely end in you selling this “something” for a higher price than if you had opened the pricing at £2500.
According to studies on pricing you have thrown in the anchor of £5000. It is now acting as a reference point in the buyers mind. Your offer to sell for £3000 now seems like a real bargain compared to the £5000. The same applies when buying. Go in low and then move up from there. This offer that no-one is ever likely to accept is curiously known as a “dead dog”.
When I read more around price anchoring I see this in everyday life.
You’ve surely seen the adverts:
“Was £100 – now only £25″
or “Reduced for a short time only from £100 to £25″.
In these instances the £100 is an anchor. The fact that the product might only be worth £25 anyway is why anchoring is used in the first place.
Another technique is to offer your products (with slight variants in deals) for different prices. One incredibly high price which no-one would likely buy and a lower price which is really what you want to sell your services/product for. In this example the research suggests that you will sell more of your “lower price” service because people are using the high price as an anchor. High end designer shops go mad with this technique.
Every day you are exposed to anchors in pricing.
So what has this got to do with Testing?
A lot really.
Going back to the example earlier, let’s say you want to get an estimate of 10 days to be accepted. So you throw in an estimate of 25 days and give a list of reasons why this might be a good estimate.
Lots of smirking, muttering and breathing in air through teeth. You sense the discomfort.
So you now go for an estimate of 14 days and give some reasons why you could achieve this and why this might still work for you. According to the anchoring theory it seems likely that this estimate could very well be accepted. In comparison to 25 it’s a good deal.
In a sense this is the interesting side of Planning Poker. The first round is intended to be called at the same time, for the very reason that anchoring plays a large influencing effect in estimation. Yet the first round can often throw in curve balls. Three people give 5 points, one person gives 1 point and another person gives 10 points. The second round often has people gravitating from their original number to either the higher or lower; a lot of this gravitation depends on the negotiating skills of the outliers.
A counter to anchoring is something called an Adjustment Heuristic which is essentially a mechanism we use to adjust to the anchor to get closer to our estimates/outcomes.
Anchoring is complex, complicated and very intriguing. I haven’t done it justice here, but it’s an area that I believe warrants a lot more reading about (and experiments). Over the next few months I’ll hopefully share some of what I am learning with you and no doubt fine tune my own thoughts on how anchoring plays a part in Testing.
If you’re interested then here are some resources on anchoring:
http://en.wikipedia.org/wiki/Anchoring
Priceless by William Poundstone
Short but interesting links from Behavioural Finance
Anchoring and Adjustment at Less Wrong
Photo by David Feltkamp on Flickr.
I’ve been using Google Books nGram a lot recently whilst I research some topics for blog posts, books, articles and other writing. It’s a great way of searching on a term and then finding related books. In fact, it’s so good that my impossibly large reading list has grown from 1498 books to 2200+. I know…I will never read them all, but I’ll have a good go.
So I thought I would share with you some of the graphs nGram created relating to Software Testing terms.
If you’ve never used nGram then head over to Google Books nGram page and have a play around. The year data it returns in the table at the bottom are clickable and will lead you to the books that mention your search term…let your expanding reading list begin 
nGram basically works by scanning millions of books for your search term and then providing you with a line graph of that terms use over time.
When you enter phrases into the Google Books Ngram Viewer, it displays a graph showing how those phrases have occurred in a corpus of books (e.g., “British English”, “English Fiction”, “French”) over the selected years. – from the nGram page
Here’s one for the term “software testing”:
(clicking on each image will show a larger one)
As you can see around the 1960′s and 1970′s the term really took off and has grown in it’s use through the last few decades.
Here’s another one, this is “test automation”
Again, the term really comes in to use in the 1960′s and grows dramatically, but interestingly it drops off in 2000. Did we see a drop in books about automation around then? Or did we start calling it something else? Or some other reason?
Here’s “quality assurance”. Same sort of trend as Software Testing and Test Automation
Here’s “exploratory testing”
Interestingly the term has been around for a while but when clicking through to search for the books you get some very interesting suggestions. Try the search and click through to the books from the 1800 – 1949 – some fascinating looking books.
“Test Management” sees a similar trend to “software testing”:
What about “boundary value analysis”
“performance testing” shows a similar growth:
“Usability” sees a later rise but the numbers show it was a growing topic of interest between the time ranges. It’s a popular topic now, but nGram only appears to go up to 2008.
You didn’t think I’d do all of these search terms without searching for “certified tester” did you?
Interestingly the term has been around for a while and in the early books it referred to various different roles and responsibilities, mostly associated with science, schooling and adjudication. It grew hugely in the 1980s, again mostly from schools and education before dropping greatly in the 1990′s – possible as school systems went through reform and as electronic marking and computers came to education. It took off again in the 1990′s and 2000′s with a load of books about ISEB and ISTQB certification.
This is pretty vague data but the beauty of nGram is the book search off the back of the term. Clicking through the dates you can grow a large reading list over time of how a term (i.e. idea or process) changes. It’s also a nice way to see what the historical trend in books is for a term. It doesn’t show me (at the moment) anything of significant value; we know the software development industry kicked off over the 1950′s, 60′s, 70′s and 80′s so it’s to be expected that there are growing numbers of books over this period.
But even though I can’t draw anything direct from the data doesn’t mean it’s pointless. I find it interesting, I like to stumble across new books, I like to play with tech and I like to find try things that might later down the line inspire new ideas for me.
Why not have a play around and see whether you can find anything interesting about Testing by using nGram.
One of the topics that always pops up in conversation with Testers is whether or not we need to know how to code.
I think a lot of this depends on your context and your career goals and aims, but really it pays to at least understand how the code is hanging together and to get a sense of what it’s doing. It would undoubtedly be useful to code at a basic level to help build tools and programs to help you and also to crack Test Automation (i.e. not relying on Record and Playback as your strategy).
I often hear the excuse that there isn’t time to learn, but I don’t think this is true. I think we could all snaffle 10 minutes a day to work on some code. The time argument depends greatly on the importance you place on learning to code. There are lunch times and after work and weekends too.
One of the things we’ve got set up within our team is two 30 minute sessions each week where the whole test team sit together and work through coding katas with our tech tester and programmer. It works really well but still needs each Tester to spend a little extra time each week re-enforcing the learning.
I thought I would collate together some resources that might help and inspire you. Oh yeah, and deciding which language to learn is often the hardest decision. I can’t offer any guidance on that really, it’s what works best for your environment, your product, your goals and your interest in each language.
So here are a few resources I’m finding helpful:
So you want to learn programming basics?
There are loads of resources for learning basic programming (try a Google search for it) but the one that stands out from the crowd is Code Academy. It’s a great interactive tutorial teaching you the basics using JavaScript as it’s main language. The lessons are short and the guidance is awesome.
So you want to learn Python?
Python is a really powerful scripting language and you would be surprised at how many of your favourite sites are running on it on the web.
There are a number of great resources available on Python but one of my favourites is this very straight forward guide called “The Programming Historian“. The lessons are kept simple and you’ll be writing Python to manipulate files and text in no time.
If you’re in a .Net environment then IronPython might be the way to go.
So you want to learn C#?
There is a pretty good course here at Programmer’s Heaven on C# basics.
CSharp-station also has some good tutorials.
So you want to learn Java?
By far the most relevant and intuitive book on Java for Testing is Alan Richardson’s “Selenium Simplified“. The guide is very straight forward and in no time you’ll have some tests running on your web site. It’s obviously aimed at getting you started with Selenium but Alan introduces you to Java as part of the journey.
Here is an introduction to Object Orientated Programming in Java.
Learn Java Programming with Green Foot. This is a really great program for learning about Java and Object Orientated Programming. You get to build a world where Wombats eat leaves. Great fun.
So you want to learn Ruby?
I would recommend to you dive straight in to Brian Marick’s excellent book “everyday scripting with Ruby“. It’s partly aimed at Tester’s so it’s a great read.
Ruby for Kids is very cool also. Don’t be put off by the title. The lessons are great and the basics can be learned very quickly indeed.
Why’s Poignant’s Guide to Ruby is a cult classic in the Ruby domain. It’s a crazy story that introduces Ruby and general programming ideas. I actually enjoyed reading this. It’s a PDF –> http://www.rubyinside.com/media/poignant-guide.pdf
Ruby in Twenty Minutes offers snippets of learning. A good resource for getting started and getting it all installed etc.
If you’re in a .net environment but still want to use Ruby then check out IronRuby.
Each of these languages is typically coded in an IDE (Integrated Development Environment) although you could also use something low tech like Notepad. A good list of IDEs is here on Wikipedia.
There are also other languages I’ve not covered here like PERL, PHP, C++ and many others.
Any other sources I might have missed? Let me know in the comments.
It was so great to be part of the Test Bash last Friday in Cambridge. I for one had a great day and I’m so glad that others did too.
The feedback we received about the event was great and it was clear from the vibe throughout the day that people enjoyed themselves, mingled and generally felt connected with others.
I’d like to thank the speakers for such an awesome day:
David Evans
Alan Richardson
Ben Wirtz
Steve Green
Huib Schoots and Markus Gartner
Adam Knight
Andy Glover
I’d also like to thank the attendees who brought such enthusiasm with them. Our sponsors MagenTys and QASymphony. And of course our community members who helped out on the day.
The venue was superb and the food delicious. Me and Rosie were more than happy with how it went and we were thrilled to see Twitter buzzing and of course, Markus Gartner live blogging*.
We ran the Low Tech Social Network throughout the day which brought people together to connect with those who shared similar interests and hobbies. I witnessed a number of people seeking out others with the same hobbies such as surfing and fast cars and then talking testing with them. That’s the point of it; connections to people you might not normally talk to. Fantastic to see this in action.
Test Bash is a celebration of connectedness, community, creativity, ideas and most importantly, the sharing of these ideas in a safe and trusted environment. We saw loads of good ideas being bounced around and it was amazing how many people felt safe to share and talk about testing openly.
It was also great to finally put a face to an online name. It was good to meet so many people I already knew in the digital world. It was also great to meet so many new faces. I only wish I had more time to chat testing everyone.
Events like the Test Bash fill me with positivity. They make me realise that Testing isn’t a battlefield of right versus wrong. Instead, it’s a melting pot of ideas; some better and some worse depending on what context they find themselves in. There were some frank discussions and opinions aired, but the collaborative nature of the event meant these discussions were constructive, useful and open for all to experiment with.
I didn’t hear the words “Best Practices”, there were no certification bashing, nor evangelism, discussions nor were there any discussions of “my way or no way”. It was a day of optimism. A day of hope for our often negative and frequently argumentative domain.
It was also a great day of learning and a great chance to get together to talk about what matters; new ideas for testing.
And this, in a sense, is what me and Rosie and our community managers work so very hard for. These moments where people connect. Where people share ideas. Where the craft of testing is pushed forward. Where there is real hope of a shift from “one size fits all” testing to a value driven activity across all stages of the life cycle.
Yet, throughout all of this I couldn’t help but notice something blindingly obvious; even within our own industry we have wildly different ideas about what testing is and who is in actual fact a “Tester”.
I don’t think this is a bad thing. In fact, I think it could be the most amazing part of what we do and who we are. We get to do what we think is right. We get to add the value we are employed to add. And that means we’re edging ever so slowly away from the long held stereotypes of Testing and Testers.
We get to nudge our craft towards the future we want for it. And that’s a pretty cool thing.
* There is no one in the business faster than Markus for blogging. I swear he had posted the final remarks before the speakers had even uttered them :
http://www.shino.de/2012/03/23/testbash-survival-of-the-fit-tester/
http://www.shino.de/2012/03/23/testbash-an-8-layer-model-for-exploratory-testing/
http://www.shino.de/2012/03/23/testbash-the-tale-of-a-startup/
http://www.shino.de/2012/03/23/testbash-the-evil-testers-guide-to-eeevil/
http://www.shino.de/2012/03/23/testbash-visualizing-quality-a-random-walk-of-ideas/
I’ve just finished reading Designing Data Visualizations by Noah Iliinsky and Julie Steele.
It’s a very relevant book to many as we strive to communicate the growing amount of data we are capturing. The book introduces the many different types of data visualisations including infographics and the use of charts, tables, graphs etc. The authors spend a lot of time explaining the reasons behind the visualisations which is very important, but often overlooked in other books. There is lots of information about colours, fonts, audiences and purposes and the channels used.
The authors support each piece of information with examples and external references, which adds lots of credibility to their arguments. There are some really insightful ideas and a lot of examples of good and bad visualisations which help make each point easier to understand.
It’s great that the authors spend time talking about colour blindness and the psychology behind colours, locations, shapes and proximity. I found this chapter incredibly useful indeed.
At times it felt like the book repeated itself, especially in the first few chapters. I got the sense I was reading the same information again, but thankfully the later chapters made the content more distinct.
Overall this is an easy to read and fun book that gives you the background, insight and tool ideas needed for you to get cracking with building visuals. Very good book indeed.
This post is part of the Oreilly Blogger review process.
