A great presentation from Katrina Clokie. Lots to think about from this one.
Here’s my notes.
It’s taken a while to write this. Not because I don’t have a head full of new ideas from TestBash but simply because it’s taken time to digest everything, put everything into a sensible order in my head, and come to come conclusions about the day.
If you hate long blog post then just read this bit
TestBash is great. It’s one of the friendliest conferences I’ve been to – people talk to each other, most people are really engaged in what they do, and it’s really easy to strike up a conversation with a complete stranger about something that you’ve seen or experienced. You should go if you haven’t already. Plus they video everything (and hopefully it’ll be online here soon).
Still here? Then read on….
I was lucky this year – I had the opportunity to speak again. Last time, in 2013, I was petrified. This time I’d spoken at a few more conferences and so I was altogether more calm and collected. From a personal point of view, one of the main reasons this was great was that it meant I focused more on the presentations that were on before mine. In 2013 I couldn’t tell you much about any of them. This time more of them went into my head
As usual I tried to write some mindmaps as the presentations took place. One great thing about TestBash is that there is only one track – and this means no difficult decisions about who to see, or annoying clashes. And from a presenters point of view it means you know how many people you will present to, i.e. everyone
So, here goes, my take on the day and what I saw.
If you come to TestBash and you don’t get up early and go to the Lean Coffee then you are really missing out. In fact more this time, there was also bacon I love Lean Coffee, it’s a great way for people to get together and talk about what interests the group. We had some great discussion on a variety of testing topics and the whole event was really well attended this year, with lots of tables full of happy testers.
Then it was time to head on into the main auditorium for a day of talks.
I started off trying to mindmap Michael’s presentation and then remembered why I don’t try and write mindmaps for Michael’s presentations There’s so much information that it’s much better to sit back, watch, and then wait for slides or videos afterwards. In this presentation Michael took us through a whole bunch of statements on testing and software development, then dissected them, put them into Rapid Software Testing context, then reassembled them to show what should have been said. There was some great stuff in there – watch the video from the TestBash website when it is available. If you want to see a very small mindmap then here it is
Iain always gives a good presentation and in this one he took us through bug detection, from the perspective of tacit and explicit knowledge, the work of Harry Collins, and Dual Process Theory. Click on the thumbnail to get a full sized mindmap.
Sally and Jon from The Guardian took us through an entertaining presentation about the differences between iOS and Android, and how The Guardian approach mobile testing as a result. There were some interesting points in the presentation, and I really liked the gameification in the presentation as well, even if it did end up as a draw Given more time then it would have been great to have seen some more detailed mobile testing information, but it was a fun presentation nonetheless.
Click on the thumbnail to get a full sized mindmap.
I’d not met Martin before TestBash but got talking to him at the tester meetup the night before. His presentation was fascinating and explained how he had experimented with job titles and the effect that it had on how testing and testers were perceived. The results he presented were really interesting and certainly made me think more about what job titles and names really mean. I’m sure we’d all like to think that being called testers is great and people will always accept the value we know we bring, but perhaps that is not always the case.
I didn’t mindmap Martin’s presentation. It was before mine
I spoke about my experiences of losing my job as a Test Manager. and shared my experiences of going through the transition. Being someone who now works in an organisation where there are no Test Managers meant that I was able to give my take on the future of Test Management, a future that I think does not, and probably will not, include the Test Management role in the way that it does today. I spoke about the changes that the organisation made in order to keep a focus on testing; things like test communities, a coaching role, and mentoring.
No mindmap obviously. I was busy If you’d like to see the presentation then there will be a video on the TestBash website but why not come and see it live? I’ll be presenting a longer version at both Nordic Testing Days and EuroSTAR this year.
The legend that is TesterFromLeicester confronted some of the myths that we all experience as part of testing. With added tutu gags. Vernon gave us some great ways of confronting common myths and challenging those who share them. Watch the video – it’s great.
Maaret gave a really interesting presentation on how she has tested in a team with one tester. She gave some great hints and tips, and explained how her approach changed as a sole tester, and how the developers also approached quality as a result.
Matt’s presentation really interested me because we’d gone through the same transition in the past year and so I’d seen the arguments for and against. Primarily it was the testers who were more concerned about getting rid of release testing, and so it was interesting to see Matt’s take. I also liked his presentation style, using no prepared slides but drawing them on a iPad as he went. Really unique and it worked.
Click on the mindmap to get a larger version.
Richard took us all through his experiences in automation. I found it really interesting that he had first tried to ‘automate everything’ before understanding more about the differences between checking and testing, and how automation should be used to add value to software testing, not ‘be’ software testing. I didn’t get the chance to mindmap Richards presentation so take a look at the video when it’s available.
We finished up the presentations with Karen, who sat on the stage and quietly and confidently gave us some great advice. She explained about how to ask questions, gave us a lot of really useful reading material, and explained in lots of details why asking questions in the right way is so important. You can find her slides on Slideshare and I’d really recommend reading them and following the links.
The 99 second talks were really great as usual. A real mix of topics, delivery styles and delivery. If you haven’t presented before then 99 second talks are a great way to get started and seeing so many new people up there and speaking was good to see.
Overall I love TestBash. It’s a conference that is so friendly. There’s lots of social events, it’s single track which means everyone sees the same presentations, and the lunch really helps to get people together. If you went this year then you’ll know how good it was. If you didn’t then why not? You should go next year. You won’t be disappointed.
You reached the bottom. Here’s your ‘prize’. TestBash makes people feel like this sometimes.
I’ve been recruiting for both testers and developers recently and one thing that struck me was the difference between the two disciplines when it came to a body of work.
As a developer you are nothing these days without a Github account. It’s expected that you have one, that it has code in it and that an interviewer will take a look. So much so that most developers will gladly advertise their account and repo’s on their CV.
In my most recent piece of testing recruitment I was looking for an exploratory tester and a tester with more automation skills. One automation tester was able to give me a link to her Github account; this was the first time this has happened to me when interviewing testers and was a positive thing to see. None of the exploratory testers I interviewed showed me any links to previous work; now this does not necessarily make those testers better or worse of course. However, as Rob Lambert has talked in his recent series of blog posts and e-book about ‘Remaining Relevant’, as a candidate, you need to stand out, and having a body of work can really help.
For testing it’s a bit different.
So this got me thinking – why is it that testers don’t traditionally have a portfolio?
There could be an element of truth here, perhaps there are more testers who are less motivated by their work, with testing being a job they have fallen into rather than a career. If one is not motivated by a job then one is far less likely to want to do whatever is required to remain in that career area.
Perhaps there’s a bit of pride in sharing something that one has created that testers don’t have so much. For testers involved in automation, particularly framework design, then there’s something to share, but this isn’t the more general case.
I’d wouldn’t say so, it’s just what is shared is different.
I think it is. Since testing is much less about creation then it does make things more difficult. But it’s far from impossible.
Myself and Dan Ashby touched upon the idea of a testers portfolio in the recent two episodes of Testing In the Pub, where we talked about recruitment. The idea is that, as a tester, you have this body of work, either built up through your day-to-day work, or from experiences in the wider testing community, that can really help you to stand out from your peers, and help when you want to make your next career move.
You may be able to directly share what you are working on at work, but this is frequently not the case. Getting involved outside of work can instead be one key way of building up a portfolio. For example you could consider:
Maybe your company has a tech blog. Why not write for that? Or magazines, whether printed or online are always looking for articles. Don’t think that you have nothing to write about – all experience is relevant and there’s some great people in the testing community who will help you edit an article. You just need the idea, and an ability to type
Sometimes you just want to publish something, or you want to say something that’s free from any editorial tone. Start your own blog, it’s really easy and free if you use something like Blogger or WordPress. It’s also great for raising your visibility, especially if you get your blog featured on sites like Software Testing Club or Test Huddle. Add it to the directories.
Have an idea, submit a proposal, get it accepted and then panic But seriously, talking at a conference is a great way of sharing your knowledge, raising your profile, and getting noticed. It’s daunting at first, slightly daunting even when you’ve done it before, but also really rewarding. Conference speaking looks great in a portfolio.
Whenever you talk, take time to upload your slides to a sharing site like Slideshare. This makes them available to all and makes you far more visible to search engines like Google. Which it turn helps you build a portfolio of work.
Pulling it altogether means that you build up a single portfolio. This can take place on your own website or blog and these are easy and free to put together. If you don’t mind a few advertisments then a free WordPress site is a great way to start and you can easily use a theme which makes it look more like a website than a blog.
I have also found that about.me is a good place to consolidate your information together and is widely known. Let’s also not forget about LinkedIn, although I find that it’s better to keep my body of knowledge linked to LinkedIn rather than on the site itself, which allows for more flexibility.
Having a personal brand is an often overlooked but very important differentiator when looking for a new role. It won’t make up for a lack of relevant technical or social skills, but it will help you to stand out from other, similar, candidates.
So think about your portfolio. What would you include?
Thanks everyone who has commented, either here or on Twitter. There have been some great suggestions on other ways you can form a portfolio as a tester. For example:
And thanks to everyone who commented below. I’m glad people found the article useful.
I’m working in a team, that’s developing a mobile application and back-end, that does not have any testers. We didn’t plan it that way, but temporarily, that’s just the way it is. While I can add my testing skills and experience to the team, that’s not the primary reason I’m there, and so I’ve been looking at ways in which the whole team can help to contribute to a quality product.
It’s been interesting. At first, when our tester left then nothing happened. Like nothing at all, tickets moved over to the ‘Ready for Testing’ column and there they stayed. Immobile, ignored and unloved. It was as if all eyes were to the left, where the fun stuff for developers was, understanding designs and coding. Although there are unit tests and some automated integration level tests for our code it clearly wasn’t enough.
I’ve used session based testing in the past when I managed test teams, and have found it to be a very useful way of breaking exploratory testing work into understandable pieces, and distributing that work out to the team. James and Jon Bach explain the approach far better than I can. Ministry of Testing have also got an excellent resource on SBTM.
Having read some articles from people who had broadened their approach then I thought I’d take the session based testing concept and roll it out to the whole team as a bug bash.
The key point for me was that any sort of session had to be fun. Initially I feared that not all the team were going to see the full value of such a session since it wasn’t development work per se, so keeping the approach light-weight was key. The ideas for our first bug bash had formed.
Getting away from the everyday work was important so the bug bash took place in a separate room, close enough to our team area that it was quick to pop out and pickup forgotten devices, etc but away from the interruptions that phones, etc provide. I made sure we had enough phones, tablets, post-it notes, pens and cake to keep us going. I also brought in some popular testing books and the Test Heuristics Cheatsheet from Elizabeth Hendrikson, in case people needed some inspiration.
We use JIRA as our project management tool and since we were testing a whole Epic then it made sense to break the testing down on a story by story basis. Working with our lead developer, we took each Epic in turn and used that to form an exploratory testing charter stored as a Google doc. You can get an example version here. Using charters enabled us to define the boundaries of the testing; ensuring there was not too much overlap. It also meant that people who were not so familiar with the story were able to quickly learn about it, and areas to test, without needing to spend time reading stories and Epics in JIRA.
So, the charters were ready, the room was ready and the people were ready. Time to start.
We decided on two 45 minute sessions with a tea break in between. The whole team attended; PO, designers, UX, developers and myself. Everyone was a tester for the afternoon. We agreed who would pickup which charters and made a start.
I made a Google doc in which people could record potential issues which I kept projected up on the wall throughout, so that we could all see the progress that we were making and the issues that were being raised. I encouraged the team to add screenshots as well as text and this really helped to make things clear and to prevent duplicate issues making their way into the list. Discussion was also key to the success of the session; having everyone in the room at the same time meant that potential design issues could be shown to designers straight away for review.
The lead developer for the feature was also present, not testing but helping to explain architectural and development decisions, and also to fix some bugs on-the-fly.
The session went well. We got all the charters finished and the session concluded with a quick retrospective.
Having structure was critical to the bug bash, given that it was a new activity for the team, and they were not experienced with exploratory testing. It also meant that we got the most from the session and people were not all testing the same thing.
By including examples, and ideas on areas to test, people had a guide to start them off. Given that they were not experienced testers then this really helped.
This meant that it was clear what was to be tested and there was a clear link back to the project management tool people were used to.
This clearly shows the value of group pairing for me.
I had hoped we would get some data on setup time and test execution time so had added that to the charters but it confused most people.
Although it as clear to them which charter a person was working on, we didn’t keep a visible record of who was working on what. Next time I’ll write this down and pin it up on the wall.
For each 45 minute session one person would pick up and test against a charter. Swapping round could add value and a new set of eyes onto the area.
This was great to see since it showed that the team saw the value in the approach.
This will be our next step for the Bug Bash sessions. Pairing people up could help to add more value by giving multiple viewpoints.
Some charters were bigger than others. People naturally started to go off-charter once their charter was done and this gave multiple viewpoints across the whole feature.
By being one team, with one goal, isolated from our day-to-day activities, we were able to effectively test and find many issues in the feature, without the usual distractions that break concentration and flow. Having lots of cake also helped
We will definitely do the Bug Bash again, and I see it as becoming a really important part of our delivery processes, even when we get a full time tester back on the team. It really helped everyone to understand the feature, to explore it and to test together, giving multiple viewpoints on potential issues.
With some guidance the whole team made a great contribution. I’d encourage everyone to try a similar approach,
Survey’s like this are really important to our community, as they give a view on where we are, our challenges and successes, and a great starting point for more discussion and potential improvement.
The survey is open and you can find it here. I’ll be filling it in, will you?
After a late night at the Gala party (well I had just presented at EuroSTAR so I reckon a celebration was in order) then I’m ashamed to say I missed the first keynote of the day. From what I hear it was good
My next session was ‘Stylish Mobile Testing’ with Dan Ashby and Nehir Yelkovan. I know both Dan and Nehir well – myself and Dan do the Testing In the Pub podcast together and I work with Nehir. So missing their presentation was not an option. I’d have gone along even if I hadn’t known them, the topic of the session being around mobile testing. It was a good session; they passed on lots of useful hints and tips on mobile testing and got a great double act going on.
After watching Rene Tuinhout talk about Passionate Dating for Testers (a talk I’d seen Rene do at the Romanian Testing Conference where it was just as funny), I settled down in the auditorium for the final keynote from Zeger Van-Hesse. My notes are below:
Following the keynote, and the announcement of the EuroSTAR 2015 chair and venue (congratulations to Ruud Teunissen and let’s hope we meet in Maastricht) then then there was a decision to make. Workshop or do-over session?
I chose the do-over session, an excellent idea from the conference organisers, whereby the attendees get to vote on what session they would like to see again. This year it was won by Declan O’Riordan. Declan has had a great year, after doing his first talk at SIGIST, straight after me in fact) then he’s spoken at a number of events and also won the best paper award at EuroSTAR this year. His talk about the ‘Why, Why, Who, How of Security Testing’ was in parts exciting, parts scary and really informative. A great final session.
This year’s EuroSTAR was a great event. It’s well run by a really passionate group, both the organising committee and the conference organisers themselves. The mix of speakers and topics meant that there was real variety and something different from last year. Congratulations to all who spoke, all who organised, and all who contributed in some way. I really hope I can make it back next year.
I didn’t know what to expect from this year’s EuroSTAR conference. I’d only been once before, and so I wasn’t sure how much a different programme chair and committee, and a new venue itself would make a difference to the EuroSTAR experience. In addition I had the added pressure of being lucky enough to speak at the conference as well.
Fortunately none of the changes made a difference. It was a great conference, with some excellent speakers, fun things to do when the talks weren’t happening, and lots of opportunity to meet old friends and make new one’s. Paul Gerrard, the programme committee and the EuroSTAR conference organisers did a great job booking a varied programme and a well organised event.
I arrived in Dublin on Sunday which meant that I was able to make it along to the early registration. This is a great idea which I hope happens next year, as well as being able to pick-up all the usual conference materials, T-shirt, etc early to save queuing, it also meant that those of us who had arrived early could easily get out and meet people. I had a great discussion with a couple of guys from Ericsson which brought back memories of my earlier career there. I was then lucky enough to bump into a number of people I knew as well. Dinner with Declan O’Riordan and Karen Johnson then followed, at which we had some excellent discussions about testing, contracting and life in general.
I spent Monday sightseeing. As an ex Nokian it was great to see this
Day 1 started with the keynote from Andy Stanford-Clark. I really enjoyed it and it certainly made me think more about the Internet of Things, and the challenge it causes for testers. And also how I could automate my house
I followed this up with Amy Phillips talk about Testing In the World of Start-ups. I’ve recently started working with a team who are effectively in start-up mode and it was very useful to hear Amy’s experiences from Songkick. The main thing I took away was that the testers role within a start-up is very different to a larger company, with a more varied skill-set required and potentially less actual testing. I feel this is the way that testing is going these days anyway, slowly but surely.
My next session was from Rikard Edgren who presented about Trying To Teach Testing Skills and Judgement. It was an excellent talk, dealing with Rikard’s experience of training testers. He’s also produced a white paper with a lot more detail, that I’m going to read.
The final keynote of the day was from Rob Lambert. Rob talked about Continuous Delivery and DevOps and gave us his experiences from New Voice Media. It was a good talk and built upon previous talks I’ve seen Rob do, giving more detail.
Here’s my notes from the session.
Then it was time to learn how to pour some Guinness
If you attended my workshop at the London Tester Gathering Workshops, then you may be interested to know that I have just posted the slides up on Slideshare.
If you attended the workshop and would like the other material then drop me an email and I’ll send it over to you.
Later this week it’s the London Tester Gathering Workshops. I attended this event last year and it was great. There was a brilliant variety of workshops, and a lot of great testers to talk to. Very recommended.
This year I am giving a workshop on Mobile Software Testing. It’s on Thursday 16th Oct and I have four hours in which to give an intro to mobile, and give the attendees the opportunity to try out some common mobile tools.
The workshop will focus on giving you a basic overview of mobile testing but then will focus on you discovering how to test mobile websites and applications using the tools below. It’s not a lecture and I won’t give you all the answers, but I hope we’ll have some fun along the way as we discover more about mobile testing.
If you are coming along then it’d be great if you brought with you:
If you haven’t got the Genymotion emulator then I will bring along a standalone version that can be installed for Mac or PC from a USB stick. But if you have already downloaded it then that would make things much smoother and you’ll have more time to use it.
There will also be a bit of a competition at the end so have a think about what application or website you might like to test. You’ll be able to choose anything you want
Hope to see you there.