Skip to main content

Notes after TestingCup 2018

On May 28-29th I attended TestingCup conference in Łódź. Having quite unique perspective: this was my second year in row as a Speaker at this conference I want to share some thoughts on the event. Dust has settled, lets go! 



Championship 

Originally TestingCup is a software testing championship. Wait, what? Yes, the formula is unique: teams and individuals from all around Poland are competing in finding the most bugs and defects in specially prepared application - Mr. Buggy. I don’t have specific data, but since this year’s conference was all english I guess competitors were not only from Poland. As a spectator, I must say that the whole competition looked very professional. There were team shirts and names, podium and trophies (gold cup and cash). 

Some cons? Testing championship is held at the first day of the conference. So this is already a conference, but if you’re not taking part in the championship… there’s not much to do, since all the talks are in the next day. Organizers are aware of that, and they’re coming with some ideas. I took part in helping hand initiative: this was basically the Bring Your Own Problem idea, where attendees were asking questions from specific fields - in my case I was helping with Test Automation challenges. This is a step in a good direction and I look forward how it'll develop. 

Conference 

Next day, in the 29th, the conference day started. Firstly there were 111 seconds flash talks. Although there were some glitches with the sound effects (thunder strikes!) I find all sessions very successful and interested, especially talks by K. Mrozek, R. Smilgin and R. Lambert. 

Kamila’s point was about how we should approach conference talks: no prejudice, no negativity, only curiosity, openness and respect. I would sign my name under all of these. 

Radek talked about the change of the software tester role in the age of automation and DevOps. Great thoughts, I definitely would want to hear longer version of this. 

Robert Lambert gave some points on the features of great test engineers. Robert was the Program Commitee lead of the conference and I was very impressed about his general presence - he was very open and friendly, he was approaching attendees, shaking hands, introducing himself, starting discussions. In general he was very engage, he went beyond his role as a Program Commitee and serve also a role as a great host. 

Then we had the Keynote delivered by Michael Bolton. Since Michael is world-wide recognisable figure in software testing world I had high expectation before the talk. Michael speaking skills are excellent, but unfortunately I can’t tell that my expectations were fulfilled. For me the talk was quite chaotic and I couldn’t get consistent message. 

Next I listed to Kevin Harris talking about shift left approach. Great Speaker, well delivered talk. The subject is close to me, since I also had the talk about Shift Left approach in testing at TestingCup year ago, in Gdańsk. In his talk, Kevin gave few rules and tips in implementing shift left approach in the development process and judging by the amount of questions at the end, the talk was well received. 

This was all I did see, since the next speaker was me! 

Speaker's perspective 

As I said, this was my second time as a Speaker at TestingCup. Same as year ago, everything was organized perfectly - and the same as year ago, Joanna was in charge of the event organization. Starting from the email communication, travel details, accommodation - everything was in place. 

In the room where I had my talk, conditions were great. Microphones, remotes, sound and lighting - all checked. Thanks Adrian for assuring all of these and for hosting! 

The only drawback was that till the very beginning of my talk I didn’t know whether it will be recorded or not, and it turned out it wasn’t. Video recording of the talk is the form of remuneration for the speaker and it should be clear if you would be recorded or not. 

Agenda 

As for the agenda - diversity! There were talks from all different fields of software quality. From the AI (side note: every single testing conference I attended this year had AI talk ;) ), through sketchnoting, to the Boeing 777 flight simulation. I’m sure that every person could pick something interesting. Personally I find the agenda too diverse - I lacked thematic tracks and strict technical subjects. But this is only my personal impression, I know that the agenda diversity for some participants was a great way to explore new areas. 

The thing that was new about agenda this year is that all the talks where in english. Good job, program committee Members! TestingCup has definitely the potential to be one of the most recognisable testing conference in Europe and this is the first step to achieve that. 

Venue 

The event was held in the heart of Łódź - Manufactura. Venue was in the Vienna hotel. In terms of rooms and conditions - the hotel couldn’t be better. It’s a great hotel with all the facilities, beautiful design and… food! 

Summary 

TestingCup is definitely one of the best software testing conferences I attended this year. With the idea of “all talks in english” it will quickly make its spot on the map of the Europe’s IT conferences.

Popular posts from this blog

Testing Asynchronous APIs: Awaitility tutorial

Despite the growing popularity of test automation, most of it is still likely to be done on the frontend side of application. While GUI is a single layer that puts all the pieces together, focusing your automation efforts on the backend side requires dealing with distributed calls, concurrency, handling their diversity and integration. Backend test automation is especially popular in the microservices architecture, with testing REST API’s. I’ve noticed that dealing with asynchronous events is particularly considered as challenging. In this article I want to cover basic usage of Awaitility – simple java library for testing asynchronous events. All the code examples are written in groovy and our REST client is Rest-Assured. Synchronous vs Asynchronous  In simple words, synchronous communication is when the API calls are dependent and their order matters, while asynchronous communication is when the API calls are independent. Quoting Apigee definition: Synchronous  If a

Rerun Flaky Tests – Spock Retry

One question I get asked a lot is how you can automatically rerun your test on failure. This is a typical case for heavy, functional test scenarios, which are often flaky. While test flakiness and its management is crucial and extensive matter itself, in this post I want to give a shout to the extremely simple yet useful library: Spock-Retry. It introduce possibility to create retry policies for Spock tests, without any additional custom-rules implementation – just one annotation. If you are not a fan of Spock testing framework and you prefer JUnit – stay tuned! I will post analogous bit about rerunning JUnit tests soon. Instalation  If you are an maven user, add following dependency: <dependency>       < groupId > com.anotherchrisberry < /groupId >       < artifactId > spock-retry < /artifactId >       < version > 0.6.2 < /version >       < type > pom < /type >   </dependency> For gradle users:

Performance Testing – Vegeta Attack!

Performance testing is crucial field of modern software development. Taking into account that in today’s world majority of app’s communication is web-based, it turns out to be even more important. However, it still enjoys less interest than automated functional testing, and publications on load testing subject usually focus on mature and complex tools like JMeter or Gatling. In this post I’d like to introduce command line usage of a super simple and lightweight tool for performance testing of HTTP services, which is Vegeta. Who is Vegeta  Besides Dragon Ball’s character, Vegeta is a simple load testing tool written in GO, that can be used both from command line and as an external library in your project. In order to use Vegeta, download executables from here . It is recommended to set environment variable for ease of use.  For Mac users, you can download vegeta directly from Homebrew repositories: $ brew update && brew install vegeta Vegeta’s Arsenal  Usage