How to become a better tester?

In a lot of professions we see that people want to grow and become better in what they do. It’s a pity to see that within testing a lot of people are just doing what they always do, the way they always do it. Why does it seem that a lot of testers don’t try to get better at testing? Is it because they don’t know how or should the title of Martijn de Vrieze’s post “Is testing the dumping grounds of IT?” be answered with yes too much? Let’s try to put some pointers down on how to become a better tester.

Know your basics

The first step to becoming a better tester, is to know what testing is about. Most testers have at some point in their career participated in a “testing foundation course”. The basic terminology learnt in such a course, together with some basic techniques, should not be forgotten. I’m not saying that you should apply everything all the time, but just don’t forget it. The courses are called foundation for a reason! Every house needs a foundation, not only the first couple of times you build a house.

Be passionate and keep practicing

You’ve got to love what you do and keep on practicing to become better! Have you ever seen an Olympic champion that did not train? Every piece of software (or hardware) you’re testing is different. So you get new challenges continuously, but you’ve got to treat them as new challenges too. Of course you have some basic tests that are valid to execute in this context, but it’s a new challenge so try new methods and think outside the box. Only executing standard tests will not make you a better tester.

Read and write

One way to learn about the test profession is to read. A lot of useful sources on testing exist. When you are reading this, you found one of the sources: blogs. More and more testers start blogging to let the community know what is in their minds and to help others that might run into similar situations. In my opinion, every tester should at least read one book on testing, but preferably more than one. The software testing club has a nice lineup here. Writing a blog is valuable to become a better tester too. It helps you realize what you do and structure it. The comments that you’ll get will also help you to think again on what you wrote.

Attend meetings with other testers

Face-to-face communication will help even more. Attend conferences, specialist group meetings and peer meetings. Every time you discuss about a testing topic (or just listen to others that are discussing), you will get something out of it. Either it strengthens you in your opinion, or it will help you to understand why your opinion should be adjusted. A conference is a great place to learn. People take the time to prepare presentations, so you will get a complete story. Meet-up with other testers to talk about these presentations and share your views. Never stop learning!!

Go to the dark side

Last month I saw a video of @EvilTester (Alan Richardson) in which he explained that we need to go to the dark side of testing. This was a great video and helped me a lot to realize what needs to happen for me to become a better tester. If you have 41 minutes to watch it, please do! He clearly states that a tester needs a sense of humor and take responsibility for what you do.

Advertisement

Test automation in Agile

In Agile, Scrum in particular, the whole team is responsible for delivering a high quality product at the end of a sprint! At the end of a sprint defects should not only have been found, but also fixed appropriately. It’s important to work efficiently, since creating software, testing it, fixing it and retesting it can be quite time consuming. Recently Martijn de Vrieze had two posts on test automation that provide relevant information on how to deal with test automation within Agile/Scrum (All my automated tests are passing, what’s wrong? and Throw-away test automation).

Martijn describes a couple of types of automation:

• Test driven tests (supposed to fail until that part is developed)
• Automated regression tests (supposed to pass)
• Automation to support testing

Test driven tests

The test driven tests are an important part of the development. For this post I would like to stretch this definition a bit to “automated tests needed within the sprint”. To be more clear: unit tests, system tests and functional tests. When the team uses test driven development, developers are required to start with creating unit tests before creating functionality. Test driven development has been described a lot, so I won’t go in depth on this. Automating system tests can be realised by using the same style as the unit tests, dealing with “more than units”. It’s important to realise that automating these tests needs to be done with a risk based approach. Automating everything will create overhead, since not all of these tests need to be repeated a lot. Be aware that for automating functional tests, it is advisable to automate just below the user interface, since the user interface has the largest probability to change.

Every test written within the sprint should be created to help achieve the Definition of Done.  Therefore, at the end of the sprint, all these tests should pass! During the sprint, tests from previous sprints will start failing, since new functionality is added and the expected result will change. If you already created new tests for these situations, the older ones can be removed. Be aware that all results the old test was checking are still checked in the new context. In other cases, you need to update the old test for the new context.

Automated regression tests

Regression tests are needed to check whether the new software doesn’t break any existing software. Since these tests are run at least towards the end of every sprint (but preferably more often) these tests are a good candidate for automation. Of course the focus of the regression tests is different form the test driven tests. The focus is more on connectivity and interaction with other systems and even the quality in an end-to-end context. When a regression test fails, there are a couple of options:

• The context has changed and the test is no longer valid, then update or delete the test.
• The newly created software has a defect which needs to be fixed this sprint.
• The existing software shows a previously undiscovered defect (which needs to be fixed).
  • Product owner needs to decide who fixes, when to fix and if the feature that shows the defect should go live.

Automation to support testing

To enable faster and more effective testing, testers may require automation. This type of automation does not need to be very robust. Think of a simple recorded script to get you through the necessary steps of logging in to an application. This script only works with the credentials you used while recording, but that might be just what you need. A simple automation like this can save you a lot of time, making sure that you can start testing the functionality that comes available after logging in. Another helpful part of automation can be to extract system information that is needed for defect logging. Delivering quick and dirty automation solutions to help testers is good enough, since the time invested in this automation needs to be earned back.

Selenium

Recently a collegue, Daniël Gollings, showed me Selenium. As an enthusiastic about test automation I was interested directly. So I started to follow the step-by-step tutorial he made. I downloaded all the needed compenents and started with Selenium IDE. Since I have a background in programming, I quicly switched to Selenium RC to be able to apply better control of the automation. The ease of setting up tests amazed me.

Recent conversations with Roy de Kleijn and Martijn de Vrieze, reignited the Selenium-fire. After following a webinar about page objects, I understand the concept. Now only experience can help me with applying the concept. Hopefully I can use my knowledge in a couple of assignments and broaden my knowledge.