Este artigo apresenta um estudo sobre o modelo de processo Melhoria de Processo de Teste Brasileiro (MPT.BR). Assim, aborda-se uma alternativa de processo de teste para empresas que não queiram um alto custo na implementação de um processo. O processo é baseado em outros modelos como Capability Maturity Model Integration (CMMI) e Melhoria de Processo de Software Brasileiro (MPS.BR), porém focado no processo de teste de software. Ele utiliza o padrão de documentação sugerido pela norma internacional IEEE-829.
Em que situação o tema útil:
Para aqueles que têm interesse em conhecer o MPT.BR ou estejam interessados em aprimorar as práticas de teste de software utilizadas em seu dia a dia.
Resumo DevMan
Este artigo apresenta conceitualmente temas como teste de software, apresentando boas práticas e documentação padronizada da IEEE-829, automação de testes, processo MPT, bem como sua divisão em níveis e conceitos do processo.
Na globalização do mercado de software, cada vez mais competitivo, terá mais chance de sobreviver quem for organizado e eficiente no seu processo de produção, disponibilização e evolução de software. Esse cenário faz com que o processo de melhoria de qualidade de produtos e serviços relativos à informação seja vital para as empresas desse ramo.
O modelo de Melhoria de Processo de Teste Brasileiro (MPT.BR) foi criado com a proposta de disponibilizar um modelo de testes para empresas de qualquer porte, dando a oportunidade para as empresas de software implementarem níveis de maturidade dentro de suas organizações, trazendo mais qualidade para seus produtos, sem que haja um aumento do custo do produto.
A qualidade é algo cobiçado por todos dentro de uma organização de tecnologia de informação. Gerentes querem alta qualidade em seu produto, os desenvolvedores querem desenvolver produtos de alta qualidade e os usuários, cada vez mais exigentes, querem confiança e consistência na sua ferramenta de trabalho.
Existem outros modelos de maturidade de teste de software além do MPT.BR, como Testability Support Model (TSM), Testing Maturity Model (TMM), Test Process Improvement (TPI), Testing Assessement Program (TAP), Test Organization Maturity (TOMtm), Testing Improvement Model (TIM), Testing Maturity Model Integration (TMMi). Porém, nenhum desses modelos possui representantes no Brasil, tornando muito difícil sua implementação e, mesmo que a organização faça a implementação por conta própria, seria muito caro conseguir sua homologação e reconhecimento no mercado brasileiro.
Pelo fato do MPT.BR ser um modelo novo, ainda não existe uma solução no mercado que atenda às necessidades de sua implementação em uma única ferramenta. Desta forma, a solução atual para a automação do modelo MPT.BR é a aquisição, a implantação, a integração e o treinamento dos usuários em diversas ferramentas, cada uma abrangendo uma área do processo. Isso torna a automação difícil, considerando-se a necessidade de gastos com a compra de todas estas diversas ferramentas, integração e treinamento nas mesmas.
Neste cenário, temos que defeitos encontrados durante a produção tendem a custar muito mais que defeitos encontrados em modelos de dados e em outros documentos do projeto do software. Motivado por isto, este artigo apresenta conceitualmente temas como teste de software, apresentando boas práticas e documentação padronizada da IEEE-829, automação de testes, processo MPT, bem como sua divisão em níveis e conceitos do processo.
Entendo os principais conceitos
A partir de agora abordaremos temas como teste de software, padrão de documentação, automação de processos, processo de teste MPT.BR, detalhando o processo, bem como os níveis que ele dispõe.
Teste de Software
Neste tópico são apresentados conceitos básicos de teste de software e padrão de documentação segundo IEEE-829.
Conceitos básicos
Desenvolver sistemas que atendam corretamente seu objetivo é uma tarefa de alta complexidade, dependendo da finalidade do software. Isso eleva a possibilidade do sistema apresentar problemas dos mais variados tipos.
Entretanto, não se pode garantir que todos os programas funcionem corretamente, sem a presença de erros humanos, visto que os mesmo muitas vezes possuem um grande número de estados com fórmulas, atividades e algoritmos complexos.
Neste sentido, tem-se que testar é executar um programa com a finalidade de encontrar erros. Mais do que isso, testar não é somente procurar erros, também fazem parte da atividade de teste planejar, controlar, preparar, modelar, avaliar, mensurar e revisar.
A atividade de teste é complexa. São diversos os fatores que podem colaborar para a ocorrência de erros. Por exemplo, a utilização de um algoritmo incorreto para computar o valor das mensalidades a serem pagas para um empréstimo ou a não-utilização de uma política de segurança em alguma funcionalidade do software são dois tipos distintos de engano e, de certa forma, encontram-se em níveis diferentes de abstração. O primeiro tipo de erro provavelmente está confinado a uma função ou rotina que implementa de forma incorreta uma dada funcionalidade. No segundo caso, mesmo que exista uma certa política de segurança implementada de maneira correta, é preciso verificar se todos os pontos nos quais essa política deveria ser aplicada fazem-no de maneira correta.
Por fim, é importante dizer que a qualidade do software depende também do investimento feito no processo de teste.
...
