A importância dos testes no desenvolvimento de sistemas
Autora: Cristina Angela Filipak Machado
Um dos meios utilizadas para se garantir qualidade aos sistemas e evitar surpresas desagradáveis é a atividade de testes. Esta atividade muitas vezes é vista como uma fase de crítica aos analistas e programadores, fazendo com que estes se sintam constrangidos. Mas, se os erros existem, o fato de não se fazer os devidos testes não quer dizer que eles irão desaparecer e, muitas vezes, se esses erros são detectados tardiamente podem causar prejuízo e danos incontroláveis aos sistemas.
Para se garantir a qualidade adequada aos projetos, a metodologia MDS prevê revisões na fase de Planejamento, Projeto Lógico e Projeto Físico, ficando os testes para a fase de Programação. Essa fase de testes deve consumir em torno de 30% do tempo de desenvolvimento do sistema.
O teste parece ser uma coisa simples e empírica, mas na verdade não é. E as falhas, muitas vezes, acontecem por não darmos a devida importância a esse fato.
Fazer o sistema é parte do trabalho, e verificar a "qualidade" e se está fazendo corretamente o que ele se propõe é outra. Do mesmo modo em que hoje o cliente, através da "modelagem participativa", participa ativamente do desenvolvimento do sistema, essa mesma condução deve ser feita com os testes do sistema, pois só o cliente é que poderá dizer se o modelo está certo ou não.
Normalmente, os testes se decompõem em quatro:
- Teste Operacional (conduzido pelo usuário).
- Teste de Sistema (conduzido pelo líder do projeto ou um outro analista).
- Teste de integração (conduzido por programadores ou projetista físico).
- Teste unitário ou de programa (conduzido por programadores).
O teste operacional tem a finalidade de responder à seguinte pergunta: "Foi isso o que eu pedi?". Se escrevermos na proposta de desenvolvimento que o cliente deverá fazer os testes do sistema, isso só reforça o seu comprometimento e faz com que ele se planeje para os recursos que deverão ser consumidos. Eles, os clientes, é que na realidade são os responsáveis por montar o plano de teste e os requisitos que serão exigidos do sistema. Se esse trabalho foi montado logo na fase de análise, ele pode ajudar e muito o analista a chegar à sua proposta de sistema.
O teste de sistema, normalmente, é criado e executado pelo líder do projeto. Há uma tendência em algumas empresas de deixar esse trabalho para outra pessoa, pois existe o fato de ser difícil encontrar falhas nas coisas que se cria.
Mas, independente da pessoa que é responsável por desempenhar essa tarefa, a seguinte pergunta deve ser respondida: "Esse programa/sistema faz o que o usuário quer?" Essa fase é importante, pois, após serem feitos esses testes para a Empresa, o sistema está pronto e os requisitos de qualidade foram atingidos.
O teste de integração é o responsável por testar as várias partes e verificar se elas funcionam juntas, conforme especificação. A pergunta que deve ser respondida é: "Tudo se encaixa?" Essa pergunta relaciona-se ao fluxo de controle entre os módulos, se estão corretos e completos e se os dados que estão sendo passados entre os módulos estão corretos também. Após especificar o teste de integração, deve-se então partir para o teste unitário.
Quanto ao teste unitário, normalmente é desenvolvido enquanto os programas estão sendo feitos.
Ele deve responder à seguinte pergunta: "Será que codifiquei direito?" Ele tem a finalidade de procurar falhas nos programas e verificar se as funções estão sendo executadas corretamente. Para muitos, o compilador governa o teste de unidade, mas é vital processar dados de testes para verificar se os programas fazem exatamente aquilo para o qual foram propostos.
Os planos de testes são desenvolvidos de maneira "top-down" e a sua execução é feita de maneira "bottom-up", iniciando conforme os programas vão ficando prontos e segue até o usuário aceitar o sistema.
Para se planejar e especificar os testes no sistema, existem alguns métodos propostos que estão baseados normalmente em dois fatores: probabilidade e risco. Rotinas complexas ou que possuem uma importância maior devem ser mais testadas.
Existem algumas dificuldades com relação à implantação de testes na CELEPAR, uma delas é o ambiente em que estamos inseridos, que é: produção ou desenvolvimento. O ambiente de desenvolvimento, hoje, suporta bem os testes unitários de integração e de sistema, ficando um pouco prejudicado quando tentamos fazer testes com clientes.
O que precisamos, hoje, é resgatar a importância desses testes, para garantia de qualidade dos sistemas. E isso só é possível introduzindo-se métodos para auxiliar no planejamento e especificação dos mesmos, pois o teste é um item fundamental para o desenvolvimento de sistemas.
Um dos meios utilizadas para se garantir qualidade aos sistemas e evitar surpresas desagradáveis é a atividade de testes. Esta atividade muitas vezes é vista como uma fase de crítica aos analistas e programadores, fazendo com que estes se sintam constrangidos. Mas, se os erros existem, o fato de não se fazer os devidos testes não quer dizer que eles irão desaparecer e, muitas vezes, se esses erros são detectados tardiamente podem causar prejuízo e danos incontroláveis aos sistemas.
Para se garantir a qualidade adequada aos projetos, a metodologia MDS prevê revisões na fase de Planejamento, Projeto Lógico e Projeto Físico, ficando os testes para a fase de Programação. Essa fase de testes deve consumir em torno de 30% do tempo de desenvolvimento do sistema.
O teste parece ser uma coisa simples e empírica, mas na verdade não é. E as falhas, muitas vezes, acontecem por não darmos a devida importância a esse fato.
Fazer o sistema é parte do trabalho, e verificar a "qualidade" e se está fazendo corretamente o que ele se propõe é outra. Do mesmo modo em que hoje o cliente, através da "modelagem participativa", participa ativamente do desenvolvimento do sistema, essa mesma condução deve ser feita com os testes do sistema, pois só o cliente é que poderá dizer se o modelo está certo ou não.
Normalmente, os testes se decompõem em quatro:
- Teste Operacional (conduzido pelo usuário).
- Teste de Sistema (conduzido pelo líder do projeto ou um outro analista).
- Teste de integração (conduzido por programadores ou projetista físico).
- Teste unitário ou de programa (conduzido por programadores).
O teste operacional tem a finalidade de responder à seguinte pergunta: "Foi isso o que eu pedi?". Se escrevermos na proposta de desenvolvimento que o cliente deverá fazer os testes do sistema, isso só reforça o seu comprometimento e faz com que ele se planeje para os recursos que deverão ser consumidos. Eles, os clientes, é que na realidade são os responsáveis por montar o plano de teste e os requisitos que serão exigidos do sistema. Se esse trabalho foi montado logo na fase de análise, ele pode ajudar e muito o analista a chegar à sua proposta de sistema.
O teste de sistema, normalmente, é criado e executado pelo líder do projeto. Há uma tendência em algumas empresas de deixar esse trabalho para outra pessoa, pois existe o fato de ser difícil encontrar falhas nas coisas que se cria.
Mas, independente da pessoa que é responsável por desempenhar essa tarefa, a seguinte pergunta deve ser respondida: "Esse programa/sistema faz o que o usuário quer?" Essa fase é importante, pois, após serem feitos esses testes para a Empresa, o sistema está pronto e os requisitos de qualidade foram atingidos.
O teste de integração é o responsável por testar as várias partes e verificar se elas funcionam juntas, conforme especificação. A pergunta que deve ser respondida é: "Tudo se encaixa?" Essa pergunta relaciona-se ao fluxo de controle entre os módulos, se estão corretos e completos e se os dados que estão sendo passados entre os módulos estão corretos também. Após especificar o teste de integração, deve-se então partir para o teste unitário.
Quanto ao teste unitário, normalmente é desenvolvido enquanto os programas estão sendo feitos.
Ele deve responder à seguinte pergunta: "Será que codifiquei direito?" Ele tem a finalidade de procurar falhas nos programas e verificar se as funções estão sendo executadas corretamente. Para muitos, o compilador governa o teste de unidade, mas é vital processar dados de testes para verificar se os programas fazem exatamente aquilo para o qual foram propostos.
Os planos de testes são desenvolvidos de maneira "top-down" e a sua execução é feita de maneira "bottom-up", iniciando conforme os programas vão ficando prontos e segue até o usuário aceitar o sistema.
Para se planejar e especificar os testes no sistema, existem alguns métodos propostos que estão baseados normalmente em dois fatores: probabilidade e risco. Rotinas complexas ou que possuem uma importância maior devem ser mais testadas.
Existem algumas dificuldades com relação à implantação de testes na CELEPAR, uma delas é o ambiente em que estamos inseridos, que é: produção ou desenvolvimento. O ambiente de desenvolvimento, hoje, suporta bem os testes unitários de integração e de sistema, ficando um pouco prejudicado quando tentamos fazer testes com clientes.
O que precisamos, hoje, é resgatar a importância desses testes, para garantia de qualidade dos sistemas. E isso só é possível introduzindo-se métodos para auxiliar no planejamento e especificação dos mesmos, pois o teste é um item fundamental para o desenvolvimento de sistemas.