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 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 has 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 great community with many helpful people. With uncle Google we find almost everything in space of few minutes. It seams all we need to improve is a little bit of desire. Keep your mind open and adapt beginners mind.  Read inspirational book like Mastery to find motivation.

2. Improve your skills in check automation

Ability to automate checks in one of the leading programming language (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 considerable amount of time working to improve skills in this area.

3. Learn to manage 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 virtualisation (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 use 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 social activity now. Crazy geeks who can speak only boolean aren't really desirable. 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 to read both Lisa Crispin and Janet Gregory 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, specialise in one type of testing

From my perspective there is huge demand for skilled testers. Pentesting has to performed almost in every company, but even after 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 specialisation is the only reasonable alternative for automation.

6. Go Mobile

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

Part II - Don'ts

1. Manual checking is dead

Few years ago Google testers realised 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 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 trainings as shortcuts

We are more and more lazy as society. That's why we love shortcuts. People naively send SMS, because they except big reward. 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 post I talked about our testing brand. If you are smart share your knowledge. I guarantee you will gain a lot be doing it. Submit a paper for 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...