The Bug Bang Theory

(2 votes, average: 10,00 out of 10)

 Loading ...

Meio estranho o título para um blog de tecnologia não?

Mas o ET que estou falando não é o nosso popular amigo de dedo brilhante, nem os assustadores (pelo menos eram para ser) monstros de Hollywood.

Estou falando de um papel que muitas vezes não é explícito nos nossos processos e que se fosse mais explícito e mais valorizado, nossos processos de produção de software seria muito beneficiado.

O papel de Engenheiro de Testes ou Arquiteto de Teste é um papel no mínimo recomendado para que um projeto de produção de software seja entregue com padrões satisfatórios de qualidade.

A necessidade desse papel está diretamente vinculada a complexidade dos requisitos, especialmente dos requisitos não funcionais e do ambiente do sistema.

Se pesquisarmos no glossário do ISTQB, não temos uma declaração explicita para esse papel, nem mesmo nos Syllabus, mas o RUP descreve um pouco desse papel com o nome de Designer de Teste com a seguinte definição:
Designer de Teste: Essa função é responsável por definir a abordagem de teste e assegurar sua correta implementação. Isso inclui identificar as técnicas, ferramentas e diretrizes apropriadas para implementar os testes necessários e fornecer orientação sobre os correspondentes requisitos de recursos para o esforço de teste.Em algumas culturas em desenvolvimento, essa função é referida como Arquiteto de Teste, Arquiteto de Automatização de Teste ou Especialista em Automatização de Teste.

Mas para o RUP, esse profissional ainda está muito vinculado a automação de teste, o que de certa forma é verdade se levarmos em consideração que a maioria dos testes de requisitos não funcionais estão ligados a automação.

Mas e se pensarmos no papel de Engenheiro/Arquiteto de Testes como uma versão do ponto de vista de Controle de Qualidade do arquiteto de Software?

A definição do Arquiteto de Software segundo o RUP é:
->Essa função orienta o desenvolvimento da arquitetura de software do sistema, que inclui promoção e criação de suporte para as principais decisões técnicas que limitam o design e a implementação gerais para o projeto.

Logo o nosso Arquiteto de Testes seria um profissional responsável por boa parte das decisões técnicas do como os testes devem ser realizados. O profissional responsável por escolher as ferramentas mais adequadas, treinar a equipe que irá executar e desenvolver os casos de teste, ajudar na definição de uma massa de teste, selecionar o formato das suítes de teste, definir o nível de detalhamento dos casos de teste, ajudar a definir a complexidade e prioridade de cada caso de teste, entre outras atribuições.

Quem se habilita a ser um Engenheiro de Testes? Ou melhor, o que é preciso para ser um BOM engenheiro de testes?

•O Engenheiro de Teste assim como o Arquiteto de Software é um profissional que está acima de qualquer Tecnologia, Metodologia ou Suíte de Ferramentas. não tem “religião”. Deve ser neutro, calculista e possuir vasta experiência em todas essas verticais. Um profissional que domine bem a poderosa suíte de ferramentas de engenharia de software da IBM Rational não é simplesmente por esse fator um profissional habilitado em testes de performance, modelagem de dados, engenharia de requisitos e etc. O mesmo se aplica a um profissional que acredita que uma metodologia, seja ela RUP, SCRUM ou qualquer outra, é a melhor em todos as ocasiões. Para um Engenheiro de Testes não existe o melhor universal, existem opções que podem ser combinadas para cada modelo de projeto. Ele acredita na idéia de um projeto ser uma entidade viva, com características próprias, as vezes únicas, que devem ser estudadas, entendidas e suas soluções arquiteturadas e aprovadas por provas de conceitos.

•O Engenheiro de Testes tem vivencia em muitos projetos, dos mais diferentes tipos, de “simples” sistemas de padaria, catraca e controle de acesso a portais eletrônicos de compra, sistemas de bilhetagem e controladores de vôo por exemplo.

•O Engenheiro de Teste é um estudante assíduo das novas tecnologias, de TODAS as disciplinas de engenharia de software, do mercado de fornecedores de ferramentas de teste dos mais diversos e sua pedra angular é a Engenharia de Software.

•O Arquiteto de Testes programa tão bem quanto um desenvolvedor e tem uma excelente capacidade de compreensão de requisitos, assim como possui uma ótima capacidade de identificar requisitos não-funcionais, compreende-los e examinar as soluções propostas de forma crítica e analítica.

•O Engenheiro de Testes é um profissional proativo, crítico por natureza, visionário e ousado. A missão dele deve ser a integridade da qualidade para o SISTEMA e não somente para o SOFTWARE.

•O Engenheiro de Testes é um profissional criativo e oportunista, vislumbra soluções inteligentes em teste para cada tipo diferente de produto de software.

•Deve ter espírito de liderança e ter uma excelente desenvoltura ao lidar com pessoas, ser organizado, metódico e sistemático.

Um artigo que achei muito interessante tratando da relação entre Arquiteto e Líder técnico é o artigo The Seven Leg Sheep do Gerrit Muller, que descreve as macro e micro categorias de características técnicas que um profissional nesses papeis possui. Uma versão crítica em português muito boa está disponível em http://blog.arkhi.com.br/2008/11/03/a-ovelha-de-sete-pernas/.

Acredito que a mesma relação feita nesse artigo também é valida para Engenheiro de Teste e Coordenador de Teste, como na figura abaixo que representa uma relação Arquiteto de Software X Líder Técnico.

Quanto mais uma empresa investe em teste, mais ela investe em qualidade, não só do produto, mas também das suas pessoas, dos seus processos, consequentemente na qualidade da sua imagem e dos seus clientes. Uma equipe de teste de software pode trazer ganhos fantásticos, conhecimento partilhado, melhoria continua de processos, novas formas de fazer atividades, novas ferramentas etc. Após uma quantidade X de investimento em testes Funcionais, uma empresa de médio porte já começa a ter projetos que exigem novos padrões de qualidade e cada vez mais os requisitos não funcionais tem sido fator de falha em excelentes projetos de software com poucos “bugs”.

Engenharia de Teste de Software já existe, implicitamente em todos os projetos. A questão é que quando tornamos isso explicito ganhamos uma nova forma de garantir que os requisitos como um todo sejam atendidos, temos um processo de teste sob medida (ou pelo menos mais realista) para o projeto e consequentemente temos um produto com uma qualidade mais próxima do esperado.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

1. William disse:

   18 de março de 2010 às 17:48

   Gostei do ET, e do blog! Suesso!
2. William disse:

   18 de março de 2010 às 17:49

   Sucesso!!!