Automated tests. They are there, and they need to be run. On a test environment. By you. You wrote them in a way that they should be reliable, when the features under test work as designed.
But each day you run the same tests on the same test environment, and they fail. Not because the feature under test is not working properly. No. Because of external factors, and by external i mean: hardware issues, network issues, other services that are underlying to your own but are not in your control. And to make it an even more awesome experience, each day you the run the tests, they fail when performing a different step than the one they were performing the day before when they failed. Continue reading The tester’s daily dilemma: my automated tests fail because of the test environment. What can i do?
A few months ago i got a very nice surprise. The organizers of the STPCon conference had accepted two of the talks i submitted to their call for proposals. So, i got a fantastic opportunity to talk at this conference i had heard a lot about, and the chance to visit a beautiful city, namely Washington. Continue reading My STPCon 2017 experience
It all started over 6 months ago. I heard about Nordic Testing Days being an awesome conference and i really wanted to be a part of it, as a speaker. Having never been to Estonia, the location was also a nice plus. So i submitted some talk ideas and the guys from the organizing team were kind enough to accept me as a workshop deliverer…workshoppee…well a speaker who does workshops. Continue reading My Nordic Testing Days 2017 conference experience
Using try/catches to handle exceptions has become quite fashionable when writing tests with Java. However, this approach is also a frequent source of having false positives while running tests. Many times when writing the tests people forget to consider both sections of this code block: they forget to write the appropriate code in both sections – the code that deals with not encountering the exception (if the code in try executes) and the code that deals with encountering the exception (if the code in catch executes).
Continue reading Better Test Code Principles #5: Mind your try/catches
Yey, the program for the 2017 edition of the Nordic Testing Days conference has been published, and i am glad to be among the people speaking. More specifically, i will be running a two-hour hands-on, coding workshop on Selenium tests, the Object Oriented way. It will be a very practical workshop, where one can learn how to think in an OO fashion when it comes to testing complex modules or modules that appear in several areas of the page to be tested.
Check out the full program of the conference here: http://nordictestingdays.eu/schedule and don’t forget to get your tickets! It will be great.
So this year’s edition of RTC (Romania Testing Conference), held in Cluj-Napoca, has just concluded, and as a participant and speaker i had a great time attending the event. Therefore, here are some impressions and takeaways from a full day of presentations and meeting some really lovely folks. Continue reading Impressions after the Romania Testing Conference 2016
In my previous post i talked about how to check whether an element is displayed or not. There are times when tests where such an action is performed fail randomly (sometimes they will pass, other times they won’t). The assumption here is that the element was not displayed within a decent amount of time when there were test failures, but would have appeared later on. Therefore if the test would have waited a little bit before performing the presence check, it would have passed. Continue reading Selenium: How to wait for an element to be displayed / not displayed