Testes

Não existe “Testes automatizados”.

Em um dos parágrafos deste post (aconselho ler antes) o autor escreve esta frase:

automated checks” as a clear distinction from testing, and I started to think that perhaps there is some hope to rescue the profession from what Bach calls the “toxic term” automated testing.

O que me chamou muito a atenção e me fez parar para pensar foi a parte onde Bach pontua Automated Testing como um “Toxic Term” 

Porque será que ele diz isso? Será que estamos esquecendo a verdadeira identidade de nós Testers ? Será que hoje o escopo da nossa profissão se resume apenas a AUTOMATIZAR as coisas ?  Passar 8 horas do nosso dia sentados na frente de um computador escrevendo linhas de CÓDIGO como se fossemos desenvolvedores ?

Uma coisa é Explorar o produto e a outra é realizar VERIFICAÇÕES AUTOMÁTICAS no produto, as duas atividades juntas define o que é Testes. Quando você escreve um script de testes você está fazendo uma verificação automática para um cenário que já foi previamente explorado por você, ou seja não tem como você automatizar algo que você não conhece, você precisa aprender antes como deve funcionar determinada funcionalidade, qual o resultado esperado, quais suas limitações, exceções e etc,  este processo de aprender/explorar chamamos de Testes.

Quando usamos o termo “Testes Automatizados” parece que existe um robô que irá fazer TUDO sozinho. Irá TESTAR o sistema por completo e ainda APRENDER com ele. Irá QUESTIONAR, irá SUGERIR melhorias do ponto de vista de performance e usabilidade, e quando na realidade o robô apenas irá fazer o que você escrever no seu script e nada mais!

Umas das características mais importante para automação é saber o que AUTOMATIZAR, é ter em mente que nem TUDO PRECISA ser automatizado, portanto você como Tester deve SIM ter um boa base sobre como Testar um sistema, conhecer os vários tipos, níveis e técnicas de testes, explorar e aprender com ele,  perguntar tudo, sugerir melhorias no produto e nos processos, ter o mindset de melhoria contínua. Do meu ponto de vista esta é a verdadeira função de um Tester, aí sim você estará agregando VALOR ao time, porque se for para ficar o tempo todo escrevendo linhas de código, qual a nossa diferença de um desenvolvedor ?  Qual o nosso verdadeiro VALOR para o time ?

Janet Gregory disse algo que eu gostei muito. Ela disse que ela como Tester “quer ser conhecida como alguém que contribui para a entrega do produto, e não alguém que quebra.”

Em um grupo de profissionais de Testes no LinkedIn, o pessoal estava discutindo qual o escopo da profissão de um Tester, e Dan Ashby  escreveu o seguinte:

“It surprises me that this question is still being asked and that it still gets so many confused responses.
If anyone suggests that automation is replacing testing, then they clearly don’t know what testing is.

The way you should look at it is like this: There are things that you have explicit expectations for. This might be from requirements or from conversations or from wireframes. This is your KNOWNS. And if you operate software with a view to check that the software meets that explicit expectation, then that is a CHECK. (the clue to this is in the sentence)… Anything that you have an explicit expectation for (i.e. that you would “check”), means that you can have a machine do that checking automatically if you code it to do so.

HOWEVER, lets not think about the things that aren’t explicit. maybe you have implicit or tacit knowledge. Or maybe you and the team and the product owner just haven’t thought of something yet – be it a variable or a different perspective or whatever. These are UNKNOWNS and even UNKNOWN UNKNOWNS. These are also things that it is impossible to “check”, since you have no expectation (which means that you CANT AUTOMATE THESE THINGS). You will need to INVESTIGATE and EXPLORE these unknowns to see how the system /actually/ works. This is TESTING!

Need an example? Lets look at an input field. You might have explicit information that the field should mandatory, should allow alphanumeric characters, should accept up to 100 characters, and the field should prevent the user from typing more than 100 characters…

So we can “check” that the field accepts 100 alphanumeric characters.
We can “check” that the field doesn’t allow the user to type more than 100 characters
We can check that the field is mandatory.
(we can automate these)

But what if we type a space? does that bypass the “mandatory” rule?
What if we paste in a space? Does that act differently to typing?
What happens if we paste in more than 100 characters? Does that bypass the 100 character limitation? Or does it crop the characters?
What happens if we type in symbols? Are they accepted?
What about foreign characters? And not just characters like: é,á, or ó, but text like: δισιθ
And what about ASCII 255 characters? You know… The “blank” ones like 129 or 141.
And what about quote symbols? Will the field handle these? Or will the field be susceptible to XSS or SQL Injection?

And we’ve not even got to things like accessibility (tabbing, colour scheme, text size, field labels, etc), performance (speed, load, stress, etc), usability, reliability, testability, + many more things…

Since in this example we don’t have explicit expectations about these things, that means that we can’t automate a check for them. Asking these questions is testing – whether that’s asking the product owner during the requirements gathering, or asking the product through operation and observation… Its testing.

But you should know all this already if you’re a tester… right? How could you not know this if you take your craft seriously?” 

Acho que lendo o comentário acima ficou AINDA mais CLARO porque usar o termo “Testes automatizados” é um equívoco.

James Bach e Michael Bolton são figuras respeitadas e conhecidíssimas na comunidade de Testes mundo a fora. Eles escreveram um post falando mais sobre este assunto, se você quer se aprofundar sugiro a leitura:  Testing and Checking

Grande abraço.

Advertisements
Standard

2 thoughts on “Não existe “Testes automatizados”.

  1. Thanks for continuing the discussion. I read a Google translation of your post, and I’m humbled that you wrote in response to my post. I hope that you are able to also have this discussion with your colleagues at work too. I believe that the proper distinction between tests and checks is necessary for the testing profession to have the respect that it deserves. I’m happy to see the discussion span countries and languages, and I hope that you continue to share your thoughts. All the best.

    Philip

    • Hi Phillip, thank you for your comment, I am very happy to have a review out of Brazil. Here in Brazil I see that people confuse with checking and testing and often use the term Automated Test to describe the use of tools to carry out automatic checks on the software. I hope this will change one day because as you said this is necessary for our profession, I will continue writing my thoughts about it. I really like your posts and share your idea about software testing. Best. Allan.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s