Autor: Ueslei Aquino da Silva
Revisora: Carla Regina Florentino Sampaio
Tabela de conteúdo |
Na década de 60, os softwares eram desenvolvidos com baixo nível tecnológico e ficavam a cargo dos analistas e programadores. O foco nesse momento era apenas demonstrar que o software estava funcional. À medida que a tecnologia evoluía, softwares mais sofisticados eram desenvolvidos, impactando diretamente na realização dos testes que, desta vez, se focalizavam: (1) na detecção dos defeitos; (2) nos erros e deficiências existentes no software; (3) na definição das capacidades e limitações e (4) no fornecimento de informações sobre a qualidade dos componentes, sistemas e outros produtos. Mas, o grande problema neste momento estava em quem realizava tais processos, pois eram realizados pelos próprios usuários e testadores sem experiência. Apesar de desde a década de 70 já existirem trabalhos mostrando que o teste precisava ser re-estruturado, (Em 1979 Glenford Myers publicou aquele que atualmente ainda é considerado um dos melhores livros de Teste de Software existentes no mercado, sob o título de “The Art of Software Testing” -publicado por John Wiley and Sons Inc. em edição revisada em 2004) foi a partir da década de 90 que o Teste de Software, enfim, recebe um novo olhar. Os holofotes agora estão sob a perspectiva da prevenção. Assim como comprovado por Myers, quanto mais cedo encontrar e corrigir um defeito, mas barato se torna para empresa. Desta forma, inspeções são realizadas nos artefatos do software, possibilitando a detecção e redução de defeitos logo nas fases iniciais do desenvolvimento.
Com a sofisticação dos softwares, processos de maturidade no desenvolvimento de software foram criados para se garantir cada vez mais a qualidade do produto. Em consequência, Processos de Teste surgiram para atribuir uma melhoria contínua aos serviços de teste. Atualmente vários são os processos destinados a Teste de Software. Citando alguns deles temos :
Alguns desses modelos tiveram origem a partir de um modelo de processo de software, como por exemplo o TMM, cuja base original é o CMM.
Antes mesmo de entrar no cerne da discussão da 5ª mesa-redonda do DFTestes, cujo tema foi MPT.BR (Melhoria do Processo de Teste Brasileiro) e apresentar as opiniões dos participantes da mesa, vou de forma breve explanar o que vem a ser o MPT.BR
Tendo como fundamento toda história em torno de “Teste de Software” e a realidade do mercado brasileiro de desenvolvimento de software, a ALATS em parceria com a RioSoft dão início ao desenvolvimento do modelo chamado de MPT.BR (Melhoria do Processo de Teste Brasileiro), modelo de maturidade de processo de teste compatível com o MPS.BR e o CMMI. Desta forma, empresas que implementam MPS e CMMI poderão, com pequeno esforço, aumentar e comprovar o nível de maturidade da área de Teste de Software.
Conforme apresentado na Guia 1 do MPT:
“O MPT é voltado para a melhoria das áreas de Teste de Software de empresas de qualquer porte. O modelo é leve e possível de ser adotado por áreas de Teste de Software para apurar o seu nível de maturidade, sem com isso onerar os seus processos anteriormente implementados.” [1 (pag. 4)]
“O objetivo principal será garantir que áreas de Teste de Software de tamanho reduzido possam ser avaliadas e estimuladas a alcançarem níveis maiores de maturidade, sem que para isso tenham que incorrer em altos custos operacionais.” [1(pag. 4)]
O Guia de implementação do MPT.BR está subdividido em níveis de maturidade, a exemplo do MPS.BR e CMMI. O nível um (1) contempla apenas a área de Gerência de Projetos. O objetivo é atender áreas de testes de todos os tamanhos, mesmo aquelas com número reduzido de profissionais.
O MPT.BR é apresentado com uma estrutura de cinco (5) níveis de maturidade, sendo o nível 1 o mais baixo e o nível 5 o mais alto. Na tabela 1, veremos como estão subdivididas as áreas de processo do MPT.BR.
Áreas de processo do MPT.BR :
Nível 1
Nivel 2
Nivel 3
Nivel 4
Nivel 5
De forma a garantir a aderência a uma das áreas de processo do modelo, a organização deverá implementar as práticas específicas e as práticas genéricas, que se aplicam a todas as áreas de processo, correspondentes ao nível de maturidade visado. A avaliação de que a unidade de teste alcançou um determinado nível será feita por meio da comprovação objetiva dos resultados alcançados e do exame das evidências (diretas, indiretas e afirmações) de que a empresa implantou cada uma das práticas específicas e genéricas para aquela área de processo e grau de maturidade visado.
Desta forma, temos a seguinte organização:
A chegada do MPT ao mercado brasileiro traz novas oportunidades de qualificação profissional para os interessados pela área de processos e também para as empresas que desejam melhorar sua área de teste baseada em níveis de maturidade.
Com esta tão nova realidade, e em processo de gestação, no mercado de Testes de Software brasileiro, algumas questões, quase que inevitavelmente, são levantadas:
Com o objetivo de ajudar os profissionais de teste a pensar sobre as questões colocadas, a equipe do DFTestes se reúne em uma mesa redonda e partilha opiniões e conhecimentos sobre o assunto como segue:
Os profissionais poderão se certificar como implementadores e/ou avaliadores do MPT e a meu ver, é uma ótima oportunidade para os profissionais que gostam da área de processo e/ou querem investir na área obtendo um diferencial de mercado.
Por que os “selos” de qualidade e melhoria são tão criticados hoje em dia, principalmente pelos agilistas?
Algumas experiências ouvidas sobre o MPS.BR, mostram que empresas buscaram o selo apenas para serem melhor colocadas em licitações. De início, a empresa aceita o investimento e passa por toda burocracia para implementação do processo mas, depois que o avaliador vira as costas engavetam toda documentação e volta à vida normal. Implantar processo, seguir práticas é um tanto quanto burocrático, se na organização não tiver o apoio da alta gerência para que tudo seja seguido, mesmo sem a presença do implementador e após a certificação, nada funciona. Uma solução adotada pelo MPS.BR para resolver essa situação foi colocar prazo de validade nas certificações, ou seja, a cada 3 anos a empresa passa pelo processo de reavaliação, se não se recertificar, sai da lista dos certificados em determinado nível.
Para o Shmuel Gershon, os agilistas não inventaram as críticas aos selos de qualidade. As reclamações são antigas, é só olhar para as críticas ao ISO9000 e ao Six Sigma.
Uma das limitações de todos os processos uniformizados é a uniformidade do processo. Como ele é estático e uniforme, quem tem que se adaptar é a empresa e os empregados. Empresas não são uniformes, são compostas por interações não uniformes entre pessoas não uniformes.
Empresas são diferentes e programam softwares diferentes. O processo para tratar de qualidade é o mesmo em um produto web-based e embedded? Um controlador de equipamento médico e um administrador de conteúdo? Uma empresa com 700 empregados e uma com 7?
O Shmuel é certíssimo em seus comentários, mas quanto ao MPT.BR temos uma nova perspectiva. Como explanado pelo objetivo do MPT, ele está sendo preparado para áreas de teste de todos os tamanhos, inclusive para “áreas de teste de tamanho reduzido”.
Para o Fabrício Ferrari, o foco do MPT implica na fé de que existem contextos diferentes e o tamanho é um dos parâmetros – uma boa novidade na área de estandardização de processos, que tende a ver tudo com ‘tamanho único’.
Por outro lado:
Sobre a limitação citada pelo Shmuel, acredita-se que é uma verdade, e o pior é como alguns profissionais encaram esses selos. Infelizmente, muitos ganham os seus uniformes (adorei essa analogia) e percebem que ficam bonitinhos com ele, daí então, a sua maior preocupação é deixar o uniforme bem limpinho.
Mas… e o cliente? ahh… ele terá uma primeira impressão muito boa da empresa uniformizada, e como dizem a primeira impressão é a que fica (ou não). No entanto após um tempo, o cliente vai perceber que as aparências enganam.
O mais importante para qualquer fornecedor é atender bem o cliente, isso é tão “lógico”. Selos, certificações profissionais, entre outros são plus, primeiro você tem que comer o feijão com arroz, pra depois comer a sobremesa!
O Edwagney afirma ter o mesmo entendimento do Shamuel, além de compartilhar o material que está em (https://itqualityview.wordpress.com/), Edwagney complementa dizendo que o ponto crucial de alguns processos de qualidade, e processos em geral, não dar certo em algumas organizações é que elas não lançam mão da sua cultura, da sua política, não usam o que tem de melhor. Não adaptam um determinado padrão aos padrões já existentes na empresa.
Como experiência profissional adquiridas nas empresas por onde passou, Edwagney relata que a questão era: “Vamos implantar isso de qualquer forma.” Conhece o ditado: “Top-guela-down”? É mais ou menos por aí…
Usar padrões e processos faz parte da inovação e da melhoria da qualidade, porém, arrisco dizer que 80% do sucesso de um projeto nesse sentido, se ganha usando o lado bom do conhecimento e cultura da empresa.
Para Shmuel Gershon em um primeiro momento, pareceria uma questão de oferta e demanda. É igual ISO9001… se a empresa vai perder mercado por falta de certificação, então certamente vale à pena. Se a empresa consegue manter diferenciação comercial sem o certificado, então não vale à pena. Certo? O único problema na situação descrita é que no caso de uma certificação sobre testes, quem cria a demanda são as próprias empresas certificadas. Assim como nas certificações de indivíduos, existe tanta confusão ao redor do que testes e testadores fazem que é fácil apresentar uma certificação e dizer “Aqui oh, não se preocupe, nós somos certificados, por isso somos melhores que a concorrência”. Ao criar a demanda, criamos um círculo vicioso onde quem não se certifica fica pra trás. No fim das contas, se uma empresa acredita que deve passar pelo processo de certificação, tudo bem, mas com cuidado e delicadeza.
Uma alternativa adotada para se exigir um nível aceitável de qualidade foi a comprovação de que a empresa está desenvolvendo software com foco em qualidade. Esta comprovação vem com os selos de certificação tais como: CMMI, MPS.Br, entre outros.
Deve-se manter sempre em mente que é a melhoria do processo que realmente traz o aumento da qualidade e da produtividade da empresa. A certificação é um importante diferencial de marketing, mas não deve ser um fim em si mesma.
A melhor atitude é planejar a capacitação do processo e da equipe aos poucos, de acordo com a possibilidade financeira da empresa. É recomendada uma consultoria específica para auxiliar nesse planejamento, identificando e priorizando cada área do processo e cada treinamento necessário para a equipe de projeto.
A melhor resposta depende de cada empresa, gerente, líder e equipe. A equipe deve se conhecer o suficiente para escolher.
Como citado anteriormente, temos diversos modelos de processo de testes. A maioria deles do exterior. Implantar um processo aqui no Brasil seria trabalhoso, além, de muito caro, pois não há instituições implementadoras/avaliadoras assim como profissionais qualificados para tal.
Para o Shmuel Gershon, depende: Uma possibilidade: Sim! – pelo menos vai ter um processo mais estruturado. Outra: Não! Onde existia incompetência caótica, agora existirá uma incompetência organizada e rigorosa. O problema desta última, é que agora ninguém mais percebe que tem que melhorar. Ou ainda: Depende! Pode ser que o dono da empresa se sinta inseguro e a certificação vai deixá-lo mais cordato para guiar a empresa. Ou pode ser que a equipe seja madura o suficiente para não deixar a certificação ou o rigor do processo atrapalhar a operação. Pode ser que o gerente de testes não queira a certificação de jeito nenhum, e certificar-se vai criar rixas desnecessárias. Pode ser que a equipe seja tão madura e com ótima performance que inserir as mudanças da certificação vai atrapalhar. Tudo pode ser.
Com o MPT, toda esta realidade muda, pois é um modelo gestado internamente possuindo, espalhados pelo Brasil, profissionais implementadores qualificados e instituições avaliadoras, além de ser muito mais barato.
"Se uma fábrica de software possui internamente profissionais que testam o software, acredito que sim. Trabalhei em uma empresa que mantém no mercado um grande ERP. A empresa possui uma fábrica de desenvolvimento de aproximadamente 70 desenvolvedores (em sua matriz) e um departamento de teste com 8 testadores. Para o mercado seria interessante mostrar para os clientes que a qualidade do software desenvolvido é assegurada por processos estabelecidos, maduros, entre outros." (Ueslei Silva)
Vários benefícios já são conhecidos quando uma fábrica de software implanta um processo de desenvolvimento. Com a implantação de processo de teste, não vem a ser diferente e concatenando ambos, essa lista só tende a aumentar. Como exemplos, podemos citar:
Concluímos que processo é ótimo para a empresa como um todo, traz vários benefícios, mas submete a empresa a um investimento inicial caro. O processo de implementação é burocrático e necessita do apoio da alta gerência e colaboração de todos os envolvidos no projeto, caso contrário a implementação tornar-se-á um processo lento e doloroso. No fim, poucas mudanças poderão ser vistas. Uma vez sendo apoiado por todos os interessados, tudo torna-se mais fácil e rápido e assim a empresa sofrerá menos em seu processo de implementação. Contar com o apoio de uma consultoria especializada é uma prática comum, pois, garante de alguma forma a efetividade do processo.
Quanto ao fato de certificar-se, uma empresa deverá estudar vários pontos para uma avaliação de Custo X Benefício, de forma a comprovar a viabilidade do investimento a ser feito para a implementação do processo.
<- Voltar para o capítulo anterior | Voltar para o índice
[1] MPT.BR – Guia de Implementação – Parte 1: Nível 1 (versão 2.1)
[2] DIAS, André. Por que investir em melhoria de processos? Pronus. Disponível em: <http://www.pronus.eng.br/artigos_tutoriais/processo_desenvolvimento/melhoria_processo.php?pagNum=0>. Acessado em: 14/03/2010.