Há alguns anos o papel do testador ou Analista de Testes era limitado à documentação, relatórios e testes manuais. Mantinha proximidade com o Analista de Requisitos ou Gerente de Projetos e, a partir dos requisitos do sistema, começava a tarefa de transformar os casos de uso do sistema em casos de testes. Esses, por sua vez, eram compilados em um documento que serviria de base para acompanhar suas execuções, como uma checklist que deveria ser validada a cada versão do sistema.
Esse compilado é conhecido como Plano de Testes que, além de conter todo esse passo-a-passo, também tinha outras informações importantes para a condução dos testes, como: escopo, configurações de ambiente, dados que compunham a massa de testes a ser utilizada, papéis e responsabilidades dos envolvidos, datas para a execução, janelas de manutenção, dicionário de dados, métricas e uma infinidade de informações que serviriam de apoio a essa etapa tão fundamental no ciclo de vida de software.
Exemplo de um Caso de Teste:
A quantidade de casos de testes poderia chegar facilmente à centenas, dependendo da complexidade do sistema. Muitas vezes, essa documentação era mantida em arquivos do pacote Office Word (.doc) ou Excel (.xls), o que tornava sua manutenção complicada.
Uma alteração simples no nome do botão deveria ser alterada em dezenas de páginas desse documento. Imagine numa regra mais complexa, algum pré-requisito?
Essa documentação também funcionava como entregas definidas nas atas de reunião e auditorias internas, e essa abordagem de um documento mais rígido era possível graças ao modelo de desenvolvimento que tínhamos majoritariamente nas empresas chamado Cascata. Esse modelo seguia uma linha de fases sequenciais ou, como o próprio nome representa, uma cascata.
Representação do modelo Cascata:
Em algum momento nesse período, começaram a surgir as primeiras ferramentas exclusivas para automação de testes e outras que permitiam mais flexibilidade no cadastro e manutenção dos planos de testes e registros de bugs. Algumas delas surgiram inclusive por empresas como Microsoft e IBM, como IBM Rational, por exemplo.
Em paralelo, as metodologias de desenvolvimento de software caminhavam de forma mais ágil, menos engessadas, com muitas iterações e entregas, e passíveis de mudanças de requisitos constantes. Numa busca rápida na internet, é possível ver milhares de blogs, artigos e livros falando sobre Agile, Lean, SCRUM, Kanban etc. Outras metodologias que introduzem o teste numa etapa antecipada ao código, tem foco no comportamento e/ou domínio de software também começaram a despontar: DDD, TDD, BDD.
Os programadores escreveram seus testes, os times davam os primeiros passos nas metodologias ágeis, e os profissionais de teste de software se introduziram no desenvolvimento, buscando formas de automatizar os repetitivos testes que ocorriam a cada iteração. Era perceptível um movimento de convergência de esforços de todo o time para entregar a máxima qualidade embarcada nos produtos, o que é aplicado nas empresas até hoje, inclusive aqui, na VTEX.
Houve um boom no desenvolvimento web, sistemas SaaS escaláveis e entramos na era mobile first, com isso o escopo de testes não parou de aumentar. Chegamos a um momento em que temos diferentes navegadores web, cada um com suas particularidades, e dois principais sistemas operacionais para dispositivos móveis. Há uma infinidade desses aparelhos com tamanhos de tela e resoluções distintas.
Para acompanhar essas mudanças, serviços de cross-browser e cross-device testing surgiram para ajudar a alavancar os testes automatizados, dando mais velocidade e flexibilidade nos scripts.
Esses serviços têm em comum a disponibilização de uma infraestrutura na nuvem e facilidade em paralelização das execuções dos testes.
Além de diferentes browsers e tamanhos de telas, também é uma preocupação constante a validação entre diferentes versões de um mesmo navegador e/ou sistema operacional. Por exemplo, uma página na internet poderia funcionar perfeitamente numa versão X do navegador, mas falhas ocorrem numa versão Y. Muitas vezes a versão Y deveria ser suportada para o sistema, por questões contratuais, de relacionamento com o cliente ou outras, mesmo que o próprio fabricante não desse mais suporte àquela versão.
Além disso, testes voltados para requisitos não-funcionais também aumentaram. Como exemplo, temos aplicativos de streaming de vídeo que devem continuar funcionando mesmo com baixo sinal da antena de telefonia, sistemas que usam recursos internos dos dispositivos como acelerômetro e uma infinidade de pequenos detalhes que podem aumentar ainda mais o escopo de testes.
Em resumo, nota-se que a complexidade, dimensões e os desafios de teste de software aumentaram em uma velocidade exorbitante e assim seguem.
Toda essa transformação também impactou o perfil do profissional da área de testes de software. Esse profissional está mais capacitado para escrever código, usar ferramentas de DevOps e sistemas de integração contínua, por exemplo.
Essa transformação pode ser facilmente observada através da nomenclatura que ele recebeu no decorrer dos anos. Hoje, temos inúmeros termos para identificar um perfil que, apesar de possuir algumas características distintas nos seus papéis, no fundo é um perfil que compartilha do sentimento de dono do produto e que tem foco na qualidade. Podemos ficar aqui listando diversos: Testador de Software, Analista de Testes, Analista de Qualidade, QA Analyst, Gerente de Testes, Agile Tester, Analista Automatizador de Testes, Automatizador de Testes, Quality Assurance Analyst, Engenheiro de Testes etc.
Aqui na VTEX, um perfil que melhor se enquadra no nosso time é o SET: Software Engineer in Test. Esse perfil ganhou notoriedade através de grandes empresas de tecnologia do Vale do Silício e seria um engenheiro de software com background na área de testes e ênfase no desenvolvimento em sistemas de automação, frameworks e sistemas voltados para teste de software em geral.
Inclusive, temos vaga aberta para SET. Clique e confira.
Estamos cercados de dados e, cada vez mais, aplicações orientadas a dados estão surgindo. Esse tipo de aplicação dificulta o uso de técnicas tradicionais de testes, como Partição de Equivalência ou Análise do Valor Limite, pois as respostas não são necessariamente binárias.
Por exemplo: em aplicações de Inteligência Artificial, Machine Learning, aplicações de reconhecimento de voz, reconhecimento facial e de imagens em geral, como validar que um sistema reconheceu corretamente um gato na imagem? Sabemos que nesses sistemas há falsos positivos e muito background em estatística.
Vamos ter profissionais cada vez mais qualificados para tecnologia embarcada e hardware? Muitos assistentes virtuais estão por vir e com eles muitos desafios de testes.
Capacitação em áreas de estatísticas, data science pode ser um caminho a ser trilhado por esses profissionais. No ritmo em que o mundo de testes de software tem evoluído, é esperado que o profissional da área de testes de software deva continuar se especializando. Afinal, os desafios e responsabilidades estão cada vez maiores.
Quer construir uma carreira à prova do futuro? Confira nossas vagas.
A CCX Company em colaboração com a VTEX Commerce Cloud expressa sua gratidão por ter tido a oportunidade de enriquecer seu entendimento acerca das vantagens, tendências e demais elementos abordados no presente tema. Este artigo foi elaborado pela VTEX Commerce Cloud e é encaminhado até você pela CCX COMPANY
