They did it again!!! Massive kudos to the organisers… AMAZING JOB :-)
Its such a shame that you can’t make it to every talk but with the continued growth of this event this has to be expected… So, if you attend in the future make sure you pick wisely, although there are plenty of opportunities to socialise and share…
Always return to common ground, in this instance MASTER!
Heather Reid – A Software Tester for 2 years. Her passion is helping the software testing community. She has written a book called "30 Things Every New Software Tester Should Learn". When she's not testing she's usually exploring or working on restoration projects.
Heather brought to us the wrongs and rights of mentoring pulling on her past and current experiences, how do you become a mentor whilst also learning how to test?
Being a mentor does not need to mean you are the most knowledgeable person in the team, you just need to be ahead of the person you are supporting, knowing where to go for help if you don’t know is sometimes enough.
It’s important to build up a rapport with your mentee, you are guaranteed to find something in common, this will help. It’s good to understand your mentees learning style because this may differ from yours. Use your retrospectives to find out what works for them, it could be reading a document, having a demo or even leaving them to work it out for themselves, so try to find that middle ground.
Heather mentioned that her mentee had gone away to understand some documentation and then retrospectively gave Heather a greater understanding, this is a brilliant example of how mentor and mentee can help each other rather than it being one-way traffic.
So, take a step back, don’t force your ways on them and you may also learn a lot from the process.
Luke Boucher – A Software Engineer in Test for 3 years before moving in to Change Management.
Luke wanted to assume that his next tester is always a psycho… What makes a handover good or bad?
At the point of a handover is creating a summary enough? Maybe that lacks important context, what about the other things we do such as demos, project overviews and going through a flow diagram of the system. All really useful for giving the lower level detail.
It’s good to keep documentation ongoing rather than having to complete it all right at the end of a project. This reduces the risk of you missing key information.
One thing to remember is there are many ways to give and receive information, as testers we should be good at this… right?
COMMUNICATE to understand how much or how little information they need to get started, ask for feedback and make it relevant.
Quote of the day goes to Luke “A psychopath shared is a psychopath halved”
Viv Richards – A Test Automation engineer at Vizolution, blogger and an active member in the local developer community. In his spare-time he enjoys teaching children to code as a CodeClub volunteer at a local junior school as well as bringing communities together to share skills and knowledge by organising local meet-up's as well as organising South Wales largest agile and developer conference.
Viv wanted to talk to us about visual testing, looking at why we automate tests, the issue with just manually testing and also give a brief introduction into visual testing.
I was so interested in what Viv was speaking to us about that I took minimal notes from this session but a couple of points he made:
We automate tests because they can be reliable and quick, saving valuable time but we have to keep in mind that this does not replace human observation, that said just having manual tests is not always accurate and is only really beneficial if the tests are only run once or twice.
We all agree that automated testing is not the silver bullet as when we hit issues it’s not always obvious e.g. we could be hit with browser compatibility issues, maybe page load speeds and wait times maybe required for certain browsers etc.
There are tools available to us, the use of automation to compare images against a base image, especially useful if the page is busy… Viv’s example was a where’s Wally image, highlighting that Wally can be found by automation much quicker than the naked eye… this was a great example to use.
Automated Visual testing is definitely something I’m going to research more as I see this has great benefits…
Jit Gosai - Has over 14 years Test experience working with a wide variety of companies from Mobile manufactures to OS builders and app developers. He is currently working with the Mobile Platforms team within the BBC to help identify their Test approaches and how the teams move to DevOps and beyond. Starting his career in development, Jit moved into the testing arena as part of his degree and found that it gave him a new angle on the industry. After developing his work and making a name for himself in the testing scene, he moved towards Development in Test to integrate both his passions.
Jit ran a session focusing on Risk Vs Value. Highlighting to us that the world is becoming a complicated place and as an industry we have no choice but to work much more agile than before, this means we have to pay greater attention risk.
As part of the session we had to build a tower to specific requirements, each iteration during the build he would give us more materials…
In the end we ended up with:
- 10 Dice
- Small piece of slate
- A Marble
- Blue tac (Quite a small amount)
The focus for us was around stable/ unstable components, we had to build a tower to a certain spec using all given materials. As you can see we had two stable components and two not so stable…
As you start to build the tower you become more aware of how to use the given materials, uncovering important information of how each component interacts.
For this session, the tac represents the tester, how can we use the tester to reduce the risk of the unstable components failing and essentially impacting the end user?
What could we do? wrap the tac around the marble and use that as an integration point for all components? Spread the tac thinly across all components?
Using stable components to protect unstable or less tested components may help you get the best out of the system.
Key take away for me was that testing is generally focused on problematic areas and taking in a risk-based approach is ok. Does it add value doing exhaustive testing against stable components or is it better to Highlight issues and focus your testing efforts against new or unstable components?
Having your product owners in on the conversation helps defining the requirement for maximum benefit without delivering something that adds no value at all.
A final note from me…
The Guys at the Atelier do an amazing job at organising these days, so I would always recommend you attend… its more than just talks and there are plenty of opportunities to get involved… It’s great fun too!
This time I wanted to use TestSphere to explain how I felt… So here goes:
The Bandwagon affect – In TestSphere terms this is seen as a big negative, I’m turning this on its head… jumping on the bandwagon of bad ideas and mistakes is a huge no no, but, the testing atelier is a great bandwagon to be a part of!
Curious – I’ve been a tester for 10 years because I just can’t help but be curious! There is always something new to learn about your software, you just don’t know yet…
User Friendliness – Not so much about what makes your application attractive, but what makes these sessions so attractive… Everyone is there to learn, listen and offer suggestions! A great group of known and unknown friends!
I can’t wait until the next one…