TL;DR

At Testival 2019 Zabok, we had sixteen open sessions. This is a report on four sessions that I attended. Testival is unconference with open sessions and two keynote sessions.

Session on Page Objects, moderated by Titus Fortner

First organization failure. The room had a large touch screen panel. Of course, MacBook pro did not like it 🙁

The session started with the tool mention, Night Watch. It is a node.js framework for browser automation. Titus asked:

Where we should put assertions in browser automation?

Assertions do not belong to the page object code. Their place is in Then step implementation, because when an assert fails, it gives precise information about what failed.

Boolean assertions?

We should avoid doing boolean assertions because we lose information about what went wrong. Raising exception with the error message is a much better solution. In Ruby, we have RSpec library with the option to create custom matches. But that complicates the code base and should be avoided.

The most frequent error using frameworks based on Selenium is “Element not present/visible/ready.” We need to have implicit waits to avoid such mistakes. Watir 6 is doing a lot of clever waits under the hood.

Session On Definition Of Done In Software Testing, proposed by several attendees

It all started with process confessions :), how testers fit in the development process at their companies. Then we had questions:

How many tests are enough?

Which tests?

I noted that this leads to testing coverage and that we have several coverage possibilities. For example, one option is to cover all critical project risks. Excellent starting point: Heuristic Test Strategy Model [Bach].

More confessions.

We do customer bug report root cause investigation. We even debug the application. In the end, we retest a bug fix.

How to onboard a junior tester on a project? What to do when testing time is short?

What is a serious bug? Every project has its own meaning of severity. Do not mix severity with priority, those are two different things.

We need to have zero bugs at the end of our testing. That is for known bugs, but what about unknown bugs?

Scenario testing founds most issues. It is testing where we use applications by combining application features in different business value flows.

To conclude. Testers are responsible for the quality of testing. There is project quality, and that is the responsibility of the whole team. The tester should educate themselves and start to change their current testing routine.

Session On Automated Visual Checking

This is currently a hot topic in browser automation. How to write an assert for visual regression changes? We have several problems. First browser resolution. Test scripts must first set agreed browser resolution. But which resolution to choose? And scripts usually run in browser headless mode, which is not the same as none headless automation.

Problems that testers try to solve with visual regression checks:

• font rendering
• pdf rendering
• colors.

The mentioned tools were Apprise by Gojko Adzic and Applitools.

I am not a fan of automated visual checks. Based on the knowledge which visual files changed (CSS, images), I do direct visual checks by myself. When I know where to look, I use production and testing environments opened in two tabs side by side.

Session on Note-taking during the testing, moderated by me.

I try to make session testing notes as much as possible. For example, to made notes, while I was exploring a new application. My mission was to use those notes as documentation. Where I failed was not with the quality of those notes, but the ability to search/find them over several physical notebooks. I also use notes on sessions that I attend on various events, but those are just reminders for later blog posts.

In the session, we had testers of an embedded system. They use a tool called Integrity, where they have a lot of information about the feature they need to test. But they also write personal testing notes in physical notebooks.

There is also usage of markdown notes. Similar as readme.md files in git repositories.

Test Buddy is a session-based testing tool in the form of the web application. I have an account, but I have never used it in my testing session.

My conclusion is that testers make a lot of testing notes, but that golden information is not stored in electronic form in some cloud platforms for future reference.