Autor: Edwagney Luz
Revisora: Keite Moraes
Tabela de conteúdo |
Atualmente vivemos em um mundo onde os negócios possuem uma grande dependência pela TI (Tecnologia da Informação) e à medida que esse fator aumenta, também cresce a produção de software e complexidade dos sistemas.
Um exemplo é quando um risco operacional da TI se propaga para os negócios, deixando de ser um risco da TI, passando a ser um risco do negócio, ou seja, se uma falha ocorrer nos sistemas, consequentemente ocorrerá uma falha nos negócios. Desta forma, torna-se fundamental o desenvolvimento de software com mais qualidade e confiabilidade. Neste capítulo será abordado o porquê se devem ter profissionais qualificados na elaboração e execução de testes.
Durante a discussão desse tema, diversos integrantes do grupo DFTestes colocaram suas opiniões e suas experiências, seja obtido de suas empresas ou em participações em projetos. Dessa discussão chegamos a alguns pontos interessantes, que trataremos no decorrer deste capítulo.
No exposto por (Rezende, 2005) e descrito na introdução deste capítulo, chama a atenção o trecho onde diz que a documentação serve para orientar e treinar o cliente na operação do sistema. Esse é um enfoque interessante, visto que sem a documentação seria um tanto quando complicado passar essa orientação e treinamento ao cliente. Pensando em Teste de Software, para que serve então a documentação?
“Ajuda o entendimento do sistema, quando você cria a documentação de Teste de Software, você entende melhor o sistema e ainda abstrai as informações para o mundo do Teste de Software” (Fabrício Ferrari)
Vocês podem observar que, em outras palavras usamos a documentação de teste com o mesmo objetivo que levamos ao cliente. Entretanto, isso vai além. Ela não pode e não deve ser considerada apenas um guia para orientação e treinamento.
Ela deve ser tratada como sendo um referencial para o projeto de software, como o compartilhamento de informações entre os diversos times que compõe um projeto. É a documentação que tem o poder de dar consistência e credibilidade ao projeto. (Ambler, 2002), expõe um raciocínio interessante. O software é o produto principal de um projeto, e afirma que ter esse software funcionando é o principal objetivo desse projeto e a produção de documentos ou artefatos gerenciais irrelevantes não é o foco. A equipe de desenvolvimento desenvolve softwares e não documentações.
Por outro lado ela também tem a responsabilidade de possibilitar a execução de um possível próximo trabalho. Ele chama de objetivo secundário da equipe de desenvolvimento. Ele afirma que para possibilitar que isso aconteça, a equipe não deve querer apenas desenvolver um software de qualidade, mas também documentação suficiente para que as pessoas que jogarão a próxima partida possam ser tão ou mais eficientes do que a equipe anterior, pois transferem habilidades para a equipe posterior, além de motivar o pessoal já existente a permanecer na equipe e desenvolver uma próxima versão.
Usando esse raciocínio, podemos perfeitamente transferi-lo para a equipe de teste, que em nada difere de uma equipe de desenvolvimento. Se uma equipe de desenvolvimento tem como principal responsabilidade desenvolver software, de forma análoga uma equipe de teste tem como principal atividade desenvolver testes, e como atividade secundária, não basta apenas desenvolver testes com qualidade e que encontrem o maior número de defeitos, é necessário também documentar esses testes para que outra equipe possa, no futuro, garantir a mesma qualidade que foi garantida na primeira execução de teste no projeto.
Outro ponto levantado na discussão da mesa redonda é sobre a solicitação do cliente, onde tudo depende da solicitação dele. Se ele exige documentação de Teste de Software, a equipe tem o conhecimento sobre o sistema e o prazo para teste é curto, documentações são desnecessárias, e o teste a ser realizado seriam apenas usando técnicas de teste exploratório. O que é um assunto bem controverso, visto que a equipe de teste é a que deve ou deveria zelar pela qualidade do produto e este inclui o software e sua documentação. Assumir esse tipo de situação seria o extremo do extremo. Sugere-se fazer um estudo sobre a viabilidade de documentação, documentar por documentar, pode tornar-se perda de tempo, e consequentemente ocasionará perda de dinheiro.
Concluímos que documentar é preciso, porém com muito bom senso e que a mesma tenha uma finalidade, caso contrário estaríamos perdendo um precioso tempo que poderia ser utilizado para a melhoria da qualidade do produto. Mas quando é preciso documentar? Abaixo listamos alguns pontos levantados durante a discussão:
E quando documentar não é preciso?
Percebemos que nesse caso, todos os itens são uma consequência do item um, portanto, a primeira regra de utilidade é a primeira coisa que deve ser levantada no processo de decisão de se elaborar ou não um determinado documento.
Todos concordam que esse é um tremendo de um desafio, visto que antes é necessário convencer as equipes da necessidade de se documentar. Mas podemos simplificar essa tarefa, como algumas pessoas propuseram conforme descrito abaixo:
Como vimos no item anterior, devemos apenas gerar uma documentação quando temos certeza de que será lida. Elaborar documentos apenas com o intuito de documentar detalhadamente determinada atividade, mas que de nada vai adiantar para o projeto ou projetos futuros, estaremos além da perda de tempo, consumindo recursos de armazenamento que poderão fazer falta no futuro e tempo desnecessário de profissionais para simplesmente organizar e manter as informações em repositório. Elaborar documentação deve antes passar pelo crivo de identificar para qual necessidade vamos armazenar tal informação.
De acordo com o Guia de Implementação – Parte 10: Implementação do MR-MPS em organizações do tipo Fábrica de Teste (SOFTEX, 2009), as informações que devem ser armazenadas para qualquer projeto são: relatórios informais; estudos e análises; atas de reuniões; lições aprendidas; artefatos gerados; itens de ação; e indicadores. As informações podem estar armazenadas nos diversos meios de armazenamento como papeis impressos, fotografias, desenhos, eletrônicos e multimídia.
O guia também prega que as informações relevantes devem ser observadas primariamente, ou seja, devemos sim documentar, porém o que for mais relevante ao projeto. Vimos que essa informação é compartilhada por todas as fontes citadas nesse capítulo e com base nisso chegamos ao seguinte questionamento. Em teste, quais documentações então devem ser geradas para o armazenamento das informações?
De acordo com o discutido pelos integrantes da mesa redonda, várias documentações são utilizadas, dependendo da forma em que a empresa ou o projeto se porta em relação ao teste. Entretanto, colhendo dados durante a discussão, encontramos comumente entre todos os integrantes os seguintes documentos, que podemos dizer que podem seguramente serem considerados como sendo documentações que guardam informações relevantes ao teste de software. São eles:
Esse conjunto de artefatos em geral é aplicado em projetos de teste que possui um nível de criticidade alto, pois necessitam de maior controle e armazenamento de informações. E nesse caso descrever de forma sucinta a estratégia, riscos, ambientes, recursos, relatórios periódicos e detalhados de execução, são informações extremamente relevantes, não só para o projeto atual, mas principalmente projetos futuros.
Para projetos com menor criticidade, somente os relatórios de testes são exigidos, principalmente para evidenciar os testes realizados. E na maioria dos casos pelos próprios desenvolvedores. Mas tudo isso faz parte de uma estratégia de melhoria dos processos, que devem visar sempre alcançar níveis mais elevados de maturidade.
Sugere-se que a documentação deve ser mais simples possível, mas que permita o registro das informações que a organização considera imprescindíveis. E nessa análise cada organização deve definir sua documentação básica, mas deve também explicitar aos seus colaboradores os objetivos a serem alcançados e as estratégias utilizadas, para que consiga da equipe o comprometimento e a motivação necessários.
No decorrer da discussão, surgiram algumas reflexões no sentido de melhoria do processo de teste, que não poderiam ficar de fora dessa coletânea de informações.
Uma dessas reflexões que chamou a atenção dos componentes da mesa foi relativa ao tratamento dos requisitos. Ao invés de criar casos de teste, basear os testes nos requisitos ou “user stories”. Essa abordagem gerou controvérsia entre os integrantes no sentido de acreditarem não ser uma boa ideia a criação única de documento de requisitos direcionado para teste. Alguns acreditam que a criação dos casos de teste continua sendo necessário, mesmo que os requisitos sejam elaborados tendo a visão do teste. Melhorar a elaboração e gerência dos requisitos é uma tarefa a ser considerada sempre, mas não elaborar os casos de teste pode ser um risco para a qualidade do projeto, visto que o documento de requisitos e casos de teste possui diferentes significados.
Outra reflexão interessante é se, ao invés, de requisitos, documentarmos apenas os testes? Colocarmos as solicitações do cliente não como requisitos, mas como cenários de teste. Será que perderíamos algo?
De acordo com os praticantes do BDD (Behaviour Driven Development), costumam dizer que existe a possibilidade de utilizá-lo para detalhar os requisitos funcionais e nesse caso já estaríamos documentando e escrevendo um teste. É possível que não percamos nenhuma informação no caminho, entretanto corremos o risco de ter que detalhar muito cedo as informações de um projeto. Nesse momento a equipe ainda não está madura o suficiente para realizar esse detalhamento e em alguns casos nem mesmo o cliente tem esse nível de maturidade no projeto.
Em relação à abordagem TDD (Test-Driven Development), como ficaria a documentação de teste? Seria dispensável ou seria apenas em nível de Teste de Unidade? Possivelmente os documentos de teste continuariam sendo gerados, principalmente se no projeto existirem papéis específicos para a atividade de teste. Continuariam sendo desenvolvidos testes manuais e que em determinados projetos terão a necessidade da elaboração de documentações tradicionais em outras abordagens.
No decorrer da discussão dessa mesa redonda, pudemos perceber vários pontos de vista e várias abordagens diferentes quanto à elaboração e tratamento da documentação a ser elaborada em um projeto. Alguns optam pela elaboração vários tipos de documentos, outros optam por uma quantidade menor. Isso depende do tamanho e da criticidade projeto. Quando maior e mais crítico, maior nível de detalhamento é exigido.
Entretanto o ponto em que todos concordam e isso vem ao encontro do que pregam as referências usadas como base teórica deste texto, foi que a documentação só é necessária quando existirem informações relevantes e que realmente sejam importantes de serem armazenadas. Caso contrário não faz muito sentido a elaboração de documentação. Analisar a informação que se deseja armazenar e o objetivo pelo qual se destina, é o primeiro passo e a primeira reflexão a ser feita antes de se iniciar a elaboração de qualquer documentação.
<- Voltar para o capítulo anterior | Ir para o próximo capítulo ->
[1] Ambler, S. W. (2002). Modelagem Ágil: Praticas Eficazes para a Programação eXtrema e o Processo Unificado. Porto Alegre - RS: Bookman.
[2] Rezende, D. A. (2005). Projeto de Documentação. In: D. A. Rezende, Engenharia de Software e Sistemas de Informação (p. 275). Rio de Janeiro: Brasport.
[3] SOFTEX. (Outubro de 2009). MPS.BR - Melhoria de Processo do Software Brasileiro - Implementação do MR-MPS em organizações do tipo Fábrica de Teste.