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.
What You Should Bring
If you are coming along then it’d be great if you brought with you:
- A laptop with:
- The latest stable build of Chrome on it.
- The Genymotion Android emulator.
- At least one device image (I’d suggest the Samsung Galaxy S5).
- As many mobile devices as you have.
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.
So it’s day 2. I’ll be blogging as much as I can, scroll down for the earlier sessions.
Dr Cheahan So talking about Why We Are Wrong When We Think We Are Right.
Next up – Peter Varhol, who is talking about Mobile Apps and the Role of Load Testing. Here’s my mindmap.
Stefan Gwihs and Philipp Strelka talked about the use of emulators and simulators in mobile testing.
Some interesting stuff, particularly about how a test approach should not be purely UI driven. My mindmap is here.
First the keynote. Unfortunately Daniel Knott couldn’t make it – fortunately he put his slides up on slideshare.
Everything is not lost – we have a new keynote – Mobile App Quality at Paypal.
The London Tester Gathering Workshops 2014 are nearly here. Last year I had a great time at the event – it had a really inclusive feel and I learnt a lot from the sessions that I attended.
My review is here, if you want to read about how good it was last year
This year I’m running one of the workshops. It will be about Testing Mobile Software, and promises to be a lot of fun (I hope).
Want to take part in a hands-on workshop and get an overview of mobile testing? Stephen Janaway will explain some of the common mistakes that are made when starting to test mobile, and will give you the opportunity to put into practice what you learn straight away.
We are increasingly moving towards mobile devices to fulfil our day-to-day computing needs. More smartphones are sold than PCs but many people are unclear on what changes to test strategies are needed when working with mobile.
We’ll spend a majority of the session testing a mobile application across a variety of platforms, and reporting the results in real time to the rest of the group. All you need to bring along is an open mind and as many mobile devices as you can get your hands-on.
Tickets are currently a bargainous £250+VAT until 19th September, and for that you get two full days of workshops, covering everything from mobile to automation, exploratory testing to creative thinking. Well worth it.
What are you waiting for? Sign up
Recently I’ve been reading Elisabeth Hendrickson’s excellent book ‘Explore It!’. For anyone who has an interest in exploratory testing it’s a must own. I wish I’d discovered it earlier to be honest, since it gives so many useful hints and tips, as well as confirming that the ways of working that one has chosen are also recommended and used by others.
As well as using it for my own learning, I’ve been slowly going through the book and working out what parts I can use in the regular lunch and learn sessions that I run at work. While we practice exploratory testing, in fact it’s the cornerstone of our sapient testing strategy, there are some areas where I feel we could take approaches that could benefit not only testing, but also the wider business.
Working With Legacy Systems
We frequently work with legacy systems and so one chapter that was of immediate interest to me in Elisabeth’s book concerned exploring an existing system. When one has an existing system to test I find it’s all too easy to become primed by what others have already discovered, and to fall back on existing test cases (whether physically written down or in someone’s head). This can bias you, resulting in less effective testing.
Elisabeth makes the point that an existing system may well be unknown to the tester, but also may well be unknown to the whole team, or at least contain parts that are unknown. While the software fulfils a business need, how it actually goes about doing so may be less clear. That makes it ideal for exploration.
James and Jon Bach like to call the initial exploration of an existing system ‘recon testing’. I like this term, by taking an initial session to explore and discover the basics of the software under test then one can then plan more effectively for future sessions, and write future charters in order to drive those plans (if you want to know more about the concept of session based testing and how charters fit in with this then have a look at James Bach’s explaination). Recon sessions help to map the territory and give insight.
During a recon session you can learn a lot, but the most important areas to ensure that you have gained insight into are:
- The ecosystem in which the software under test resides.
- Touchpoints to other systems.
- Variables (things we change or can change).
- Obvious vulnerabilities and potential risks.
Our Training Session
During our training session we carried out recon testing on the Staples ‘Easy’ button, and a standard service bell. This no doubt annoyed those in the room next door
By starting training with something simple, and not software based then it’s easier to pick up and learn the basics of a new technique without bias or the complication of software. We then compared our experiences, testing, (and the charters produced), with those that the Bach brothers produced when they carried out an exploratory testing exercise using the same product. Fortunately for us, their session is available on youtube, so it was an excellent addition to our de-brief. In it they explain the different testing techniques they use, and why. It’s well worth watching.
Enough Recon Testing?
One area to focus upon when conducting recon testing is whether one has conducted enough recon testing. Fortunately ‘Explore It!’ has this covered, recommending you ask yourself questions about the system that you have been exploring. If you don’t understand what the system does, how input and output works or how the environmental configuration affects the system for example, then it’s probably time to think about more recon before you move into more focused test sessions. Fortunately for the ‘Easy’ button and bell testers, (and those sitting near the meeting room where we had the lunch and learn), then this was not necessary
A Useful Addition
Recon testing is something that I think we’ll find is a really useful addition to our strategy. I’d certainly recommend that you check it out, and that you check out ‘Explore It!’ which contains much more useful information and techniques to use in your exploratory testing. I’ll certainly be using the book to inspire some future training sessions for the team.
I’ve just uploaded episode 9 of Testing In The Pub, the regular podcast about software testing which I record with Dan Ashby.
It’s the second part of an interview with Dan Billing about security testing. With security testing being such a hot topic at the moment then it’s well worth listening to.
Head over to the Testing In The Pub website to download, discover the RSS feed, or search for “Testing In The Pub” on iTunes.
Some exciting news – I’m going to be presenting a webinar at the EuroSTARonline Software Testing Summit on 16th September. The virtual, online, conference is free to attend and there’s some great speakers. You should sign-up. You really should
I’m presenting a talk about “The Current State of Mobile Testing” and answering questions afterwards.
I’m interested to know what people are most interested in knowing about. Have you just moved into mobile testing and want to know the basics, or are you a more experience tester who wants some detailed information about a particular area of mobile?
Are you starting to use, or already using, automation for mobile?
Are you testing phones, tablets, set-top boxes, smart watches or Google Glass applications?
If you want to play a part in helping to define what I talk about, and hopefully learn something that will really benefit you, then get in touch.
Episode 7 of the software testing podcast that I record with Dan Ashby is now available. In this episode we talk about the idea of ‘schools of testing’ and compare and contrast approaches such as those from the ISTQB and context-driven communities.
You can download it from the site, via RSS or it’ll shortly be in iTunes as usual.
I’ve been reading a lot about test management recently. There’s some excellent posts out there, in particular I’d recommend you look at this one from Katrina Clokie, explaining the changes that are required for test management to remain relevant in the world of Agile software development and continuous delivery.
She also links some other articles which I would definitely recommend you read, if you are interested in the subject.
- The role of the Test Manager in an agile organization – Johanna Rothman
- Changing the role of test managers – Gojko Adzic
- Test Manager’s Survival Guide to Going Agile – Joel Bancroft-Connors
So why am I interested? Well for starter I’m a Test Manager. Over the last couple of years I have seen my role change, from one of leading a separate, large test department, to one of managing testers across a number of project teams. It’s about to change again.
I’ve seen the challenges being a Test Manager in an Agile environment brings, in particular the difficulty in remaining relevant in the eyes of product and development managers, and the challenges of understanding enough about multiple areas in order to be able to support your team members. Being a Test Manager in a Agile environment can be isolating at times, particularly when the department is big, and the number of agile teams is large. It requires an ability to balance a lot of information, priorities, and tasks, across a number of areas. Stakeholder management and influence become key. Context switching comes as standard. Often it’s not much fun.
Through discussions with others, and looking at my own situation, I’m increasingly coming to the conclusion that the new ‘Agile Test Manager’ positions that Test Managers are moving/ falling into just don’t fit with the ways that teams want to work anymore. The team is more important than the manager, and, for example, choosing to keep discipline based management because it means testers are managed by testing ‘experts’ isn’t enough to justify it. Managers are not able to effectively support their people if they do not have the time and energy to keep fully in the loop with the team. As Test Managers get split across multiple teams, (primarily because having one Test Manager per Agile team is massive waste), then it becomes nearly impossible.
Moving to Continuous Delivery complicates matters further. Giving a team complete autonomy to design, build and release it’s own code is an extremely motivating way of working. Do Test Managers fit in with this ? I’m not sure they do. Where independence and autonomy are key, management from someone from outside of the team just doesn’t fit, particularly when that management is only part-time.
Change Is Coming
So how do we change? Do Test Managers merely become people managers, desperately trying to understand what their people, spread across multiple teams, are up to? Are they there to help manage testing but not people?? What about the coaching and mentoring, the sharing of knowledge and expertise, and the personal development of testers?
As I see it I think we’re going to see a lot more of this sort of setup:
- Engineering Managers, who line manage an entire team. They understand the people best because they work with them day-to-day. No need for handovers, no need for performance feedback requests to other managers at review time, and no need to waste time and effort with coordination. Engineering Managers manage the whole delivery process and people involved. They may have come from a background of expertise is a particular discipline, but now they need to be able to represent all. But crucially they are focused on the management of a team who own a particular product or component and so share a single focus with their team.
- Test Project Managers, who manage larger testing projects/ programme’s and dedicated testing phases such as UAT and customer acceptance. No people to manage, just deliverables. This role is very dependant on the nature of the software/ hardware solution being delivered. It’s most likely not needed in a lot of companies.
- Test Coaches, who help organisations deliver the optimum testing possible. This means through coaching, mentoring, advising and working with engineering managers and whole teams in order to help them optimise their testing effort. Similar to James Bach’s idea of Test Jumpers, but with more focus on providing advice, guidance and strategy. In smaller companies they are much more likely to be exactly like the idea of Test Jumpers. Call them Test Jumpers, Test Managers, Heads of Testing or whatever, but the key point is that they are test experts who have the mandate to support testers in multiple teams but do not manage them. They can assist with recruitment and personal development if required, but are not a particular person’s official manager, and may get involved more with recruitment and personal development process, rather than people.
The dedicated Test Manager, who manages testers and testing is not a role I can see continuing for too much longer. It is a hangover from the past, when large, dedicated test teams needed management, and it simply does not fit with how a lot of teams work anymore.
But, and this is a big but, I work in web, web services and mobile. I’ve seen the push for Agile and the push for Continuous Delivery because it fits the nature of the projects and technology used in these areas. Team’s are lean and projects are short. Almost certainly this makes me biased.
I would be interested to know what you think. Do you think the traditional Test Management role is reaching the end of the road? Or is it alive and well, and relevant in the area that you work? Why not leave a comment below and get the conversation started.