.png)
Como Amadurecer o Processo de Testes
Como Amadurecer o Processo de Testes
Por: Fernando Palma
Maio, 2007
_______________________________________________________
Segunda Fase: plano de testes produzido pelo profissional de testes
Com pouco tempo, o homologador amadurecerá e criará segurança para idealizar diversos casos de testes. O resultado disso serão planos com grande dimensão de mudanças sob a atividade de peer-review. Neste instante, o mais natural é o surgimento da Segunda Fase. A melhoria imediata será responsabilizar o artefato do plano de testes ao próprio homologador, que por essa atribuição começará a se comportar como analista de testes. Ele será acionado em algum momento da produção da especificação, para ir compondo seu documento. O analista do sistema servirá então de apoio para esclarecer quaisquer dúvidas referentes às regras, e se tornará o novo responsável pelo peer-review do plano. Esta é a passagem mais importante de toda a evolução e dependerá do bom desempenho do profissional de testes.
Ex: o analista de testes faz a leitura da seguinte passagem de especificação
.O usuário informa a data inicio e data fim que deseja procurar.
.O sistema retorna todos os registros cadastrados entre as datas informadas.
Neste momento, ele constrói os seguintes casos de teste:
(Para ampliar , basta clicar sob a imagem)
E quantos mais casos de testes forem necessários.
Terceira Fase: analista de testes no inicio da especificação e verificações de documentos
A ultima etapa será trazer os testes para a especificação. Isso deve acontecer quando o analista de testes começar a encontrar e criticar erros desde a construção do plano de testes. Como isso é possível? É simples: as falhas são previstas desde a leitura da especificação. É comum isso ocorrer á medida que ele for ganhando uma boa experiência. Justamente porque, existem erros que se repetem, exceções que deveriam ser levantadas e não foram escritas pelo analista, além de falhas nas regras de negócio, contradições, omissões. Finalmente, o profissional de testes estará desempenhando o seu verdadeiro papel, que é descobrir erros o mais cedo possível. A partir deste ponto, poderá participar desde a reunião inicial do projeto e produzir seus requisitos de testes baseados nos requisitos de análise. À medida que os artefatos de especificação forem sendo produzidos, atuará para cruzar todos os seus requisitos de testes com a especificação. O alinhamento entre as documentações trará como resultado sistemas com qualidade bastante superior.
Ex: O analista de testes tem conhecimento da existência de um campo de e-mail no cadastro de usuário. Imediatamente, ele cria um caso de teste que exija uma validação do campo de e-mail (aceitar apenas e-mails válidos). Quando finalmente consulta os fluxos de exceção do caso de uso, nota que não existe uma exceção levantada para o cadastro de e-mails inválidos. Então é adicionado um erro de especificação “Criar fluxo de exceção para cadastro de e-mails inválidos”.
Toda esta evolução está fortemente ligada à dedicação e talento do profissional de testes, até porque não existirão apenas regras de negócios simples como as que foram exemplificadas. Mas é impraticável chegar a sistemas com boa qualidade sem que o processo seja ampliado, permitindo a execução de testes antes, durante e depois do desenvolvimento. Enquanto não existir a participação de um especialista em testes desde o início do projeto, não é será possível ter um processo amadurecido.
A transformação profissional do testador e as mudanças de regras descritas são possíveis, simples de implementar e altamente lucrativas. O custo de um erro encontrado depois da construção de código é, em média, cem vezes maior que o custo do mesmo quando visualizado na especificação. Pular etapas de testes para cortar custos é contraditório. As fábricas de software que experimentam algumas mudanças chegam sempre às mesmas conclusões: optar por testar somente no fim é ineficaz, gera mais gastos, e ainda induz ao maior de todos os prejuízos: a insatisfação do usuário.
Por: Fernando Palma
Maio, 2007
_______________________________________________________
Apesar do crescimento da área de testes de software, ainda é difícil encontrar profissionais experientes e capacitados, justamente por ser uma cultura recente no país. Em muitas empresas, os conceitos de qualidade de software estão distantes de uma maturidade desejada. Existem omissões de etapas de testes e falta de comprometimento com a qualidade dos sistemas. Como conseqüência, encontramos produtos de baixa confiabilidade e gastos desnecessários em razão a descobertas de erros tardias. Este Artigo tem o objetivo de ajudar quem pretende melhorar o seu processo de desenvolvimento e produzir com maior qualidade através do estímulo ao crescimento de seus profissionais de testes.
É comum encontrarmos modelos de fabricas de software que adotem apenas um homologador, qual participa paralelamente ao desenvolvimento do sistema, testando tela por tela, e encaminhado os erros imediatamente aos programadores. A isso, acrescenta-se o fato de que ele inicia sua atividade sem o conhecimento do negócio e, em alguns casos, ausente de um plano de testes. Os prejuízos gerenciais causados por este método já foram abordados no artigo Execução de Testes e Gerencia de Testes. Agora, serão focadas algumas práticas no processo, divididas em alguns passos, que trazem uma boa evolução. Passando por isso, será atingido um patamar em que os testes sejam realizados em todo o ciclo de produção do sistema.
Uma vez que, seria inviável realizar uma quantidade grande de mudanças em um prazo curto, a proposta é que sejam feitas pequenas alterações, graduais, induzindo um processo natural de amadurecimento. Para isso, foram denominadas três fases:
Primeira Fase: plano de testes e homologador como peer-review
O primeiro objetivo é criar um plano de testes para ser usado pelo Homologador assim que inicie seu trabalho. Mas o avanço não para por ai. O homologador ganhará também a função de Peer-review deste artefato, que deve ser feito antes do desenvolvimento do sistema. Esta simples atribuição, além de exigir dele que estude toda regra de negócio, ainda irá incentivá-lo à imaginação e criação de cenários de testes, não vistos pelo analista do sistema. Assim, o plano produzido, alinhado ao trabalho dos dois, tenderá a trazer melhores resultados imediatos.
Ex: em uma tela de login de usuário, existem os campos login e senha. Os seguintes casos de testes foram construídos pelo analista:
É comum encontrarmos modelos de fabricas de software que adotem apenas um homologador, qual participa paralelamente ao desenvolvimento do sistema, testando tela por tela, e encaminhado os erros imediatamente aos programadores. A isso, acrescenta-se o fato de que ele inicia sua atividade sem o conhecimento do negócio e, em alguns casos, ausente de um plano de testes. Os prejuízos gerenciais causados por este método já foram abordados no artigo Execução de Testes e Gerencia de Testes. Agora, serão focadas algumas práticas no processo, divididas em alguns passos, que trazem uma boa evolução. Passando por isso, será atingido um patamar em que os testes sejam realizados em todo o ciclo de produção do sistema.
Uma vez que, seria inviável realizar uma quantidade grande de mudanças em um prazo curto, a proposta é que sejam feitas pequenas alterações, graduais, induzindo um processo natural de amadurecimento. Para isso, foram denominadas três fases:
Primeira Fase: plano de testes e homologador como peer-review
O primeiro objetivo é criar um plano de testes para ser usado pelo Homologador assim que inicie seu trabalho. Mas o avanço não para por ai. O homologador ganhará também a função de Peer-review deste artefato, que deve ser feito antes do desenvolvimento do sistema. Esta simples atribuição, além de exigir dele que estude toda regra de negócio, ainda irá incentivá-lo à imaginação e criação de cenários de testes, não vistos pelo analista do sistema. Assim, o plano produzido, alinhado ao trabalho dos dois, tenderá a trazer melhores resultados imediatos.
Ex: em uma tela de login de usuário, existem os campos login e senha. Os seguintes casos de testes foram construídos pelo analista:
(Para ampliar , basta clicar sob a imagem)
No momento em que analisou este plano, o homologador visualizou outros casos de testes:
(Para ampliar , basta clicar sob a imagem)
E assim por diante.
Segunda Fase: plano de testes produzido pelo profissional de testes
Com pouco tempo, o homologador amadurecerá e criará segurança para idealizar diversos casos de testes. O resultado disso serão planos com grande dimensão de mudanças sob a atividade de peer-review. Neste instante, o mais natural é o surgimento da Segunda Fase. A melhoria imediata será responsabilizar o artefato do plano de testes ao próprio homologador, que por essa atribuição começará a se comportar como analista de testes. Ele será acionado em algum momento da produção da especificação, para ir compondo seu documento. O analista do sistema servirá então de apoio para esclarecer quaisquer dúvidas referentes às regras, e se tornará o novo responsável pelo peer-review do plano. Esta é a passagem mais importante de toda a evolução e dependerá do bom desempenho do profissional de testes.
Ex: o analista de testes faz a leitura da seguinte passagem de especificação
.O usuário informa a data inicio e data fim que deseja procurar.
.O sistema retorna todos os registros cadastrados entre as datas informadas.
Neste momento, ele constrói os seguintes casos de teste:
(Para ampliar , basta clicar sob a imagem)
E quantos mais casos de testes forem necessários.
Terceira Fase: analista de testes no inicio da especificação e verificações de documentos
A ultima etapa será trazer os testes para a especificação. Isso deve acontecer quando o analista de testes começar a encontrar e criticar erros desde a construção do plano de testes. Como isso é possível? É simples: as falhas são previstas desde a leitura da especificação. É comum isso ocorrer á medida que ele for ganhando uma boa experiência. Justamente porque, existem erros que se repetem, exceções que deveriam ser levantadas e não foram escritas pelo analista, além de falhas nas regras de negócio, contradições, omissões. Finalmente, o profissional de testes estará desempenhando o seu verdadeiro papel, que é descobrir erros o mais cedo possível. A partir deste ponto, poderá participar desde a reunião inicial do projeto e produzir seus requisitos de testes baseados nos requisitos de análise. À medida que os artefatos de especificação forem sendo produzidos, atuará para cruzar todos os seus requisitos de testes com a especificação. O alinhamento entre as documentações trará como resultado sistemas com qualidade bastante superior.
Ex: O analista de testes tem conhecimento da existência de um campo de e-mail no cadastro de usuário. Imediatamente, ele cria um caso de teste que exija uma validação do campo de e-mail (aceitar apenas e-mails válidos). Quando finalmente consulta os fluxos de exceção do caso de uso, nota que não existe uma exceção levantada para o cadastro de e-mails inválidos. Então é adicionado um erro de especificação “Criar fluxo de exceção para cadastro de e-mails inválidos”.
Toda esta evolução está fortemente ligada à dedicação e talento do profissional de testes, até porque não existirão apenas regras de negócios simples como as que foram exemplificadas. Mas é impraticável chegar a sistemas com boa qualidade sem que o processo seja ampliado, permitindo a execução de testes antes, durante e depois do desenvolvimento. Enquanto não existir a participação de um especialista em testes desde o início do projeto, não é será possível ter um processo amadurecido.
A transformação profissional do testador e as mudanças de regras descritas são possíveis, simples de implementar e altamente lucrativas. O custo de um erro encontrado depois da construção de código é, em média, cem vezes maior que o custo do mesmo quando visualizado na especificação. Pular etapas de testes para cortar custos é contraditório. As fábricas de software que experimentam algumas mudanças chegam sempre às mesmas conclusões: optar por testar somente no fim é ineficaz, gera mais gastos, e ainda induz ao maior de todos os prejuízos: a insatisfação do usuário.
Fernando, é bem por aí o que eu havia falado. Fica claro para mim que, independente do tamanho da organização, deve haver alguém dedicado aos testes.
ResponderExcluirOk, Lucio, que bom que toquei no assunto de seu interesse.
ResponderExcluirAté mais!
Muito bom Fernando!
ResponderExcluirGosto muito deste assunto. Um detalhe que uso com a minha equipe de desenvolvimento é "quando efetuar os testes pra valer". Considerando que um pedreiro, na construção civil, conclui a sua obra somente após estar com a parede levantada, na medida/inclinação combinada e rebocada, usando o material adequado. Logicamente, após ter seguido todo esquema do projeto estrutural, elétrico, hidráulico, entre outros. Instruímos o nosso pessoal a fazer os testes dos programas desenvolvidos somente após estar com todos os itens preparados, ou seja, construídos. Tendo conferido requisitos, padrões de programação e planos de testes. Também, acostumo dar o exemplo do confeiteiro: vamos colocar o bolo para assar somente depois que estiver com todos os ingredientes apropriadamente acondicionados na forma. Depois que a assadeira entrar no forno não teremos como voltar para colocar mais farinha porque a medida estava incorreta. Testar sistemas sempre será uma tarefa imprescindível tanto quanto a própria programação.
Sucessos!
Este comentário foi removido pelo autor.
ResponderExcluirMarco,
ResponderExcluirgostei muito das suas analogias, com certeza ainda irei usá-las.
Bom, o proximo Artigo vai abordar o mesmo tema sob o angulo do custo, aguarde!
E obrigado pela visita e comentário!
Até mais,
Fernando Palma.