Founder and CEO of @TentamenHr. Organizer of Zagreb Software Testing Club meetups.
1207 stories
·
0 followers

Pay To Speak - why care and other collected thoughts

1 Share
I hold a strong belief that the world of conferences needs to change so that it is not #PayToSpeak. This means that while you are not necessarily making money for speaking (that should happen too), you are not paying money out of pocket for speaking.

Recently I spoke at a big conference that has no call for proposals but invites all speakers and says to pay their travel, including the following weekend's hotel nights to enjoy the beautiful city the conference is at. They have a policy of checking in with them on bookings or them doing bookings for you. So when they did my bookings for flights, they had me leave home 3:30 AM and return home 2:00 AM. That meant no public transport available to the airport. I could drive and park there, or I could take taxi. I chose the latter as cheaper option. When I arrived after 8 hours of being stuck on travel for something that would be a 2 hour direct flight, I had a taxi pick me up. However as I needed to get out immediately after my scheduled talk to still almost miss my flight, I had to find (and pay) the taxi myself. The flight tickets did not include any luggage, so I ended up paying 80 euros just to bring my stuff with me. Packing so that I can take it all inside means compromises on cosmetics I would rather not do while having to feel presentable. That's one of the women's problems, I guess.

The extra costs totaled to 180 dollars, which was more than the cheap flight they found me. Their view was that they wouldn't pay and that was yet another nail in the coffin killing my speaking willingness. Now it looks like they might pay, but I believe when the money is on my account.

So being against #PayToSpeak means that I believe that while it is reasonable to ask speakers to be considerate of costs (no business travel), it is not reasonable to optimize in ways where you just transfer the costs to them.

To be clear, many conferences are #PayToSpeak. Most in fact in the field of testing. A little less in the field of programming. A little less in the field of testing now that we are getting to a point of being respectable industry (including automation).

Why should the conferences care?

We've seen examples like Selenium Conference moving away from #PayToSpeak. The results they report are amazing.

  • 238 % increase in number of submissions - there are a lot of people with great content that cannot afford to teach in conferences that are pay to speak
  • new subjects, new speakers, new nationalities and new perspectives - all valuable for us learning in the field
  • percentage of women submitting growing from 10% to 40% - showing that the pay to speak might disproportionately impact underrepresented groups ability to teach in conferences

Surely you don't mean that we should pay newbie speakers?

I find that #PayToSpeak conferences present their audiences three groups of speakers:

  • Those so privileged financially that paying isn't an issue
  • Those with something to sell so that their companies pay them to deliver a sales pitch in disguise. Some better disguised than others. 
  • Those dreaming of public speaking experience finding no other options but paying their woes, sometimes delivering great talks. Believing paying is temporary. 
I believe that people in first category can opt out of payments in a conference that pays the expenses. In my experience they rarely do opt out on the out of pocket money, but many have opted out on profit sharing to leave money behind to support new speakers. People in the second category might become sponsors and pay more than just expenses to attend, and have their sessions branded as "industry practice / tool talks" which is often a way of saying it's selling a service or a tool. 

The third category is what makes me sad. 
This should not be the case. We should pay these speakers expenses. Our audiences deserve to learn from them.

As conference organizer, the thing I'm selling is good lessons from a (insert your favorite positive adjective) group of speakers. There are other ways of managing the risk of bad speakers than making sure your audience only gets to listen to the financially-well-off-and-privileged segment.

You could ensure the speakers with less of reputation get support and mentoring. With things like Speak Easy and folks like myself and Mark Dalgarno always popping up to volunteer in twitter, this is a real opportunity for conferences as well as individuals.

For Profit and Not For Profit

Finally, these words don't mean what you think they mean around conferences. You can have a not for profit conference with really expensive tickets and they can pay the speakers (this is the vision I build European Testing Conference towards - making real money to pay real money to speakers within a not for profit organization using profits to pay other conferences speaker's travel). You can have a for profit conference with ridiculously small cost and they still pay the speakers (Code Europe was one like this - they made their money out of selling participants to sponsors in various ways in my perspective).

Speaker's choices of where they show up with great material matters. But most of all, participants using money on the conferences matter most. Pay for the good players. Be a part of a better world of conferences.



Read the whole story
karlosmid
12 hours ago
reply
Zagreb
Share this story
Delete

8 Tools I use to Accelerate My Testing

1 Share
Inspired by Justin Rorhman’s post of a similar name with a slight twist focusing on tools that generally help accelerate my testing. As a test and quality specialist embedded in an engineering team I have a lot of work to do on any given day. Our engineering team’s goal is to ship quality software on a […]
Read the whole story
karlosmid
12 hours ago
reply
Zagreb
Share this story
Delete

Failing Selenium tests – SOLVED!

1 Share
Just under a year ago the team and I made the bold decision to delete our existing suite of automation UI test. The suite was your traditional web test framework – SpecFlow, Selenium WebDriver, Page Object Model. I could explain in length how we came to decommission the tests but I think this picture does a pretty decent job of explaining:
TeamCity Build History (before)
In short the framework was bloated, full of fragile tests (many of which were ignored), the developers were waiting over 40 minutes for feedback, the testers were tired of fixing failing tests and everyone was fed up with red builds. Before making the decision to deprecate the old framework we did review the code and we saw all the traditional poor coding traits – lots of duplication, lack of consistent patterns or naming conventions, huge classes doing far too much, too few layers of abstraction, tightly coupled dependencies, static objects preventing tests from running concurrently… the list goes on.

The plan

We began by decommissioning the old framework (removing the tests from the CI build) and then started working on a replacement suite of end-to-end smoke tests, with the intention of resolving a number of the design issues with the old framework and in-time, replacing the existing test suite all together.
Naturally this did present us with the problem of having no automated coverage of the UI or end-to-end journeys, so in the short-term we had to accept more manual regression checking before releasing, but that was just something we were going to have to live with.
So what next?
We began by reviewing all of the feature files in the existing test pack and classifying each of them (out of scope; add to new end-to-end test suite; move to lower level test suite, e.g. service, component or unit), and documented the actions as Features and Stories in the team’s backlog.
We then ran a workshop with the Business Analysts and Solution Architect to review the coverage, gather feedback and prioritise them based on business criticality.

The result

Fast forward a few months and eventually we reached a momentous occasion. Our new smoke pack was finally merged in and running as part of the CI pipeline and all tests were GREEN!!!
TeamCity Build History (after)
In the first couple of weeks of running the tests they had already begun offering value and has helped to identify a number of bugs. What’s more, several months on, the tests are still running and passing consistently, and only failing when a genuine bug is introduced.
So how was this achieved and what lessons did we learn along the way?

Test coverage

The UI regression pack was overhauled, with the fragile UI test framework being replaced by a shiny new smoke pack. The new suite covers just the core end to end web user journeys (currently 24 scenarios), just 10% of the tests in the original framework. There are a few tests still to be implemented, but on the whole this pack covers our core user journeys.
We chose only to include the full user journeys that truly needed to be run through the browser, everything else was pushed to lower level tests, allow them to run earlier in the pipeline, with few dependencies. This provided much faster feedback and closer alignment to the automation test pyramid.

Framework design

At its heart the framework is built on Selenium WebDriver v3 and runs using NUnit and SpecFlow and the feature files are described in third-person business domain language to allow for better business collaboration.
Tests have been designed for robustness and stability, but are also efficient and configured to run in parallel. Total execution time is around 5 minutes. They currently run against Google Chrome (Windows OS) in SauceLabs (our cloud cross-browser testing platform) to provide a consistent operating platform and to improved stability. They has also been configured to run in our TeamCity CI pipeline against our SIT environment.
We have done away with the Page Object Model and PageFactory, and have adopted the Screenplay pattern (formerly the Journey pattern), to maximise maintainability and code reuse. This pattern introduces more layers of abstraction and offers a more SOLID approach.
In order to create the new framework we also abstracted some of the common functionality into three standalone packages. The advantage of using these packages is that the test project itself is very lightweight. In addition the packages have been open-sourced within the organisation, allowing other teams to adopt them and meaning that they are now being maintained and contributed to by the wider engineering community. These packages have also be configured to run in TeamCity pipelines and with unit and acceptance tests, meaning that they are stable and easy to maintain (more on this here – Tests for your tests).
Finally, Slack notification have been configured to post build failures to the team channel, so everyone in the team is aware when there is an issue to be investigated.

Next steps

After going live with the new framework we made the following agreements and added them to the team’s charter:

  • Keep tests green, as if our lives depended on it!
  • Keep code quality high, as if our lives depended on it!
  • Only add tests that truly need to be tested through the browser
  • Keep total test execution time below 10 minutes

We also added some additional stories to the team backlog to ensure we continue to improve the framework and increase coverage. This will help to minimise the need for manual release testing and will enable us to continue our push towards fully automated Continuous Deployments.

Lessons learned

Having been through this journey here are the lessons we learnt, and some things to consider should you face a similar situation:

  • Start with the end in mind – Define what “good looks like” up front. How many tests will you have (ratios work better than exact numbers)? How quickly will they run? Where will they run?
  • Communicate – Be open with your team before making taking bold decisions like decommissioning a whole suite of tests, listen to their concerns and seek their advice
  • Stakeholders – Seek buy-in from your stakeholders so everyone knows what is happening, the impacts and the value that it will bring
  • Single responsibility principle – Separate common functions into independent libraries/packages and enable greater code reuse
  • Open-source – Adopt an open-source model for common frameworks to allow multiple teams to collaborate and benefit from each other’s contributions
  • Test code is still code – Apply the same care, practices and design principles to your test code as you would with your production code
  • Test your tests – Unit testing your test libraries might seem like overkill, but actually they allow you to add features and fix bugs with greater speed and confidence
  • Pairing – Pair-programming, code reviews and pull requests are a vital part of any software development project and automation frameworks are no different. They help to share knowledge, increase code quality and instil comradery
  • Visible failures – Publish test reports and highlight failures
  • Root cause – Get people talking about failures and identify the root cause as soon as possible. Bring the whole team together around a common cause and avoid a “them and us” divide within the team
  • Measure value – When your automated checks uncover bugs, raise them and tag them so you can keep track of what kind of bugs are being caught and the value they are bringing
  • Publicise – Shout about your successes (and failures) so that yourself and others can learn from them
Read the whole story
karlosmid
1 day ago
reply
Zagreb
Share this story
Delete

Five ways to make your presentation better

1 Share
  1. Make it shorter. No extra points for filling your time.
  2. Be really clear about what it’s for. If the presentation works, what will change? Who will be changed? Will people take a different course of action because of your work? If not, then why do you do a presentation?
  3. Don’t use slides as a teleprompter. If you have details, write them up in a short memo and give it to us after the presentation.
  4. Don’t sing, don’t dance, don’t tell jokes. If those three skills are foreign to you, this is not a good time to try them out.
  5. Be here now. The reason you’re giving a presentation and not sending us a memo is that your personal presence, your energy and your humanity add value. Don’t hide them. Don’t use a prescribed format if that format doesn’t match the best version of you.

And a bonus: the best presentation is one you actually give. Don’t hide. Don’t postpone it. We need to hear from you.

A presentation is expensive. It’s many of us, in real time, in sync, all watching you do your thing. If you’re going to do it live, make it worth it. For us and for you.

       
Read the whole story
karlosmid
1 day ago
reply
Zagreb
Share this story
Delete

Lean Testing or Why Unit Tests Are Worse Than You Think

1 Share
Comments
Read the whole story
karlosmid
1 day ago
reply
Zagreb
Share this story
Delete

How I Socially Engineer Myself into High Security Facilities

1 Share
Comments
Read the whole story
karlosmid
2 days ago
reply
Zagreb
Share this story
Delete
Next Page of Stories