Monday, February 8, 2016

Do's and don'ts for testers - 2016 edition

Time is flying pretty fast. Christmas has just finished and we have February already. Probably everyone who wanted to post 2016 testing predictions has already done it. Hopefully, I'm the last one (lots of scientists say it's the best possible scenario). Before I start I'd like to introduce two controversial definitions, which are not covered in ISTQB Glossary. Quotes from James Bach and Micheal Bolton (source):

Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes to some degree: questioning, study, modeling, observation, inference, etc.

Checking is the process of making evaluations by applying algorithmic decision rules to specific observations of a product.

I'm not a fan of reinventing the testing field entirely, but this distinction seems pretty reasonable for me. 

Part I - Do's

1. Keep learning

Probably the most important one. It can even mitigate our flaws in other areas. I have recently read great Erik Dietrich's article about developers who have stopped learning and become Expert Beginners. It can not only lead to your personal stagnation but also affect our most ambitious peers who may decide to change their job. We have a great community with many helpful people. With uncle Google, we find almost everything in space of a few minutes. It seems all we need to improve is a little bit of desire. Keep your mind open and adapt the beginners' minds.  Read an inspirational book like Mastery to find motivation.

2. Improve your skills in check automation

The ability to automate checks in one of the leading programming languages (Java, C#, Python, JavaScript, Ruby...) is crucial. That's definitely the most important hard skill for testers. We should be proficient with Selenium and API level testing. I'm not sure about unit testing (shouldn't we coach programmers to write them?), but some knowledge about Mockito and EasyMock is required. Our peers (developers, business, managers) all expect us to write working (stable!) automated checks on all pyramid levels. Personally, I hope to spend a considerable amount of time working to improve my skills in this area.

3. Learn to manage the testing environment

It seems like the time when testers asked for deployment and just waited are long gone. Now we should be able to care about our environment (configure CI tool, manage Selenium Grid, etc.) and prepare appropriate scripts (Bash, Perl). Servers need to be orchestration by a tool (Puppet, Ansible, Chef...). We have virtualization (Vagrant), clouds (AWS, Google Cloud), and containers (Docker). This is a lot to learn, but we don't have to be experts in this field (unless of course, we test app that uses them). They're just useful tools, and we should know how to use them appropriately. I would say that more and more companies expect testers to maintain those tools not only for themselves but also for developers.

4. Adopt Agile / Lean principles and improve social skills

Software development is a social activity now. Crazy geeks who can speak only boolean aren't really desirable. The tester should add value to a team. We need to coach programmers how to care not only about new features, but also unit tests, quality, and refactoring. I strongly suggest reading both Lisa Crispin and Janet Gregory's books, especially More Agile Testing. They are available via Safari Books. I'm not an expert in Lean, but kaizen / continuous improvement is surely worth applying. I'd like to read a lot in this area this year.

5. Find your niche, specialize in one type of testing

From my perspective, there is a huge demand for skilled testers. Pentesting has to performed almost in every company, but even after the OWASP project, those skills aren't common among testers. If you love nitpicking give yourself a chance. With various online scanners and powerful tools like Burp, it's no longer rocket science.  Performance/user testing skills are desirable too. Rare testing field specialization is the only reasonable alternative for automation.

6. Go Mobile

Mobile is booming. We are more and more addicted to our smartphones. It's kinda sad, but it's reality. The good company simply has to have a mobile site version and Android/iOS native app. Those are at least three more products to test. With the mobile-first movement, we need to make a good first impression, i.e. release quality product. There are so many mobile testing frameworks what this branch of testing already has its own life. Surely, we will have to join it eventually. 

Part II - Don'ts

1. Manual checking is dead

A few years ago Google testers realized that people in their company are valued by coding skills. So they dumped manual checking completely and started writing automated checks. Sooner or later this activity will be abandoned entirely (replaced by automated checks and skilled exploratory tests). If you have doubts just ask yourself a question: would you hire someone who only writes test cases and checks if it works as desired? 

2. Don't go all-in on ISTQB certificates

This topic probably bore you already, so only a few words. Pass ISTQB FL because it may give you an edge during recruitment, but don't waste time going higher. Read my recent post or Rob Lambert's book for details. 

3. Don't treat external training as shortcuts

We are lazier and lazier as a society. That's why we love shortcuts. People naively send SMS, because they except big rewards. Yet even if they win, they usually lose it right after. Shortcuts don't work, we have to slowly go forward. Don't expect external coaches to teach you everything. Even if training is perfect, there is simply not enough time. Make sure you pay for quality stuff before attending.

4. Don't be shy

In my previous postI talked about our testing brand. If you are smart share your knowledge. I guarantee you will gain a lot by doing it. Submit a paper for the conference, start blogging or just comment here :)


  1. great post, I'd sign under all of those!

  2. In general I like this post, however ( ;-)) should I understand from what was written here, that the common way of improving testing skills is to learn programming/tools/frameworks/... etc.? ;-)
    I know your answer, therefore I think there is a lot more in 'testing' than that isnt it?

    1. I think we can add skilled exploratory testing to point 5, but job market seems to disagree with me... Theory doesn't seem to go along with business expectations.

    2. Actually it is not only a theory, but is coming from practice. Even if you have got skilled tester who is good in automation it doesnt really mean project is well tested, doesnt mean he/she is automating the right things in the right way (I mean business analysis part of automation).

      And what`s more I dont agree that automation has something to do with the business. Business cares (at least it should) about resolving stakeholders problems or covering their requirements (this is why we build software probably?) so who cares if the software is covered by automated tests or manual as long as we deliver?

    3. If it is a safety relevant software, for sure there will be some authorities which are willing to see the test reports :-)

  3. dziękuje za ten tekst, trochę mnie zainspirował.
    Paweł z

  4. Great post! Reminds me a little bit of the 2016 software testing new year resolutions post!

  5. This comment has been removed by the author.

  6. If by manual checking you mean repeating over and over again same test manually then I agree -- it's dead. However, I still believe exploratory tests bring value. When you automate tests you focus on your test to be reliable, stable and quick. When you explore the application you use your lateral thinking, turning left, right, going off-road. It's completely different mindset.

    1. Yes, I agree with you again.

      I tried to include this in my point 5 (find your niche, specialise in one type of testing), but probably failed to express that clearly (as you and Daniel observed).

      Thanks for your comments Maciej, you have made my post better :)

  7. I would also add one more element to the DOs list: Go below end-to-end tests and think white box. End-to-end tests are known to be long, flaky and not reliable: A response to that is to focus on tests are better isolated. So, testers should make a step ahead towards developers tests, just like in Agile teams developers help testers automate end-to-end tests.

    1. Good point, definitely agree. I have linked this article more than once here if I remember correctly :)

  8. Can you fix the link to "social activity"? Seems dead now...