Curso Gratuito de Automação de Testes Para Iniciantes

Disponível no
Youtube

 

QA no futuro hoje!

qa futuro

QA no futuro hoje!

Quando formamos em um curso superior, sempre nos preocupamos com o que faremos quando ele chegar ao fim. A mesma situação aconteceu comigo, e todos passam pela mesma incerteza que digo que pode ser pior do que a escolha do curso superior. Me formei em ciências da computação e minha ênfase durante o curso foi na área de segurança, estudando criptografia, esteganografia, ou seja áreas da criptologia em iniciações científicas e Trabalho Final do Curso (TCC).

 

Mas sempre tive um grande apreço pela engenharia de software, estudava e sempre pensava que iria juntar as duas aéreas em algum momento da minha carreira. Me formei em meio uma crise econômica e política que desestabilizou o país, resultado meus planos de mestrado e doutorado foram para escanteio pois necessitava de bolsa para conseguir fazê-los. Então comecei a analisar as vagas que o mercado oferecia e tinha uma área que estava crescendo, Teste De Software ou Analista de Qualidade. Através de várias pesquisas terminei me identificando a tal ponto de no mesmo dia decidi seguir a carreira na área de qualidade.

 

 

Bom primeiro passo feito, mas verificando meu currículo eu não tinha quase nada que os recrutadores pediam que era o mínimo. Aqui eu quero dar uma dica para quem está iniciando: procuram os profissionais que são referência na área sigam no linkedin ou outra rede, sempre aparece nos feeds dicas, cursos, jornadas para quem está iniciando e procurem também pelos grupos no facebook, linkedin sobre a área de interesse que você almeja. A comunidade sempre se ajuda muito. No meu caso eu procurei cursos, gratuitos sem emprego fica difícil a aquisição, e estava quase nos últimos dias para se inscrever no curso rápido de teste de software da Iterasys.

 

“ O homem ignorante apenas guarda o seu conhecimento, enquanto o homem sábio o compartilha”  Anônimo

 

E o melhor gratuito, me senti entrando num oásis no meio do deserto. Tive uma grande chance que agarrei na primeira oportunidade. Através das QArentenas também da Iterasys, fui moldando os meus próximos passos. É aí que fica a maior dúvida: por onde começar a estudar? É muito conhecimento? Que linha de raciocínio e estudo eu utilizo? Preciso estudar tudo ao mesmo tempo? Preciso tirar certificações já no início da minha carreira? Estudo só ferramentas de automação?

 

Morte Do Testador de Software

 

Para conseguir essas respostas temos que entender que o testador está MORTO!!

Que isso não vou nem continuar a ler e nem tentar entrar nessa área se já tá morta!!!

Calma, para traçar uma linha de estudo em QA é necessário analisar o passado dela e a evolução do testador o futuro de ambos. Não se preocupe sua pergunta vai ser respondida, continue lendo. Antes de iniciarmos nossa jornada na história do teste de software, vamos pensar na seguinte pergunta: Por que existem testes de software? e de uma forma mais abrangente: Por que produtos de diversos segmentos são testados? A resposta é lucro!!

 

Quando achamos um defeito antes que ele se torne uma falha as empresas economizam muito dinheiro. Mas além disso a reputação de empresas que conseguem lançar produtos quase livre de falhas é muito boa. O que mais importa hoje em dia é a imagem, empresas não vendem somente produtos e sim suas imagens, desde de inovadoras à competentes e sérias. Agora se uma falha ocorre quando os clientes já estão usando o produto, a imagem da marca sofre e é depreciada. E o dinheiro de possíveis lucros deve ser utilizado para a correção dessa falha.

“Quanto mais cedo encontramos um defeito, mais barato será sua identificação e correção.” Myers.

Com isso entendido vamos entrar numa máquina do tempo agora.

 

História do Teste de Software

 

Para não jogarmos somente fatos históricos nos seus olhos, vamos dividir a história do teste de software em 5 grandes períodos.

 

 

1 período:

Nome:depuração

Data: 1947–1956

Nesta época os testes eram todos voltados para o hardware, porque eram menos desenvolvidos como os que temos hoje e seu correto funcionamento era essencial para o software. Temos um grande fato histórico que aconteceu nesse tempo Grace Murray, cientista na Universidade de Harvard, que trabalhou com o computador Mark II achou uma mariposa presa a um relé atrapalhando seu funcionamento. Ela documentou seu achado como um bug e prendeu a mariposa com fita adesiva no relatório. E o trabalho feito para solucionar o bug ela nomeou de depuração. Aqui se vê um tipo de testador chamado de “solitário” quem acha o bug, deve corrigi-lo e documentá-lo.

Image for post
                                                               First Bug

Então nesse momento somente corrigia-se os defeitos que surgiam no hardware ou software, portanto os testes eram corretivos. Somente em 1949/50 Alan Turing mudou essa mentalidade através dos seus artigos: verificações de software e o “Teste de Turing” na qual afirma que o software deve fazer o que os requisitos do produto mandam. Aqui temos a semente do conceito de testador 1.0, mais para frente veremos esse conceito.

 

 

2 período:

Nome: demonstração

Data: 1957–1978

A experiência no novo setor de teste estava aumentando, porque novos programas caros, importantes e complexos estavam sendo feitos e custava muito dinheiro corrigir as falhas do projeto já disponível no mercado. Era mais lucrativo achar os erros antes, durante o planejamento e produção do produto do que depois de vendido. Charles Baker, em 1957, afirma que é necessário desenvolver testes para que o software atenda os requisitos projetados. Assim como a funcionalidade que o programa deve ter.

 

 

3 período:

Nome:destruição

Data: 1979–1982

Em 1979 surge uma grande revolução de testes provocada pelos novos conceitos trazidos pelo Glenford J. Myers que se resume nessa frase:

Até então todos os testadores e a área de qualidade buscava mostrar que o software era perfeito livre de falhas, mas segundo Myers com esse pensamento nada era testado direito porque inconscientemente os dados de testes sempre seriam os que não resultariam em nenhuma falha. Com o outro pensamento proposto por ele os dados de teste devem ser os que causam falhas no software, pois ele é falho. O que garante uma maior cobertura de teste resultando em mais bugs encontrados e aumentando a qualidade do software.

 

 

4 período:

Nome:avaliação

Data: 1983–1987

Aqui há uma evolução do testador, o teste passa a ser considerado parte fundamental junto com a análise e revisão do ciclo de vida do software. Ou seja, o testador terá que entender os requisitos do software que irá testar. Essa nova metodologia tinha o objetivo de melhorar a avaliação do software conforme seu desenvolvimento avança. Nesse mesmo período as ferramentas de testes automatizados começam a aparecer, mostrando tamanha importância que os testes contraíram. Embrião do testador 2.0 nasce nessa época.

 

 

5 período:

Nome: prevenção

Data: 1988 — presente

Nos anos atuais os testes estão presentes desde do planejamento do software, tudo buscando a prevenção de falhas no mesmo. Mas da onde surgiu essa metodologia? Em 1988 William Hetzel publicou seu livro intitulado “ The Growth of Software Testing ”, que redefiniu todo o processo de testes de software e até mesmo os ambientes em que são feitos. Definitivamente os testadores 2.0 e 3.0 surgem com força aqui, mas quem são eles?

 

 

Testador: 1.0, 2.0 e 3.0

 

Vimos que muitos conceitos e metodologias surgiram ao longo da história do teste de software, incluindo testadores 1.0, 2.0, e 3.0. Vamos começar pelo 1.0, podemos ver que esse testador estava inserido num contexto em que o ciclo de desenvolvimento seguia estágios, que só avançavam se o anterior já estivesse finalizado. Isso fazia os testadores se isolarem do resto da equipe, pois geralmente o teste do software era a última etapa. Então não tinham conhecimento de todo o software. Os times de desenvolvimento eram tradicionais ou seja, cada um cuida somente da sua área e a comunicação era burocrática acontecendo por documentação oficial.

 

Dá para perceber que isso não durou muito tempo teria que ter uma evolução, surge então o 2.0 inserido num novo ambiente chamado ágil. A divisão de times é extinta, a equipe agora é multidisciplinar. A comunicação passa a ser fundamental, e a qualidade e os testes estão presentes desde do planejamento do software. Ainda é necessário um membro da equipe ser especialista em teste de software, mas ele também para se adaptar ao método ágil tem que aprender novos conhecimentos como negócio. Então o testador terá que saber de tudo? Não, isso é definido pela equipe em que está presente ou por ele mesmo, mas precisa ter profundos conhecimentos em teste de software e em outros novos conhecimentos. É o chamado T-Shape.

E para onde o testador evoluiu no 3.0? Agora ele se especializa na área de teste e também em outros conhecimentos, fazendo uma multidisciplinaridade. Existem por exemplo: o testador com foco em análise de negócios, o testador focado em arquitetura de software entre outros.
 
 

Engenheiros de Software

 

De todas esses conceitos e metodologias podemos concluir o seguinte: não é mais necessário nomenclaturas nos times de desenvolvimento como analista de requisitos, arquiteto de software, analista de testes, todos estão convergindo para engenheiros de software. Então o testador morreu! Mas permanece vivo como uma especialidade do engenheiro de software, que pode entender muito da área de teste de software, ser especialista nela, mas tem a capacidade de realizar qualquer tarefa durante o processo de desenvolvimento do software. 

 

Por exemplo, um engenheiro de software com ênfase em testes, pode pegar uma tarefa de UX design. A equipe mudou e se tornou tão flexível que todos os membros sabem uniformemente do projeto, ficaram mais “livres”. O projeto não depende de uma só pessoa, mas sim do conjunto.

Como eu estudo tantas áreas ao mesmo tempo? Para organizar seus estudos ou da equipe surgiu o modelo fractal de conhecimento dentro dos times ágeis. Observe a imagem abaixo.

 
Image for post
 

Nesse fractal cada pedaço se torna uma competência ou skill, a maior área será a especialidade do engenheiro, na imagem é teste de software. O segundo maior pedaço que corresponde a 50% do primeiro é a segunda skill escolhida pelo engenheiro que mais ele vai dominar, a próxima que corresponde a 25% da primeira é a terceira skill que ele vai praticar e assim sucessivamente. 

Formando se uma escada de conhecimento do maior ( mais especializado) para o menor (menos especializado). Isso pode mudar conforme o time necessita ou pela própria vontade do engenheiro.

Em um time podemos ter uma equipe composta por diversos conhecimentos, seguindo as necessidades do projeto. Veja as imagens abaixo:

 

Image for post

Mas qual linha de raciocínio eu sigo? Pegando a principal parte do fractal que no nosso caso é testes eu aconselho seguir a seguinte linha de estudos observada na imagem abaixo:

 

Image for post

Fundamentos do testes de software: Inclui toda a base teórica desde da história até os tipos de testes e como planejá-los e suas técnicas. Livro recomendado: Introdução ao Teste de Software Marcio Delamaro e os livros do autor Leonardo Molinari. Curso: Início rápido em teste de software da Iterasys. É aconselhável também a leitura do Syllabus da CTFL, CBOK do QAI e TMap Next da Sogeti.

 

Seguindo o fractal criado para testes todas as outras partes são os tipos de testes como web, mobile e API. Entenda o que é o tipo de teste em questão. Faça os cursos de automação para aquele tipo de teste.

 

Lembrando que esse fractal de teste é uma sugestão mude conforme sua necessidade e seus interesses. Outro exemplo que pode-se fazer é baseado no ISTQB, que divide o fractal de testes em Agile, Core e Specialist. Fique a vontade para decidir qual usar ou crie o seu próprio fractal de teste. Sugestão: realize muitas pesquisas para poder montar sua grade de estudos. Em relação às outras partes do fractal do engenheiro como Dev, Negócio e UX faça pesquisas e decida qual melhor linha de estudo seguir em cada tema assim como cursos e livros. Lembre-se da escada do conhecimento o quanto você irá dedicar seu tempo a cada uma das partes. Tire mais tempo para estudar testes de software que será a sua especialidade.