Thoughts: Test automation strategy

I am a bit behind the curve on this I am sure but the free platform Test Automation University by Angie Jones is pretty great. There even is a more high level short course on test automation strategy. I was super grateful for this, because of a few reasons which I will cover in a moment.

Why was I looking at the platform in the first place? Well we have objectives around test automation. (A discussion on objective setting and personal development plans could actually be a whole series. I still very much refer back to Stephen Janaway and what he wrote a while back on the subject and 1:1s. Read the whole series, it is great!)

Don’t assign objectives or tasks if the person doesn’t have time or isn’t motivated

But back to the objectives. Now it is pointless assigning someone an objective or personal development task when they are not motivated to act on it. If someone does not want to learn to code or cannot put in the time for whatever reason, then there is no point in them needing to achieve actually writing some code. At the end of the day we want our teams to succeed and feel like they are growing in their role. Now for some that is simply being a valued team member on their team. But we do like pushing people and letting them explore their role from different angles.

As a company approach we want to aim for continuous delivery where feasible (regulations), which means more automation. But not many of us can or want to learn to code.

So we decided to split our automation focus and take on the approach of not just doing but also understanding the whole approach. This is something I really liked about the automation in testing approach by Richard and Mark. It gives test automation another dimension because it no longer is about automating away testing tasks such as regression but also understand why you are doing it and what other things it enables you to do and how it supports testing activities.

Test automation is a whole team approach

Sometimes though these sort of words need to be in a course or some sort of material for people to accept it and listen to it. So finding Angie’s course on test automation strategy makes the whole subject of test automation way more approachable. Most of us testers lead scrum ceremonies or meetings. We have to be good communicators, so armed with some great questions from that course, anyone can help lead a discussion on a test automation approach to make sure it becomes a whole team approach.

Not being a coder can be such an advantage when designing a test automation strategy

Not being a coder can be such an advantage when designing a test automation strategy, not a disadvantage. I have seen people feel intimidated and scared but all the technical details, but being a functional tester often means you have a whole picture of the application and can really help the team automate the more risky parts of the application and the most valuable to the business.

I found that functional testers can easily feel less valued than the ones who can write automated tests and by also focusing on understanding test automation it made this objective a lot more approachable in my mind, and shows that you can still sit at the automation testing table, even if you cannot code the test. It might even free your mind. You don’t have a predetermined level of “automating that is hard so I won’t even go there” mind block. You are free to ask all the questions around what is possible and then is it feasible given the estimated effort.

So high level what do you need for a test automation strategy? Well watch Angie’s course. 😀

My summary of the first video with some of my own thoughts below.


A goal! What is your goal? This made so much sense to me. This can help you identify where are automation efforts are most value-able.

The most common goal I have seen is to reduce regression testing time. But here it can be important to then not jump to conclusions. Just because regression testing happens by manually clicking through the UI, it does not mean your tests need to do the right thing. Be clever about which layer is gets the automated tests and what your regression tests actually check and think about the least costly design that is most effective and build on that.

Brigh#Testactually and terrible UI tests

It’s been a big quiet here recently and this had to do with me changing job and trying to get used to a commute. Luckily our meet up didn’t suffer and thanks to the co hosts we had another great evening.

This time we had a talk on terrible UI browse tests in selenium and how to not write them in a terrible way.

 Rich the speaker, in my opinion made a great point that got me thinking a little bit further.

He mentioned the automation test pyramid and how at the top it always states UI tests. However what it actually means is end to end tests run through the UI that test the full stack of code.

You could even argue that end to end tests are a sub form of UI tests because really UI test do not need to be run against the full stack of code if you mocked the API calls and other third party integrations.

So the UI could be written with unit type tests from day one run on the CI server if it was a separated layer.

Do we distort the message of what types of tests we want at the top of the automation pyramid by letting us be boxed in by its shape?

I think we shouldn’t necessarily just put UI tests at the top. It should be end to end tests run through the browser. Is it just me that also thought UI tests have to take a long time, be brittle and use the full stack?

It hadn’t occurred to me that if we separate the UI layer and apply a few other tricks we could test just the UI fast and free up manual tester time even more to explore those edge cases.

Do you think we boxed our definition and understanding of what UI tests are in due to the shape of the pyramid?
The slides from Richs talk

Thoughts: Should Testers be able to code? – CodeBar Review

Excercise from the TestLab at Eurostar 2014

Should Testers be able to code?

Funnily enough this topic was just reinvigorated since I started to write this a few days ago. There is an interesting and in depth article here from Simon Knight and also an interesting perspective (that I share) from the designer community.

Why did I want bring this topic up?

Well I went to my first meet up organised by In their own words this is their goal:
“Our goal is to enable underrepresented groups to learn programming in a safe and collaborative environment and expand their career opportunities. To achieve this, we run free weekly workshops, regular events and try to create opportunities for our students making technology and coding more accessible.”

I decided to to go because my good friend and awesome tester Emma K (@EmJayKay80). said she was going and if she was going to sit on a 1 hour bus journey on one of the hottest days of the year I could do the 5 mins train journey down there. (that was my thinking and  my own kick up the butt to go).

How does codebar work?
Codebar holds their weekly Brighton meetup all over town, often in software companies’ offices which is also great from a nosey perspective! I love seeing other people’s work places.

The structure is that people turn up, mentors and students, and chat and mingle for half hour while eating delicious pizza (I think it came from pizzaface and was amazing.)

I was welcomed by one of the organisers straight away and introduced to people who were there already and then we got divided by subject. I decided to give Javascript a go and was at a table with 2 more students and 2 mentors. The mentors are really trying to give you hints and tips and explain the tutorials throughout the way and even give you real life examples which helps to make the learning less abstract.

I had an awesome time, learned a lot and will definitely go again!

Why do I want to learn to code/about code?

Now I am a tester by trade, a manual front end tester who only recently started along the way into the realms of API testing and performance testing. Why do I want to learn to code.

Mostly to aid my manual testing. If I can create throwaway automation or scripts to do stuff for me which will save me time and free me up to do more manual testing then I have won.

Also our tool of choice for API testing has been Postman which uses javascript to write assertions for example and I want to feel confident that I understand what these are doing and testing for.

Understanding or knowing about code, its quirks, weaknesses and strengths can help in test design, in my opinion.

The referenced articles also talk about empathy. Understanding what your colleagues do and understanding about their tools and therefore being empathetic can help the team work together better. I fully agree with this. Hence I also try to encourage developers to listen to test talks and share other literature around.

Currently we are moving towards a continuous delivery model and this means there will be an element of a testing consultant role that we as testers may need to fulfill as the developers will automate a lot of the tests and if I understand more about the code I can potentially advise more on what tests may be appropriate/relevant and ask the better questions.

Domain knowledge be it of the field we are in or the tools we are using is very important for testers to gather to be effective, in my experience.

But there is a fine line where testers may become bad coders and should we not just let the experts (programmers) deal with it? Also maybe you end up spending so much time with code at not do anything else?
I have certainly experienced this moment of “oh I automated this thing, now let me just do this other thing… oh it is 6pm and the office is empty and I haven’t tested the story that is waiting”. We can get distracted by new skills, and being a tester I can get quite involved in trying to understand something beyond the reaches of which I may need to, just because I am being nosey.

We currently are using the analogy of the swiss army knife a lot in house and it just so happens this is also echoed in one of the articles above.

We want to avoid to become swiss army knives as this means would have a lot of basic knowledge but do nothing particularly well or effectively.
However doing just enough (which will depend on your context) to understand some of the concepts of the coding languages your teams use means that you will share a common language and hence be able to communicate better.

In my context I am using a coding language for my API tests that I want to be able to understand a bit better. Hopefully with getting to grips with some of the concepts of using javascript and understanding its structure I can write better, more easily maintainable tests.

So in my context it would be advantageous to learn to code in some javascript, soI look forward to maybe seeing some of you at codebar Brighton in the future. 🙂

SpeakEasy: Thoughts: 3 things that bug me about “Agile Testing”

Sculpture made out of electronic waste at Eden project 2015

I re-started my speakeasy journey this month and in my conversation with Mark he just asked me to speak for 3 minutes on a topic. This was also part of re-living a bit of my fear of getting something wrong and feeling like an imposter. Who am I to have an opinion and one that people may want to hear about?

Mark made the talk easy by asking me something that I cannot get wrong as it was based on my opinion, still I panicked and stalled. This meant we digressed a little bit while I was trying to calm my nerves.

What he asked me was to tell him the three things that I do not like or agree with to do with Agile Testing.

Initially I was taken aback and stalled the conversation while trying to get my thoughts in order. In a way this is a skill itself, but should be practiced less like a deer in headlights, which is definitely what I did.

After I finished stalling I moved the conversation back to the three things that bug me and I surprised myself a little bit as well.

  1. The actual term “agile”. When you look it up it means to move quickly and easily. In terms of project management especially in the software world, this is rather subjective in my opinion. What is fast and easy for one team means something completely different for another, even within the same company! I think the term is misused and misunderstood. It also seems to appear in a lot of different industries now and I feel the actual philosophy behind agile testing has gone missing. By this I am referring to the manifesto which states “people over processes” etc. The incarnations of Agile Software Development I have seen have a lot of process and not so much focus on the people.
  2. Agile vs Context driven debate. I hate the fact that when we use agile as a term or definition of a process, that it is assumed you are the enemy of another school of thought. At the end of the day I see it like this: We are all aiming to do useful and valuable testing and we should encourage rational debates between ourselves, so we can learn from each other rather than segregate ourselves and shut each other out. I simply do not understand this. I would like to think I do testing in my day job, and I do not care what prefix you want to add in front of it “agile, context driven, exploratory, etc.” Maybe I am being naive here though.
  3. Automate all the things. Some people I have come across in my journey as a tester, have equated agile testing with automating all the things! They forget that manual testing is still a valuable process and that automation testing is a check rather than a test. A machine can only look for what you tell it to and it cannot think outside of the box. As a side note, if you manage to catch Richard Bradshaw speak at an event he currently has a great presentation about the pitfalls of automating All.The.Things.

So these were the three things I told Mark about. It wasn’t as scary as I thought to state my opinion. It is my opinion after all and it cannot be wrong per se, but it could be disagreed with. And I think I need to make that shift in thinking. it is not wrong, but someone else may think differently and I know I wouldn’t judge them on that.
Of course these statements can be elaborated on and expanded to make a better argument, but that is another technique I need to explore.

Next stop is facilitating a workshop and some learning at work.

Events: BrightTest Take 2 – BDD: Testing Requirements

Brighton Eye

Shameless brief plug about the next Brighton tester meet up.

This time all about BDD with a presentation by Alan Parkinson (and I think a game!).

Venue is provded by Rakuten Attribution and food and drinks by Crunch Accounting.

Hopefully see you there. RSVP Here.

P.S: If you want to speak in Brighton let me know. 🙂


We will focus on Behavioural Driven Development with a presentation by Alan Parkinson!

Beers, Soft drinks and Pizza sponsored by Crunch.


BDD – Testing Requirements

Many software projects suffer from a hidden requirements crisis. Theses are the projects where the client says “That’s not what I wanted” or testers discover functionality and business value problems after the code has been written. The common root cause of theses problem is miscommunication; these range from cognitive bias to different domain terminology used by stakeholders, business analysts, developers and testers.

Behaviour Driven Development (BDD) solves the problem by enhancing User Stories with examples called Scenarios. Each scenario is an example of how the requirement should behave in a real world situation, and aid communication by allowing the team members to ask questions to clarify the understanding of scenarios.

Alan will demonstrate and discuss the different causes of requirements miscommunication and how BDD can bridge the communication gap using examples.

Alan is CEO and Co-founder of Hindsight Software, a start-up focused on supporting BDD in the Enterprise. He has worked in the industry for over 15 years and in a wide range of industry sectors, including embedded real-time systems, safety critical systems, e-commerce, and Algorithmic trading systems.

He is a passionate believer in finding talented engineers and works with a “Do Tank” the New Engineering Foundation to influence the UK government and educational bodies on STEMs education. Alan is also involved in a number of open source projects including Karma, sbt and Cucumber-JVM



42 Frederick Place, Brighton, East Sussex, BN1 4EA


Turn up from 7pm.

Talk(s) start from 7:30 pm.


Venue: Sponsored by Rakuten Attribution

Food and Drink:

Beers, soft drinks and Pizza sponsored by Crunch Ltd.

Follow Up: Testing Strategies in a microservice Architecture

Me starting the walk along the Causeway

While pondering the future of how we will be developing and therefore testing we did a lot of research. I shared my first post about this the other day here.

I have since had a chat with Amy whose talk on testing in a continuous delivery world I mention here.
Re-reading that post and the chat with her gave me some great insights and I am trying to relay parts of our conversation below. (Thanks for taking the time for the chat Amy!) 🙂

To mock or not to mock

One of the my issues was the emphasis that was also pushed for internally that microservices will be tested in isolation, with mocking in place.
Whereas in my mind you want to be able to integration test your services and make sure they play nicely together in production BEFORE they are live.
So how can we create end to end tests that touch as much of the stack as possible and do not mock most of it?
And if we do need to resort to mocking why?

Our reasons for mocking would be two-fold:
1. Cost: cost of resources during development may mean we cannot have all services that may talk to each other up and running at once.
2. 3rd Party Applications – Need for integration with 3rd party software which we do not have sandbox environments for, hence this would need to be mocked.

Amy shared a great question with me which I really need to use to help us decide on where we invest in front end automation tests and where we don’t.
“What must never break vs. what can we break as long as we fix it quickly?”
This helps her team to decide what needs testing vs monitoring.

Keeping the business happy and keeping devs happy

As a tester we can find out who is worried by frequent releases and find out what it will take to make them less worried and base some tests around these worries as well.
Understanding your business’ needs is key.

But not only that, do not neglect the dev team. What annoys them? Slow build times, maybe? Can providing them with an SSD help? (I know we are lobbying for faster machines).

Be careful with metrics

Metrics can be useful but be careful how you use them. This was also a theme at the Lean Software Testing course I attended and wrote about here.

Production bugs will always be a good measure to see if your tests are in the right place and providing the value you hoped for.
If too many bugs get out into the wild then you need more tests (at some level).

At the beginning of transitioning to a service oriented architecture manual testing may be quite intensive because you need to start building confidence in the product and the tests that are being run.
Once you have a reasonable number of tests running then you’ll hopefully find fewer bugs during manual testing and can relax a little.

I have some action items from the chat:

  1. Find the key people, assess what worries them about releases and how to provide them with confidence of the release process
  2. Push for unit and integration tests
  3. Push for more manual time to begin with and then define the key journeys for selenium tests to be run against.

EDIT: Since the conversation this great post has appeared. A real world story about Microservices. Which ends with what sounds like a change of heart from Martin Fowler.
“…my primary guideline would be don’t even consider microservices unless you have a system that’s too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don’t try to separate it into separate services.”
So we will see where we end up in practice! But for our proof of concept I have a lot to do right now!

P.S: There is Brighton Tester meet up on the 27th May about BDD with free food and drink! RSVP here so I can get enough! 😉

TestBash 2015 summary

The first time I went to TestBash was in 2013 after discovering that testing is a great job and can give you a career, and has an amazing community around it.

On a random side note, at 7am I got hit by bird poo for the first time in 10 years! I knew then that it will be an awesome event, it means luck being hit by bird poo, doesn’t it?

The conference was being held at the Brighton Dome for the third time, and I like the venue. It has some great mingling spaces.
What is special about TestBash to me is the community feel. There are so many social events around the actual conference, giving you the chance to meet many testers. This mean that on the actual conference day you already know at least 1 person and do not feel anonymous,
which can be the case at some of the other conferences.

The other thing that sets TestBash apart is that it is a 1 day, 1 track event. So everyone you meet will have been at the same talks and you can really discuss the topics among yourselves. This is great for introverts like myself, because you are unlikely to run out of conversation topics.

The Talks:

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

Michael opened the conference with a great talk about how we and businesses communicate about testing and software development. I have a keen interest in linguistics and communication styles so if you do, watch the video!

Bug Detection – Iain McCowatt

Ian did a great presentation last year and didn’t disappoint this year either.
He focused on the impacts of tacit and explicit knowledge when finding bugs.
I have read a lot about tacit knowledge recently, and found it really interesting to have this applied to finding bugs.
It also made me realise how important it is to have a varied team of developers and testers, as everyone will apply their tacit knowledge to the software development lifecycle.

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

Next up we had Sally and Jon from The Guardian with one of my top 3 presentations of the day.
Personally I have not been involved in mobile app development in my career and loved the insights they gave us on how different it is to develop and test for Android vs iOS.
The gamification element of their presentation added a bit of fun as well.

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

Martin did a very interesting talk, both in terms of content and visually. Have a look at the slides to know what I mean!
His presentation was the re-telling of an experiment he did at his organisation around job titles and how the businesses’ attitude towards his team changed (for the better) when they removed the “tester” label.
In a way this was a sad outcome, because the business clearly did not try to understand what testers really do and how they can contribute in a team, until he changed their job title away from “tester”.

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

Stehen was up next! His talk focused on the dynamic of internal development team structures and what did not work at his company and how it improved.
I have been building up a test team at my company Crunch Accounting for the last year and hearing Stephen’s talk was a relief that I could be doing things right.
He outlined the changes his organisation made to create a better working environment inside of the development teams without losing the testing team feel.
These included trying to build an internal community around testing by coaching each other in testing techniques, sharing blogposts and creating mentorship roles instead of manager roles.

Myths and Legends of Software Testing – Vernon Richards

If I remember correctly Vernon’s talk stemmed from his 99 seconds TestBash talk from the year before!
He expanded his 99 second talk well and gave real life examples on how to address software testing myths and challenge colleague’s perceptions of testing.
I found this really useful, because the real life examples that Vernon gave can easily be applied and I am sure many of us have heard them as well!

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

The message from Maaret’s talk is one I find to be very powerful. “Quality is the team’s responsibility!”. She outlined a project where she had been the sole tester and her journey in convincing the team that they can all work towards better quality products. Some of those tips will definitely come in handy for me in the future.

Getting Rid of Release Candidate Testing – Matthew Heusser

Matt’s talk fitted in well with his workshop he did a couple of days before. My review of his Lean Software Testing Workshop is here.
He had an interesting approach of using what looked like the program paint to give his points a visual element.
The main considerations for release testing were outlined to be risk and quality. His argument was that with more frequent releases, the changes to a product will be smaller and hence the risk will actually be lower in the end. I recommend watching this one as Matt has a specific style of presenting and it really gets you thinking about the problems and solutions.

Automation in Testing – Richard Bradshaw

Richard shared with us his journey in automation testing and the things he had learned along the way. I particularly loved the point where he realised he had automated “all the things” and therefore was wasting his time maintaining his tests rather than getting good information from them. This is a valid lesson to learn very early on, although I do still find that I tend to over automate my regression tests, due to fear of missing something. To paraphrase Richard, automation should add value to other test activities rather than be the sole element of testing.

The Art of Asking Questions – Karen Johnson

This was my favourite talk of the day. Karen shared with us how factors such as timing and tone can have a real impact on what sort of answer you get to your questions.
I could definitely relate to choosing the wrong timing to ask a question and being cut off or just ignored.
There were some great audience questions around asking questions in writing, ie. via e-mail, rather than in person. The main tip was to keep the e-mail short and concise and to consider your audience.

99 Second Talks

Unfortunately I missed this years 99 second talks but the idea is that you have 99 seconds to talk about anything testing related.
Previous years have seen serious topics, funny topics and even interpretive dance and poems!
The 99 second talks are a great way to experience what it is like to stand in front of an audience and do a talk and it has even been a platform for quite a few testers to do more public speaking and be invited to the conference! I do love that TestBash gives everyone the chance to share in this way as it removes the “speakers are Gods” elements, because you can go and stand on the stage yourself.

As you may be able to tell the conference’s program this year was very varied and engaging.
The event finished with a great after party at a local pub. There was a separate area for all attendees and the venue was comfortable.

TestBash is an amazing event to meet like minded testers, learn from each other and refresh your passion for testing. I highly recommend it!

If you missed it the videos are now on the Dojo. More info here.

Thoughts: Testing Strategies in a microservice Architecture – takeaways and reflections

“The Causeway”

This post based on some research we did about hypothetically moving to a micro service architecture/soa. 

This first post is a reflection on an article by Martin Fowler.
My personal problem with these testing approaches to a micro service architecture  is that a lot of it is automated and in isolation. Automation is good as it allows us to make sure we are building the code right but we need manual testing a lot earlier to make sure we are building the right code.
There are many benefits with this approach such as the ability to independently deploy, scale and maintain each component and parallelize development across multiple teams. However, once these additional network partitions have been introduced, the testing strategies that applied for monolithic in process applications need to be reconsidered.

Testing Pyramid – How to focus the testing effort 

This is actually not that different from other automation test strategies I have read.

Aim to provide coverage at each layer and between layers with the challenge being to stay lightweight.
The first three layers are best tested in isolation where possible. Component and integration tests may need to call on other services but these can be stubbed to keep tests fast and maintainable. 
Any external service that is out of the team’s control should be stubbed/mocked in order to test failure scenarios.
One key characteristic in this type of architecture is graceful failure! The system must fail gracefully as it is prone to fail in many places.

Testing micro services in isolation:
Fast feedback as no end to end test.
Controlled environment – minimizes moving parts
Unit tests can help to identify areas which are too coupled as the unit under test needs to be isolated from its collaborators.

Resources for testing:
Expose internal resources such as logs, database commands and metrics to be able to test the system from another layer

Business value not achieved unless it is proven that many services work together to fulfill a larger business process, so testing in isolation will not suffice.

End to end tests:
Automate end to end tests using the GUI and API as well as perform manual end to end tests. But external services may still need to be stubbed/mocked. Due to more moving parts the system is likely to fail, so write less end to end tests at GUI level to avoid expensive maintenance and feedback times. Are these story acceptance tests?
Need to define a time we are happy to wait for these to give feedback – 5 mins?
Best tests would be data independent – not relying on any data to have been set up as this makes the tests more brittle
In which sort of environment do we run these tests? Is in production with a feature toggle feasible? Do we keep a production like environment running with the downside of double the overhead to technically have 2 live environments?

Exploratory manual testing:
These are manual tests that are performed with a mission statement in mind, they are session based ideally; time boxed from 45 to 135 minutes. What sort of environment is feasible for exploratory tests? Production environment with a feature toggle?

Have you solved the conundrum of testing micro services sufficiently in a continuous integration world? Please send me any resources or thoughts! Would be very interested to read them! 🙂

Events: BrighTest Summary and the next event

Just over 1 week ago we had our first BrighTest Tester meet up with actual talks!
The event went really well and I wanted to thank everyone involved.

The Past Event

Dan started the presentations talking about the emotion of fear and how it holds us back in our lives, but it doesn’t need to. We can use our fears, face them and learn from them.

The more you know about something the more rational it becomes, and is not as feared. The biggest fear there is is the unknown after all.So what do you fear?Have you tried to overcome your fears before?
The link to that research is here.

We started a thread on testhuddle where you can discuss if you like. 🙂
We then moved onto the load testing tool gatling with a show and tell from Jack (he has now social media accounts). He explained that we chose a 1 second response time to aim for on the website with less than 1% error rate. The discussion afterwards was great and we had a comment that actually just because something response fast it does not mean it feels right to the user, so do not forget usability!
So it was a great night! Please continue to talk about fears and load testing here and also feel free to give us any feedback! :)
Pictures are on our Facebook page.

The Next Event
Next we will have an event in the centre of Brighton at Rakuten around the subject of BDD. This will be on the 27th May. Hope to see you there!
More info here.
If you want to sponsor let me know. 🙂

1 week to go til TestBash 2015

Bench at Shoreham Graveyard March 2015

One week left until Brighton’s one day testing conference kicks off!

This will be my third time that I go to TestBash! It has a great atmosphere and everyone is really nice and helpful!
As always there are tonnes of meet ups happening around the event and a few workshops beforehand as well!
Actually for the first time there is a day full of them, 3 tracks!!!.
Everything you need to know has been collated here, so I won’t bore you with it.

You can find me at Lean Testing on Wednesday, then the workshops on Thursday (probably BDD, followed by the Jmeter course), and then at TestBash of course on Friday!

I am going to try and make an appearance at the meet ups also, but unfortunately I am moving out of my house and will have to clean it during that week! Timing, eh?

What am I hoping to get out of the events this year? Well, several things!

1. I am now a Test Lead, having built a team from scratch, that I am very happy with! So I want to share experiences of recruitment, the success and the failures.

2. Discuss topics of continuous delivery and test strategies in a continuous delivery world.

3. Learn about BDD and how it can help a company improve their knowledge and requirements of a product.

4. Pick everyone’s brains about API testing!

5. Meet and network with people from all over the world! Yes you heard correctly! This small local event attracts people from all over the world!

6. Take some great pictures of the testers that make these events so special and rewarding!

7. Share my learnings after the event via the blog and just by talking to people. 🙂