Tuesday, November 15, 2016

SeleniumConf UK 2016 - Day 1 summary

As a first-time visitor to the Selenium conference (happening in London this year), I'd to summarise key points from my favorites talks. This is my interpretation so it may not be 100% accurate with the speaker's ideas.

Zen and the Art of Open Source Maintenance by Simon Stewart

Simon turned up to be not only a lead Selenium contributor but also a great showman. He was really energetic and funny throughout his talk and that gave everyone a lot of positive energy. Perhaps Selenium 3.0 release made him so happy? Or it was just us, the huge crowd ;)

My personal key points from the talk:

1. If you want to gain contributors for open source project you need to keep code simple. If you happen to complicate things too much, you are pretty much doomed to work alone.

2. Software Engineering is Human activity (slide below). If you want to succeed in any IT project (including open source) you need to focus on human collaboration. Everyone is different, everyone learns differently. Publicly recognise your’s contributors' successes and if something goes wrong fix it personally.

3. You need to have fun to succeed. Don’t forget about that. Remember my how to start learning test automation post

How to get automation included in your DoD by Angie Jones

Angie is a very confident public speaker and that trait plus her broad knowledge and experience made the talk really valuable. It ended so quickly (almost too quickly).

My personal key points from the talk:

1. Collaborate with other players - build common 'what we would like to do here?' understanding throughout your team first. Do not start until you’re absolutely sure everyone’s one the same page. Remind developers that their code should be testable (by adding element id's for example).

2. Automate strategically - always follow the test pyramid - start with the question: can it be tested on the unit test level? If not ask yourself: can it be tested on service (API) level? Only then start writing Selenium GUI tests.

3. Build incrementally - you don’t want to build a fancy framework for an unknown future. You can expand it further in your next sprint if that turns out to be necessary. Finish tests only for this sprint stories. Keep it simple.

Building a Test Engineering culture by Mona Soni

I liked this talk a lot because Mona Soni is not only a tester but also Engineering Leader in her company. This means that she’s the person who decides if it’s worth hiring test engineers. A lot of testers tend to ignore business/financial priorities and focus on ISTQB learnings instead. If you are such a person - watch this talk and make sure you're still employable.

My personal key points from the talk:

1. If you want to build Test Engineering culture everyone should responsible for the quality, not only Test Engineers. Forget about testers as a quality gate - this idea is dead. Do not expect your testers to magically improve everything.

2. Testers should expand their knowledge in different fields of Software Engineering to be employable. They should understand PO, UX, DevOps (or TestOps as I say it) responsibilities and actively contribute to them.

3. There is no easy way to Introduce Test Engineering culture into your company. You should start small and then expand. Mona Soni recommends three distinct stages which should focus on the following things:

Image is not very clear so I'll describe the slide:

a) Startup level - Testing (done not necessarily by Test Engineers, can be by the second developer), TDD, Data-Driven Decision & Feedback (you need to verify your ideas on actual customers and do not trust fully in your judgment - see my Lean Startup review for details), Continuous Integration, Frequent Releases

b) Average size company level - hiring first Test Engineer, weekly releases, Exploratory testing (manual), UX, Security, Privacy, Automated deployments (at least partially)

c) Large size company level - daily releases, Dog Fooding, Alpha/Beta releases, Monitoring & Alerts,   fully automated deployments, Outsourced manual testing

The Screenplay Pattern - a SOLID alternative to Page Object by Antony Marcano

I wasn't particularly impressed by most of the technical talks today, but Antony's presentation was most certainly an exception. There were not enough chairs in the room so a lot of people had to stand. 

My personal key points from the talk:

1. To be a good test engineer you need to write code. No exceptions from that.

2. Selenium isn't flaky, your test is. 

3. Page Object Pattern isn't perfect, mostly because they often break SOLID OOD programming principles.

4. There is a solid (and SOLID) alternative for Page Object Pattern called Screenplay Pattern.

A lot of presentation content can be found in this RiverGlide article which is highly recommended reading.

General conference thoughts

1. I like how an area with stands and food was separated from conference rooms. It really helped to overload the traffic jams which you probably remember from your previous conferences (busy people near stands who block movement).

2. I was a little disappointed with how lunch was organized. Not only it wasn’t a proper meal, but there was no separate area in which people can just sit and enjoy their food. Everyone had to stand and it from bowls.

3. Final Robotics Keynote by Jason Huggins was fun, but I'd personally prefer something more useful now, not exactly in an unknown future.