Category Archives: Testing

conferences, Eurostar, mobile, Testing

Teaching Mobile Testing in the EuroSTAR 2015 Test Lab

Leave a comment

I was lucky enough to be at EuroSTAR 2015 last week. As well as presenting my experiences and thoughts about the future of Test Management, I also spent most of my Wednesday in the rather excellent Test Lab.

testlab4

If you go to EuroSTAR, or any other conference for that matter, and you don’t take the opportunity to do some testing, and talk and learn from people whilst doing so then I think you’d be really missing out. The Test Lab is a great place where you can just hang out with other testers, speakers and guru’s. It makes everyone really accessible. You can learn a lot.

testlab1

You can also get extremely frustrated trying to figure out the various black box machines, other testing challenges and even how you might go about firing a rocket from a tank.

testlab5

I did a couple of Mobile Testing sessions, the first for beginners and then the second one as a mob testing effort. We found lots of bugs – our app of choice for the testing was DrinkedIn (the drinkers LinkedIn – check, it’s a real thing and available for both Android and iOS :)).

testlab2

I had great fun teaching, and I hope those who came along to my sessions went away knowing a bit more about mobile testing. If you are at EuroSTAR next year then be sure to get along to the Test Lab. Hopefully I’ll see you there.

 

conferences, Presenting, Testing

TestBash – The Friendly Conference

1 Comment

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 🙂

The Condensed Version

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

The Long Version

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.

Lean Coffee

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.

 The Rapid Software Testing Guide to What You Meant To Say – Michael Bolton

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 🙂

What you meant to say

Bug Detection – Iain McCowatt

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.

Bug detection

 

Re-running the ‘Are you a mac or a PC? battle … for iOS and Android – Sally Goble & Jon Hare-Winton

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.

Mobile testing

 

What’s In a Name? Experimenting With Testing Job Titles – Martin Hynie

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 🙂

Why I Lost My Job As a Test Manager and What I Learnt As a Result – Stephen Janaway

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.

Myths and Legends of Software Testing – Vernon Richards

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.

Quality doesn’t belong with the tester! – Maaret Pyhäjärvi

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.

Getting Rid of Release Candidate Testing – Matthew Heusser

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.

Getting rid of release testing

Automation in Testing – Richard Bradshaw

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.

The Art of Asking Questions – Karen Johnson

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.

And the Rest

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.

testbash

Experiences, recruitment, Testing

A Testers Portfolio

16 Comments

portfolio

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?

Is it because more testers are 9-5’ers?

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.

Are developers more motivated to share their work?

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.

Do they have more to share?

I’d wouldn’t say so, it’s just what is shared is different.

Is it more difficult to build and maintain a body of work as a tester?

I think it is. Since testing is much less about creation then it does make things more difficult. But it’s far from impossible.

What could you do if you want a portfolio of work?

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:

Writing for Blogs and Magazines

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 🙂

Starting Your Own Blog

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.

Talking At Conferences and Meet-ups

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.

Sharing Your Presentations On Slideshare

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

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?

—-

Update

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:

  • Use Github to store useful resources. It doesn’t have to be code. Thanks to Alan Richardson for the link to this pentest example.
  • Test an OS project that is stored on Github – thanks Michael Bolton, and also @xrisfg.
  • Taking part in activities such as Weekend Testing, podcasting, etc – thanks Dan Billing.

And thanks to everyone who commented below. I’m glad people found the article useful.

Experiences, Exploratory Testing, practices, team, Testing

Experiences Of a Testing Bug Bash

5 Comments

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.

Session Based Team Testing – A Bug Bash

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.

Organisation

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.

The Bug Bash Session

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.

Retrospective

What Went Well
Charters give structure and prevent misunderstandings

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.

Hints and examples in charters are good

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.

It is good to have charters split by story

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.

Some of the bugs were fixed during the session

This clearly shows the value of group pairing for me.

What Could be Improved?
Make the charters simpler

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.

Make the process of splitting up the charters and recording who is working on each one, simpler

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.

People could swap charters halfway through the session to give multiple points of view

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.

Comments
Aim to do this for all large stories

This was great to see since it showed that the team saw the value in the approach.

Consider pairing

This will be our next step for the Bug Bash sessions. Pairing people up could help to add more value by giving multiple viewpoints.

Going off charter was a good thing

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.

Being away from the desk is a good thing

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 🙂

Conclusion

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,

reviews, Testing

The State of Testing Survey 2015

1 Comment
It’s great to see thatJoel Montvelisky and the team at Practitest are running The State of Testing survey again this year. Last year they had over 640 people answering, and this year their target is to go over the 1,000 mark, to get an even better picture about what is going on in the Testing World.

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?

conferences, Eurostar, Experiences, Testing

EuroSTAR 2014 – Day 3

1 Comment

This is the third part of my review of EuroSTAR 2014. You can also read about day 1 and day 2 in the previous posts.

Day 3

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.

wpid-wp-1418046411188.jpeg

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:

IMG_20141203_084836

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.

IMG_20141203_084845

Overall

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.

conferences, Eurostar, Testing

EuroSTAR 2014 – Day 1

1 Comment

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.

Prologue

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.

IMG_20141123_180430
The conference centre looked very impressive

I spent Monday sightseeing. As an ex Nokian it was great to see this 🙂

IMG_20141124_092610
Someone really needs to update their advertising…

Day 1

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 🙂

IMG_20141125_142120

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.

IMG_20141125_154005

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.

IMG_20141125_164205

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.

IMG_20141125_172402

Here’s my notes from the session.

IMG_20141203_084710

Then it was time to learn how to pour some Guinness 🙂

IMG_20141125_185014
Well we are in Dublin after all…