‘Twas a not so warm day in October, that in Vilnius awesome testers united to talk about their crafts. Some crushed candies, some with machines worked, others Selenium magic performed. And this is how it all unfolded. Continue reading My TestCon Vilnius 2017 experience
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?
Following on from some of my earlier posts, where I described some of the useful utils from the apache.commons.lang3 library (like that very nice RandomStringUtils class), this time I will focus a bit on the StringUtils class. As the name suggests, it provides developers and testers an easy way to deal with certain String related operations. The class is quite large, so in this post I will cover the ‘substring’ category. As the name suggests, these methods deal with extracting substrings from a larger string, based on some conditions. Continue reading Extracting substrings with StringUtils from the Apache library
When you have more than one assertion in your test, you might want one of two things:
- Have your tests fail once the first assertion failure is encountered.
- Have all your assertions run, no matter if they have passed or failed. Of course, after they are run, if there are failures, you want the test to fail, and also show you where the issues were.
Suppose you are starting work on a new piece of software that you will need to write automated tests for. Your goal is to cover the most relevant test scenarios that apply to the feature , without missing or forgetting one. Below are a few steps (guidelines) to help you achieve identifying those required scenarios (a sort of ‘how i do it and it works for me’ guide). Continue reading How to identify the test scenarios you have to automate
The 2015 edition of the Agile Testing Day Conference recently took place in Postdam, Germany. I was one of the around 800 people who have attended, some of them testers, some Agile people with different roles in their organizations. Within 3 days of the conference, i had the opportunity to attend different types of presentations, from non technical to very technical ones, with lots of fresh new ideas, but also some not so great content. I will try to share some of my personal takeaways from this meet-up, so here goes. Continue reading Lessons Learned at the Agile Testing Days 2015 Conference
I’m thinking you should, in no particular order…
- Start from the basic . When learning a new language, start from the beginning. Understand the elementary notions of it. Make sure you know what the language represents, what it is used for, how to write it properly. Read the tutorials, try out the examples.
- Be lazy. Don’t reinvent the wheel. If you need some code that someone has already developed, use it. Use existing libraries where possible.
- Modularize, don’t copy paste. When you know you have bits of code that will repeat themselves, extract them in a separate method and call that method wherever the code is needed.
- Think and plan before you write your tests. Take time to analyze the requirements, to discuss the implementation with the developers, in order to identify the broadest and most relevant set of test cases. Take notes. Visualize how regular users will interact with the site. Make sketches. Jumping into testing just to finish it will make you skip some obvious scenarios.
- Name things properly. Whenever you pick a name for a method, attribute or test scenario, make it relevant to what it is supposed to do. Describe it as much as possible. Use a decent amount of letters (not 2-3 and not 100).
- Ask questions. Whenever something is not clear, or when you just need a confirmation of how well you understand the requirements, ask the people around you for information. No matter how basic or stupid the question might sound, it’s the start of a conversation which benefits all the people included in it.
- Separate concerns. Don’t put all the code in one class. Analyze what you must write. What part is the setup, what part is the verification? Usually tests should largely focus on the actual testing, not the setup, so maybe extract that part into a separate class/unit, so that you minimize how large a test it. Also, you can put in all validations in a separate place. In this case, when you read the test, you should have – a line of code which calls the setup; the test logic; one line of code that performs the validation (if possible).