Defeitos são caracterizados como imperfeições incluídas em softwares e têm como causa o erro humano. Quando a execução envolve uma condição que passa por um defeito do software, ocorre a falha, que é a manifestação deste defeito.
Prevenção de falhas em software é o processo que estabelece os mecanismos para evitar esta ocorrência. Tem como principal objetivo garantir que, uma vez identificadas e endereçadas, as falhas em software não voltem a ocorrer.
Identificar e corrigir defeitos acrescenta muito aos custos de desenvolvimento e manutenção de software. Isto inclui os custos de teste, de correção, da insatisfação de usuários, das garantias e do atendimento. Não contando aí os custos imensuráveis da perda de reputação.
Outro importante fator, além das economias de custo e esforço na institucionalização da prevenção de falhas, é implantar o foco contínuo de melhoria de processos.
A prevenção de falhas não é feita por uma ou outra pessoa esporadicamente. Cada um deve estar envolvido e todos devem estar conscientes de sua importância. É instrutivo fazer com que as pessoas pensem em seus problemas como se fossem altamente críticos. De fato, como mais e mais Softwares vêm sendo utilizados de forma crescente em aplicações sensíveis, progressivamente, ou principalmente, falhas em software tornam-se catastróficas para a sociedade.
Para implantar a prevenção de falhas, assim como qualquer outro programa de qualidade, há que se iniciar pelo “compromisso pela qualidade” na da alta direção da organização. Enquanto este nível retardar ou redirecionar projetos para atingir metas, não haverá crença na implantação do programa de qualidade. Este aspecto, assegurar qualidade, deve ser reforçado até que as pessoas certifiquem-se da sua importância.
Um papel chave está em designar o processo de prevenção de falhas às ações de um time. Time formado por profissionais de diferentes áreas, Quality Assurance, Gestão de Serviços, Gerência de Configuração e Especialistas em Metodologias. As responsabilidades deste time são:
• Priorização de todas as ações;
• Estabelecer um plano de implantação para as ações de alta prioridade;
• Designar responsabilidades;
• Acompanhar implantação;
• Reporte gerencial de progresso;
• Assegurar que todos os casos de sucesso sejam reconhecidos e as responsabilidades individuais identificadas;
• Continuar com as próximas ações de prioridade.
O processo de prevenção de falhas é contínuo. A cada momento foca a prevenção das falhas mais relevantes remanescentes. Depois de implantado, o processo segue seu ciclo.
Os passos para a implantação de um programa de prevenção de falhas são:
• Reporte de defeitos – inclui informação suficiente para caracterizar cada falha e determinar suas causas (o registro faz parte de outro processo);
• Análise causal – onde a causa das falhas, ou defeito provocador, de maior ocorrência e gravidade são determinados;
• Ações de implantação – determinadas, as ações devem ser implantadas. Isto geralmente envolve todas as partes da organização em um esforço concentrado de melhoria;
• Acompanhamento do desempenho – dados de desempenho são levantados e todas as ações são acompanhadas e compiladas;
• Starting over – recomeçar novamente, porém concentrando esforços nas falhas de maior relevância remanescentes.
Em todos estes passos, os engenheiros de software devem estar envolvidos, nas reuniões de identificação das falhas relevantes remanescentes e análise destas, assim como no processo de prevenção. As pessoas devem receber retorno deste tipo de ação.
O processo de prevenção de falhas é uma mudança complexa no processo de software que irá transformar as organizações.Mesmo se não houver nenhuma evidência econômica de que a prevenção de falhas é efetiva em custos, o exemplo de outras indústrias que tiveram experiência nesta situação, e que não reagiram a tempo, deve ser considerado. Enquanto não estiver claro que software está enfrentando desafio similar, não há argumento convincente de que esta situação seja diferente
sexta-feira, 31 de julho de 2009
domingo, 21 de junho de 2009
Qualidade na Implantação de Sistemas
A crescente importância das organizações no “Time to Market” acelera o processo de mplantação de sistemas que em geral é feito em caráter de urgência. Estatísticas, como da revista CHAOS, revelam que apenas 9% a 28% dos projetos têm sucesso no aceite; que 47% a 62% são implementados com adaptações; e que 22% a 37% destes são descontinuados. E ainda, pesquisas do instituto GARTNER apontam que, aproximadamente 40% dos projetos de missão crítica em Mainframe, assim como 70% dos Client/Server, têm falhado durante a sua implantação.
Estes dados apenas indicam ações de qualidade conduzidas durante o ciclo de desenvolvimento de sistemas, não são suficientes para garantir os resultados após a sua conversão para a produção. O Plano de Implantação, que inclui o Plano de Conversão, o Programa de Comunicação e o Plano de Treinamento, devem ser alvo destas ações e muito bem controlados pela Gestão de Mudanças.
Dois fatores são muito importantes para a Gestão da Mudança durante o processo de implantação:
· A demonstração da qualidade do sistema para aceitar a sua conversão ao ambiente de produção – implica em evidenciar a qualidade do sistema, para que o solicitante autorize a sua implantação e entrada em operação; e,
· A demonstração de que os processos de conversão foram bem sucedidos – implica em validar o sistema implantado, certificando-se o sucesso desta conversão.
O Aceite deve ser um processo transparente, que demonstre a qualidade do sistema como suporte à tomada de decisão de sua implantação, ou não. Dar transparência ao processo de Aceite implica em evidenciar a real qualidade do sistema para o Negócio e para a Produção. Exibir prova das qualidades e dos defeitos do sistema em relação aos seus requisitos funcionais e técnicos, com análise de risco, planos de mitigação e/ou contorno.
Um resumo dos requisitos, classificados em essenciais, importantes e desejáveis e, ainda ponderados pela sua criticidade, alta, média, ou baixa, que indique o nível de cobertura e de resultado atingido durante os testes.
Para cada requisito não atendido e/ou não coberto, são estabelecidos os riscos para o negócio e para a produção e plano de ação para a eliminação destes riscos, ou, pelo menos, para mitigá-los.
Estas ações são tomadas antes da conversão, por serem de suporte à implantação. Para complicar o cenário, a virtualização dos acessos tornou as falhas em sistemas fatais para o negócio, impedindo a sua verificação prévia e, o processo de validação da conversão, complexo, importante e crítico.
O processamento de “Piloto” para tornar a validação exeqüível e efetiva está diretamente associado ao ambiente em que este será executado. Deve, portanto, acontecer de forma pouco, ou nada invasiva em relação ao processo produtivo, para que falhas que possam ocorrer durante este “Piloto” não impactem a produção e, por conseqüência o negócio. No limite, o “Piloto” deve processar em ambiente segregado a produção, porém, com todas as características deste, onde o correto funcionamento e as necessidades do sistema em implantação podem ser certificados.
Este tipo de ambiente em geral tem alto custo, porém, em nada se compara ao prejuízo no negócio advindo de falhas na implantação de sistemas que o suportam.
Estes dados apenas indicam ações de qualidade conduzidas durante o ciclo de desenvolvimento de sistemas, não são suficientes para garantir os resultados após a sua conversão para a produção. O Plano de Implantação, que inclui o Plano de Conversão, o Programa de Comunicação e o Plano de Treinamento, devem ser alvo destas ações e muito bem controlados pela Gestão de Mudanças.
Dois fatores são muito importantes para a Gestão da Mudança durante o processo de implantação:
· A demonstração da qualidade do sistema para aceitar a sua conversão ao ambiente de produção – implica em evidenciar a qualidade do sistema, para que o solicitante autorize a sua implantação e entrada em operação; e,
· A demonstração de que os processos de conversão foram bem sucedidos – implica em validar o sistema implantado, certificando-se o sucesso desta conversão.
O Aceite deve ser um processo transparente, que demonstre a qualidade do sistema como suporte à tomada de decisão de sua implantação, ou não. Dar transparência ao processo de Aceite implica em evidenciar a real qualidade do sistema para o Negócio e para a Produção. Exibir prova das qualidades e dos defeitos do sistema em relação aos seus requisitos funcionais e técnicos, com análise de risco, planos de mitigação e/ou contorno.
Um resumo dos requisitos, classificados em essenciais, importantes e desejáveis e, ainda ponderados pela sua criticidade, alta, média, ou baixa, que indique o nível de cobertura e de resultado atingido durante os testes.
Para cada requisito não atendido e/ou não coberto, são estabelecidos os riscos para o negócio e para a produção e plano de ação para a eliminação destes riscos, ou, pelo menos, para mitigá-los.
Estas ações são tomadas antes da conversão, por serem de suporte à implantação. Para complicar o cenário, a virtualização dos acessos tornou as falhas em sistemas fatais para o negócio, impedindo a sua verificação prévia e, o processo de validação da conversão, complexo, importante e crítico.
O processamento de “Piloto” para tornar a validação exeqüível e efetiva está diretamente associado ao ambiente em que este será executado. Deve, portanto, acontecer de forma pouco, ou nada invasiva em relação ao processo produtivo, para que falhas que possam ocorrer durante este “Piloto” não impactem a produção e, por conseqüência o negócio. No limite, o “Piloto” deve processar em ambiente segregado a produção, porém, com todas as características deste, onde o correto funcionamento e as necessidades do sistema em implantação podem ser certificados.
Este tipo de ambiente em geral tem alto custo, porém, em nada se compara ao prejuízo no negócio advindo de falhas na implantação de sistemas que o suportam.
Qualidade de sistemas-legado
Em todos os setores da economia, indústria, finanças, serviços e até mesmo em setores agrícolas, é crescente o emprego de processos informatizados. Esta crescente utilização, por sua vez, faz com que falhas em sistemas aplicativos gerem impactos imensuráveis ao negócio. Seja pela indisponibilidade temporária, ou pelas distorções em resultados, mas principalmente, na credibilidade e imagem da organização perante seus clientes.
Mas, se os sistemas aplicativos foram testados e homologados exaustivamente antes de sua implantação, por que falham em produção?
A resposta é uma só: testes e homologações só verificam e validam as condições previstas. O que não foi previsto, não foi testado. Significa que, por melhor que sejam executados os testes, estes não garantem total remoção de defeitos. Sempre existirão condições não previstas, que não fizeram parte dos planos de testes e / ou das homologações. Os sistemas que suportam a operação (Legado) carregam defeitos, que, a qualquer momento podem causar falhas em produção e impactar o negócio que suportam.
Como então prevenir tais ocorrências? Como melhorar a qualidade de sistemas-legado? Quais as ações de qualidade que podem ser aplicados à produção?
Referências à qualidade de sistemas, em sua maioria, dizem respeito aos processos de verificação e validação que são conduzidos durante as fases de desenvolvimento, teste e homologação de novos aplicativos, ou novas funcionalidades a serem implantadas em produção. Poucas, ou quase nenhuma são as referências ao legado de sistemas que está em operação.
Para tanto, faz-se necessário definir ações de proteção à estabilidade do processamento. Ações de qualidade devem ser aplicadas no sentido de proteção à produção:
· Simular antecipadamente a produção;
· Identificar as interrupções e/ou divergências possíveis; e,
· Corrigir a produção a tempo.
· Identificar as interrupções e/ou divergências possíveis; e,
· Corrigir a produção a tempo.
Resumidamente, implica em processar aquilo que será a produção do próximo ciclo produtivo: é a “diária de amanhã”; é o processamento das “transações de amanhã”. Este processamento deve ocorrer par e passo com a produção, em ambiente apartado e controlado, de forma a validar, contornar e, principalmente, corrigir as falhas de processamento que iriam impactar a produção.
A simulação antecipada da produção exige investimento não só em processos de qualidade, mas em infra-estrutura de processamento. Estes investimentos podem ser reduzidos com a adoção de infra-estruturas já existentes, como por exemplo, ambientes de contingência, que têm a mesma configuração da produção e estão disponíveis apenas para a eventualidade de queda da produção. Certamente, as falhas em produção são mais caras e mais difíceis de serem reparadas. Assim, estes investimentos serão pagos com as economias das falhas evitadas em produção. Estas ações, se devidamente implementadas, com as gestões de mudanças, incidentes e problemas devidamente operantes neste ambiente, com métricas, com simulação e monitoração de falhas em comparação à produção, permitem a redução dos impactos das falhas em produção. Para subsidiar o investimento em processos de proteção da produção, cálculos do instituto Meta Group (atualmente Gartner Group), o custo de parada da produção para instituições financeiras é estimado em US$ 996 mil / hora, o que já auxilia a demonstração da viabilidade de implementação de ações deste tipo.
A decisão pelo desenvolvimento e implantação de ações com este fim, não precisa necessariamente ter a abrangência da produção, mas sim, abrigar as aplicações que sustentam os negócios críticos da organização. Também não implica em desenvolvimento e implantação em uma só vez. Iniciar com o desenvolvimento de uma aplicação crítica e partir para outras aplicações na seqüência, permite o ganho inicial e o aprendizado da organização com a crescente evolução nas ações de qualidade. Aplicar ações de qualidade agregando valor ao negócio.
quarta-feira, 12 de novembro de 2008
Qualidade de Sistemas com Foco no Negócio
Somente a qualidade medida e percebida pelo usuário final permite o real foco na qualidade do negócio. Mas, como implementar na prática qualidade de sistemas como benefício ao negócio?
Na realidade, é necessário definir ações que, aplicadas ao ciclo de vida dos sistemas, ou mais especificamente, aplicadas aos ciclos de Solicitação, Desenvolvimento e Produção, focam a qualidade dos sistemas a serviço do negócio. São ações voltadas à estabilidade e integridade do produto que o sistema suporta.
Durante o ciclo de solicitação, a “Inspeção de Requisitos” é o principal processo que garante a validação dos requisitos de negócio. Neste contexto, é imprescindível que os resultados deste processo de inspeção sejam refletidos nos Planos de Teste e os requisitos de negócio validados pelos Solicitantes.
Assim também, os requisitos técnicos, que garantem a aderência ao ambiente de processamento, devem ser validados neste processo de inspeção, porém pela Produção. Inspeções formais com representantes dos Solicitantes e da Produção garantirão a aderência ao negócio e à produção do sistema que suporta este negócio.
Durante o ciclo de desenvolvimento, a “Gestão de Mudanças” é o principal processo que valida a presença dos requisitos de negócio no sistema. A gestão de mudanças deverá garantir que todos os requisitos de negócio e de sistemas estejam evidenciados e em acordo com o planejado nos Planos de Teste.
A gestão de mudanças deverá exigir a concordância do Solicitante e da rodução em todas as evidências. Isto inclui as evidências de testes de regressão em caso de implementação de funcionalidades adicionais a sistemas já em produção, ou interface com sistemas já em produção. Devem incluir também os requisitos de performance e de volume.
Durante o ciclo de produção, a “Monitoração” e a “Reação às Falhas” são os processos que garantem a validação dos requisitos de negócio. Por melhor que sejam executados os testes,
estes não garantem total remoção de defeitos. Defeitos não removidos pelas inspeções ou pelos testes, armam verdadeiras “bombas relógio” que, em condições específicas, provocam falhas no processamento, causando impactos que podem ser muito danosos ao negócio.
estes não garantem total remoção de defeitos. Defeitos não removidos pelas inspeções ou pelos testes, armam verdadeiras “bombas relógio” que, em condições específicas, provocam falhas no processamento, causando impactos que podem ser muito danosos ao negócio.
Certamente, as falhas em produção são mais caras e mais difíceis de serem reparadas. Faz-se necessário definir ações de real proteção para a estabilidade do processamento, ou a continuidade do suporte ao negócio. A proteção à produção deverá ser implementada com a simulação antecipada da produção e com a prevenção de falhas. A efetividade das ações aqui propostas dependerá de gestão de processos, com métodos instalados e profissionais treinados e focados.
Ações de qualidade, portanto, têm foco no negócio, quando agregar valor ao negócio. Agregar Valor ao Negócio implica em:
- Melhorar o “Time to Market” – através da redução prazos para implantação dos projetos;
- Manter a “Continuidade do Negócio” – através da redução das falhas e dos impactos ao negócio, e;
- Melhorar a “Rentabilidade do Negócio” – através da redução dos custos minimizando o re-trabalho.
Note-se que qualidade de sistemas focada no negócio não elimina os demais processos de verificação e validação previstos nas metodologias de desenvolvimento e de testes de sistemas.
terça-feira, 28 de outubro de 2008
Requisitos para um Modelo de Testes
Diversas vezes as organizações desenvolvem seus Modelos de Testes próprios em função das mais diversas razões, tais como particularidades do ambiente, diferentes abrangências da metodologia utilizada, etc.
Não importa muito o modelo utilizado - um modelo consagrado de mercado, ou desenvolvido internamente à organização - pois o fator relevante é a efetividade do teste que este modelo permite alcançar.
É neste sentido que são listados a seguir os requisitos para um modelo de testes.
Um Modelo de Testes deve:
Não importa muito o modelo utilizado - um modelo consagrado de mercado, ou desenvolvido internamente à organização - pois o fator relevante é a efetividade do teste que este modelo permite alcançar.
É neste sentido que são listados a seguir os requisitos para um modelo de testes.
Um Modelo de Testes deve:
- Forçar uma reação de teste para todo e qualquer código liberado pelo projeto;
Requerer do planejamento de testes uma ação explicita e registrada em resposta a toda nova liberação, cancelamento de liberação e mudança de conteúdo de liberação;
Incentivar o uso de informações originais diferentes da documentação do projeto, durante o desenho do teste; - Permitir o relaxamento do esforço de testes por documentação tardia, ou pobre, porém prevenir o bloqueio total do teste;
Permitir que testes individuais sejam desenhados utilizando informações combinadas de várias fontes; - Permitir que testes sejam redesenhados assim que surjam novas fontes de informações;
Incluir feedback cíclico para que o desenho de testes considere o que é aprendido durante a execução de testes; - Permitir que testadores considerem poupar esforço em detrimento da execução de testes;
- Permitir teste de componente antes de sua construção estar completa.
Considerações
Alguns modelos de testes podem não aderir a estes requisitos, que a primeira vista parecem exagerados, sugerindo certo relaxamento na disciplina. Isto também não é importante.
O primordial é sim o gerenciamento dos testes focando seus objetivos básicos - remover defeitos evidenciando a qualidade do software para suportar a decisão de sua implantação - e, para tal, a flexibilidade do modelo é fundamental.
sexta-feira, 24 de outubro de 2008
Objetivos para a terceirização de testes.
Qual o objetivo que leva a organização a decidir pela terceirização das atividades de Testes de um projeto, ou dos projetos em geral?
Na realidade podem existir várias razões para tal, porém vejamos algumas questões que sustentam uma decisão neste sentido.
O Projeto está bem organizado e é fácil terceirizá-lo:
Esta razão é, no mínimo, interessante sobre o ponto de vista da oportunidade. As condições do projeto permitem que as atividades de teste possam ser terceirizadas, pois estão bem definidas, focadas e orientadas. Não há conflito de responsabilidades, nem contra indicações, sendo um momento particularmente propício para adquirir a experiência específica de terceirização dos testes.
Existem muitos projetos em andamento e é preciso focar:
Esta já é uma razão mais específica, que também traz a oportunidade. A terceirização dos testes vão, neste caso, na direção da racionalização do emprego de recursos. As condições dos projetos podem não ser tão favoráveis quanto no caso anterior, porém é possível escolher os projetos mais bem organizados para a terceirização e manter os menos organizados sob foco de seu Staff mais experiente. Uma postura mais arrojada neste caso, destinaria à terceirização os testes dos projetos menos organizados, exigindo do Terceiro a experiência comprovada na atividade.
Existe o desejo terceirizar testes de manutenção de software baseados em tecnologia antiga e que ninguém na organização quer conduzir:
Permitir ao Staff trabalhar com as tecnologias mais atualizadas é fator de motivação na organização. Terceirizar testes de software de tecnologia antiga é uma oportunidade de fato, que por vezes permite até melhorar os testes que talvez não vinham sendo executados com o devido foco e atenção.
Acredita-se ser possível reduzir e controlar custos de testes terceirizando o teste:
Toda e qualquer atividade focada e verticalizada, conduzida com maior nível de especialização, tem como tendência natural ter seus custos melhor controlados e consequentemente reduzidos. Terceirização das atividades de testes é sim fator de redução e controle de custos.
Não há Staff suficiente e não é possível recrutar:
A indisponibilidade de recursos para execução de atividades é razão suficiente para terceirizar e com a atividade de testes não é diferente.
O serviço não pode ser feito em tempo:
A terceirização de atividades para permitir paralelismo e, assim, ganhar tempo no total do projeto é razão para a terceirização de atividades.
A organização está perdendo expertise necessária:
A terceirização por si só já é uma forma de comprar expertise para o desenvolvimento de atividade. As atividades de testes demandam toda uma expertise para a condução adequada dos testes.
É desejável que o Terceiro treine seu Staff (dando o exemplo):
A aquisição de expertise de teste através da terceirização das atividades de testes é, por vezes, um valor agregado que assim se justifica. É comum atuar com equipes conjuntas para passar os conhecimentos.
O Terceiro detém habilidades e ferramentas específicas que devem ser experimentadas nos projetos:
A terceirização, com a utilização de método, habilidades e ferramentas empregadas pelo Terceiro, é forma de experimentar tais práticas antes de sua aquisição. Por vezes, a utilização de ferramentas nestes casos, é feita através de contratos de locação e não de aquisição.
É necessário um consultor independente (para avaliar a severidade de problemas, ou completeza dos testes, etc.):
A utilização de consultor independente de testes, externo à organização, é um conceitos de auditoria – princípio do duplo controle – onde quem faz não controla, ou quem desenvolve não verifica. Atualmente, tal princípio é utilizado largamente nos conceitos de testes, com a terceirização destas atividades e até na criação de um Grupo Independente de Testes internamente à organização.
Deseja-se algum tipo de certificação que o Terceiro pode prover:
Consultores independentes de testes são experts na disciplina e atuam treinados, com método específico e aplicam ferramentas no desenvolvimento das atividades de testes. Assim, normalmente estão credenciados para certificarem os testes de software, principalmente com base em requisitos de qualidade e evidências da execução de verificações específicas.
Há uma obrigação contratual de terceirização (independência dos testes):
A obrigação contratual na independência dos testes é razão clara para a terceirização destas atividades, mais ainda do que a utilização de um Grupo Independente de Testes reconhecido e designado pela organização.
Deseja-se julgamento independente do Terceiro, pois acredita-se que este conduzirá testes com base em requisitos de qualidade:
Não só a condução dos testes baseados em requisitos de qualidade é mais eficiente, como também é mais eficaz. Sobretudo, é a melhor forma de terceirizar atividades de testes, contratando níveis de qualidade do software a serem evidenciados para obter parâmetro de completabilidade dos testes.
A alta gerência acredita que Terceiros executam os testes de forma mais rápida, mais barata e melhor:
Sim, sem dúvida, desde que estes terceiros sejam especialistas em testes, sejam treinados e orientados a testes, utilizem-se de métodos de testes para o desenvolvimento de suas atividades e utilizem ferramentas – software de apoio a testes – para aumento de sua produtividade.
Caso seja um exercício Piloto, certifique-se de que todos os custos internos e externos sejam registrados. Em adição execute auditorias na qualidade do trabalho do Terceiro. Providencie dados atualizados e acurados de custos e de benefícios do esforço de testes
Na realidade podem existir várias razões para tal, porém vejamos algumas questões que sustentam uma decisão neste sentido.
O Projeto está bem organizado e é fácil terceirizá-lo:
Esta razão é, no mínimo, interessante sobre o ponto de vista da oportunidade. As condições do projeto permitem que as atividades de teste possam ser terceirizadas, pois estão bem definidas, focadas e orientadas. Não há conflito de responsabilidades, nem contra indicações, sendo um momento particularmente propício para adquirir a experiência específica de terceirização dos testes.
Existem muitos projetos em andamento e é preciso focar:
Esta já é uma razão mais específica, que também traz a oportunidade. A terceirização dos testes vão, neste caso, na direção da racionalização do emprego de recursos. As condições dos projetos podem não ser tão favoráveis quanto no caso anterior, porém é possível escolher os projetos mais bem organizados para a terceirização e manter os menos organizados sob foco de seu Staff mais experiente. Uma postura mais arrojada neste caso, destinaria à terceirização os testes dos projetos menos organizados, exigindo do Terceiro a experiência comprovada na atividade.
Existe o desejo terceirizar testes de manutenção de software baseados em tecnologia antiga e que ninguém na organização quer conduzir:
Permitir ao Staff trabalhar com as tecnologias mais atualizadas é fator de motivação na organização. Terceirizar testes de software de tecnologia antiga é uma oportunidade de fato, que por vezes permite até melhorar os testes que talvez não vinham sendo executados com o devido foco e atenção.
Acredita-se ser possível reduzir e controlar custos de testes terceirizando o teste:
Toda e qualquer atividade focada e verticalizada, conduzida com maior nível de especialização, tem como tendência natural ter seus custos melhor controlados e consequentemente reduzidos. Terceirização das atividades de testes é sim fator de redução e controle de custos.
Não há Staff suficiente e não é possível recrutar:
A indisponibilidade de recursos para execução de atividades é razão suficiente para terceirizar e com a atividade de testes não é diferente.
O serviço não pode ser feito em tempo:
A terceirização de atividades para permitir paralelismo e, assim, ganhar tempo no total do projeto é razão para a terceirização de atividades.
A organização está perdendo expertise necessária:
A terceirização por si só já é uma forma de comprar expertise para o desenvolvimento de atividade. As atividades de testes demandam toda uma expertise para a condução adequada dos testes.
É desejável que o Terceiro treine seu Staff (dando o exemplo):
A aquisição de expertise de teste através da terceirização das atividades de testes é, por vezes, um valor agregado que assim se justifica. É comum atuar com equipes conjuntas para passar os conhecimentos.
O Terceiro detém habilidades e ferramentas específicas que devem ser experimentadas nos projetos:
A terceirização, com a utilização de método, habilidades e ferramentas empregadas pelo Terceiro, é forma de experimentar tais práticas antes de sua aquisição. Por vezes, a utilização de ferramentas nestes casos, é feita através de contratos de locação e não de aquisição.
É necessário um consultor independente (para avaliar a severidade de problemas, ou completeza dos testes, etc.):
A utilização de consultor independente de testes, externo à organização, é um conceitos de auditoria – princípio do duplo controle – onde quem faz não controla, ou quem desenvolve não verifica. Atualmente, tal princípio é utilizado largamente nos conceitos de testes, com a terceirização destas atividades e até na criação de um Grupo Independente de Testes internamente à organização.
Deseja-se algum tipo de certificação que o Terceiro pode prover:
Consultores independentes de testes são experts na disciplina e atuam treinados, com método específico e aplicam ferramentas no desenvolvimento das atividades de testes. Assim, normalmente estão credenciados para certificarem os testes de software, principalmente com base em requisitos de qualidade e evidências da execução de verificações específicas.
Há uma obrigação contratual de terceirização (independência dos testes):
A obrigação contratual na independência dos testes é razão clara para a terceirização destas atividades, mais ainda do que a utilização de um Grupo Independente de Testes reconhecido e designado pela organização.
Deseja-se julgamento independente do Terceiro, pois acredita-se que este conduzirá testes com base em requisitos de qualidade:
Não só a condução dos testes baseados em requisitos de qualidade é mais eficiente, como também é mais eficaz. Sobretudo, é a melhor forma de terceirizar atividades de testes, contratando níveis de qualidade do software a serem evidenciados para obter parâmetro de completabilidade dos testes.
A alta gerência acredita que Terceiros executam os testes de forma mais rápida, mais barata e melhor:
Sim, sem dúvida, desde que estes terceiros sejam especialistas em testes, sejam treinados e orientados a testes, utilizem-se de métodos de testes para o desenvolvimento de suas atividades e utilizem ferramentas – software de apoio a testes – para aumento de sua produtividade.
Caso seja um exercício Piloto, certifique-se de que todos os custos internos e externos sejam registrados. Em adição execute auditorias na qualidade do trabalho do Terceiro. Providencie dados atualizados e acurados de custos e de benefícios do esforço de testes
Como evidenciar a qualidade de sistemas e software?
Defendo que a qualidade de software só é alcançada plenamente através da aplicação de processo gerenciado, com método e com profissionais treinados e focados, sendo evidenciada através da redução dos tempos para os testes e por conseqüência, para o projeto, e dos custos de retrabalho, agregando valor ao negócio que suporta.
Esta defesa é iniciada com as definições para Erros, Defeitos e Falhas: Pessoas cometem Erros, Sistemas e Softwares contêm Defeitos, que se manifestam nos Processamentos sob a forma de Falhas.
Quando falamos em Qualidade de Sistemas e Software, fazemos referência apenas aos Defeitos e as Falhas. Os Erros cometidos pelas pessoas não são tratados nesta, mas sim, pelas disciplinas de Desenvolvimento de RH. Erros de pessoas são corrigidos com treinamentos, com campanhas de conscientização, etc.
Os Defeitos são tratados durante o desenvolvimento dos projetos de sistemas e software nas atividades de Verificação e Validação da Qualidade, durante os processos de testes e homologação. Já as Falhas são tradicionalmente tratadas pelas manutenções corretivas, evidenciadas pelo re-trabalho.
Qualidade tem de ser evidenciada e percebida. Em resumo, não se tem qualidade que não seja medida e não seja percebida pelo cliente final.
Neste sentido, é necessário medir Defeitos e Falhas, que irão compor os indicadores de qualidade. Isso significa que métricas são fundamentais na evidência da qualidade de sistemas e software, que, curiosamente, é medida pela anti-qualidade (defeitos e falhas), e para ser percebida pelo cliente final, é imperativo que a qualidade agregue valor ao negócio que suporta.
Esta defesa é iniciada com as definições para Erros, Defeitos e Falhas: Pessoas cometem Erros, Sistemas e Softwares contêm Defeitos, que se manifestam nos Processamentos sob a forma de Falhas.
Quando falamos em Qualidade de Sistemas e Software, fazemos referência apenas aos Defeitos e as Falhas. Os Erros cometidos pelas pessoas não são tratados nesta, mas sim, pelas disciplinas de Desenvolvimento de RH. Erros de pessoas são corrigidos com treinamentos, com campanhas de conscientização, etc.
Os Defeitos são tratados durante o desenvolvimento dos projetos de sistemas e software nas atividades de Verificação e Validação da Qualidade, durante os processos de testes e homologação. Já as Falhas são tradicionalmente tratadas pelas manutenções corretivas, evidenciadas pelo re-trabalho.
Qualidade tem de ser evidenciada e percebida. Em resumo, não se tem qualidade que não seja medida e não seja percebida pelo cliente final.
Neste sentido, é necessário medir Defeitos e Falhas, que irão compor os indicadores de qualidade. Isso significa que métricas são fundamentais na evidência da qualidade de sistemas e software, que, curiosamente, é medida pela anti-qualidade (defeitos e falhas), e para ser percebida pelo cliente final, é imperativo que a qualidade agregue valor ao negócio que suporta.
Assinar:
Postagens (Atom)
