domingo, 12 de setembro de 2010

Como testar quando a documentação é precária?

A importância da documentação para a realização de testes é sempre tema de muita discussão.
Quando falamos de projetos de desenvolvimento de software onde seguimos uma esteira rápida de produção ou quando a complexidade da solução é considerada baixa, normalmente a documentação é bastante simplificada e em muitos casos até desprezada. O fato é que a produção de documentação nesses projetos é normalmente vista pela maioria dos envolvidos no processo de desenvolvimento como perda de tempo e burocracia inútil.  


Isso pode trazer muitos problemas para as equipes de testes, que têm seu trabalho dificultado pela falta de insumos. Entretanto, essa dificuldade não deve ser motivo para que os testes sejam deixados de lado ou para que seja dispensada a participação de equipes de testes independentes. Mesmo com pouca documentação, é possível que essas equipes realizem testes importantes em nível de sistema, complementando a visão dos desenvolvedores sobre a qualidade da solução.

Outro ponto importante, é que pouca documentação certamente é melhor que nenhuma! E em muitos casos, pode ser até melhor termos uma documentação simplificada, mas que agregue real valor ao produto, do que uma ampla documentação, que não possa ser mantida atualizada e que não seja confiável, ou ainda, que não seja mais utilizada após a sua produção, representando um custo desnecessário para o projeto. Mesmo quando temos apenas uma definição simplificada do escopo da solução a ser construída, podemos estruturar nossos testes funcionais de tal forma que seja garantida a rastreabilidade em relação aos requisitos definidos. Isso é importante tanto para a organização dos casos de teste, como também para a avaliação da cobertura obtida na execução dos testes, sejam estes previamente projetados ou realizados de forma exploratória.

Mas como executar os testes se não temos uma documentação suficiente para compreendermos o comportamento esperado do sistema?  Não existe milagre! Quanto menos documentação estiver disponível, maior deverá ser a interação entre os envolvidos no projeto. O problema é que os desenvolvedores também sofrem pressões por uma entrega rápida e não têm muito tempo e nem disposição para explicar o funcionamento do sistema aos testadores. Mas será que isso é mesmo um problema?



Ao tratarmos a importância dos testes de aceitação em nosso último post, ressaltamos que a aproximação entre a equipe de testes e o cliente pode ser muito útil para a construção de roteiros de aceitação e maior detalhamento dos requisitos. Esta certamente é uma estratégia muito útil também quando nos defrontamos com um cenário de documentação escassa nos projetos, pois o cliente pode fornecer à equipe de testes informações preciosas sobre o funcionamento do sistema, desonerando os desenvolvedores desta tarefa. Na verdade, isso pode representar um importante benefício para o projeto, pois não teremos a contaminação dos testes de sistema pela visão do desenvolvimento, além de podermos identificar inconsistências entre as necessidades apresentadas pelo cliente e os requisitos especificados e utilizados para a construção do software. Ao aproximar-se do cliente, a equipe de testes obtém informações que lhe auxiliarão tanto no entendimento de detalhes importantes do sistema como na especificação dos testes, mesmo sem a utilização de uma documentação formal.

Assim, acreditamos ser possível contornarmos uma eventual precariedade da documentação em um projeto de desenvolvimento de software, com uma comunicação mais efetiva entre as equipes de testes e o cliente, permitindo a realização de testes com um bom nível de detalhamento, sem prejuízo ao relacionamento entre testadores e desenvolvedores e à celeridade na entrega das soluções.

terça-feira, 22 de junho de 2010

A importância dos Testes de Aceitação

Quando falamos em testes de aceitação, normalmente nos lembramos da execução dos testes, quando o cliente ainda encontra alguns defeitos, mas que principalmente serve para a aprovação da solução entregue.

Certamente, a execução dos testes de aceitação é muito útil para que o cliente adquira confiança na qualidade do software, para mensurar a efetividade dos testes executados nos níveis anteriores ou para identificar alguns defeitos residuais. Mas uma grande contribuição que os testes de aceitação trazem para a qualidade da aplicação não está relacionada à execução dos testes, mas ao seu planejamento e projeto.


Ainda nas fases iniciais do desenvolvimento do software, quando seus requisitos estão sendo especificados com a participação do cliente, os testes de aceitação são também planejados e projetados. Esta atividade permite a construção de casos de teste, que mais tarde orientarão a execução dos testes de aceitação. Mas permite também a validação da definição dos requisitos pelo cliente, quando ele fundamenta e aprova o planejamento dos testes e os casos de teste projetados para a aceitação. Dessa forma, podemos evitar que determinados problemas na especificação dos requisitos passem para fases seguintes do desenvolvimento, o que pode comprometer a qualidade do software em construção e gerar retrabalho para o projeto. Além disso, é possível aproximar a visão das necessidades apresentadas pelo cliente dos requisitos efetivamente documentados, estabelecendo-se um acordo sobre os critérios de aceitação a serem observados na entrega da solução.

Portanto, com o apoio dos testes de aceitação, a qualidade do software pode ser beneficiada, tanto pela execução como pelo planejamento e projeto dos testes, que contribuem para a melhoria da especificação dos requisitos.

domingo, 30 de maio de 2010

O Custo da Qualidade de Software

Muito se fala sobre o custo elevado das atividades de teste e dos procedimentos que buscam garantir que um software tenha qualidade. Mas como um software adquire qualidade e quanto custa às organizações para que seus produtos atinjam um nível superior de excelência?

É possível que um software adquira qualidade tanto por uma construção que utilize processos maduros e bem definidos, como pela identificação e resolução dos problemas do software, antes que ele seja entregue aos usuários. Essa qualidade pode ser também atingida com a estabilização  pós-implantação do software, considerando nesse caso, a possibilidade de alguns ciclos desgastantes de ocorrência de falhas, identificação e correção de defeitos, com a liberação de novas versões da aplicação.

A cada uma dessas alternativas, está associado um custo específico. Esses custos, somados, constituem o custo da qualidade. O custo da qualidade é parte do custo total de produção do software, que contempla também os custos de sua construção.

Fonte: QAI - Quality Assurance Institute
Custo de Prevenção – Mais que um custo, é um investimento realizado para se evitar erros e fazer o trabalho certo na primeira tentativa. É um investimento com retorno a médio ou longo prazo e que contempla a criação de métodos e procedimentos, a melhoria de processos, a capacitação dos profissionais, a aquisição de ferramentas e o planejamento da qualidade. Esse custo ocorre antes da criação do produto.

Custo de Avaliação – Esse custo refere-se ao que é gasto em procedimentos de verificação e em testes dos produtos de software para identificação de defeitos, após a sua construção e antes que sejam disponibilizados para uso ou implantados em produção. Contempla tanto produtos intermediários, como documentos de requisitos, modelos de dados ou especificações, como também o produto de software final.

Custo de Falhas – Envolve todos os custos associados a produtos defeituosos, que já foram entregues aos usuários ou disponibilizados em produção e que geraram algum tipo de falha. Esses custos referem-se ao retrabalho para reparação de produtos defeituosos, ou a prejuízos decorrentes das falhas no software. Incluem-se nesta categoria, também os custos associados à manutenção de um Help Desk.

Considerando as categorias de custos que compõem o custo da qualidade, podemos perceber que ao investirmos estrategicamente na prevenção e na detecção de defeitos, os custos de falhas podem ser sensivelmente reduzidos, com reflexo direto sobre o custo da qualidade. Dessa forma, o custo total de produção de um software pode ser também diminuído, acompanhando a redução do custo da qualidade. Ponto para os processos de Garantia da Qualidade e de Testes de Software, que estruturam importantes atividades de prevenção e detecção de defeitos.


segunda-feira, 12 de abril de 2010

Desenvolvedores não gostam de testar!

Quando observamos os perfis psicológicos de desenvolvedores e testadores, percebemos algumas diferenças importantes na maneira de pensar desses profissionais.

Basicamente, os desenvolvedores têm suas energias direcionadas para a conclusão do projeto, sempre buscando executar com sucesso a implementação do software e provar que ele funciona. É uma forma de pensar muito diferente dos testadores, que estão sempre em busca de defeitos, certamente com o objetivo de trazer mais qualidade ao software, mas que pode parecer conflitante com a idéia de entrega do produto final. Até fora do trabalho, os testadores estão sempre procurando defeitos. Qual testador nunca se pegou perseguindo defeitos em placas de trânsito e anúncios pelas ruas ou em embalagens de produtos no supermercado? Esse comportamento faz parte do perfil do testador, que é um crítico por natureza.

Mas voltando aos desenvolvedores, sabemos que os testes podem e devem ser realizados também por  eles. A grande questão é como convencer um desenvolvedor a investir esforço em testar o seu produto. Os testes seriam sempre direcionados a provar que a aplicação funciona ou podemos adotar alguma abordagem que garanta uma certa isenção do desenvolvedor em relação ao produto e mais qualidade para os testes? 

Sabemos que uma boa parte dos defeitos pode ser identificada nos testes em nível unitário e integração, que normalmente ficam à cargo da equipe de desenvolvimento, quando existe na organização uma separação de papéis entre desenvolvedores e testadores. Dessa forma, a capacitação dos desenvolvedores para que realizem mais e melhor os testes sob sua responsabilidade, pode ser um investimento com possibilidades de excelente retorno para os projetos de desenvolvimento. Passar aos desenvolvedores conhecimentos básicos sobre testes pode fazer uma grande diferença na qualidade das aplicações. E nada que exija técnicas elaboradas de teste ou um esforço muito maior do que aquele já investido. Todo desenvolvedor testa, de alguma forma, a sua aplicação. O quanto ele testa é que é o problema. Como o seu foco é provar que a aplicação funciona, normalmente apenas o "caminho feliz" é testado e grande parte do código não é exercitado. 

Mesmo sem exigir profundos conhecimentos em testes, podemos ampliar significativamente a quantidade de testes executados, se no planejamento dos testes unitários e de integração for acordado um determinado nível de cobertura sobre o código, compatível com a criticidade da aplicação e com os riscos do projeto. Dessa forma, o desenvolvedor deverá perseguir essa cobertura do código em seus testes, sem necessariamente ter que modificar muita coisa na sua forma de testar. É claro que para que isso seja possível, será necessária a utilização de ferramentas apropriadas para avaliar o atingimento da cobertura esperada. Os testes nos níveis a cargo do desenvolvedor precisam ser apoiados por ferramental específico, de tal forma que o desenvolvedor possa direcionar sua atenção prioritariamente para o desenvolvimento e os testes ocorram de uma maneira natural para ele e com o menor esforço possível. A automação criteriosa dos testes e o direcionamento à cobertura do código podem evitar que grande parte dos defeitos seja identificada apenas em níveis posteriores de testes ou mesmo em produção, quando os custos de correção são muito maiores.

O mais importante de tudo isso é conseguir que o desenvolvedor teste o seu código com uma profundidade adequada, sem ser obrigado a realizar atividades que sejam conflitantes com o seu perfil. Com o apoio de ferramentas para avaliação da cobertura de código na execução dos testes,  o teste será encarado como um aliado pelos desenvolvedores, e a qualidade  final do software será a grande beneficiada.

sábado, 27 de março de 2010

Impressões sobre o CInTeQ 2010

Antes de qualquer comentário sobre o evento, gostaria de parabenizar a organização do CInTeQ 2010, pela iniciativa de trazer para o Brasil grandes nomes do teste de software, como Rex Black (foto ao lado), Eric van Veenendaal e Dorothy Graham. Iniciativas como esta são visionárias e permitem que os profissionais brasileiros mantenham-se atualizados em relação ao que acontece na área de testes e qualidade de software em todo o mundo. É importante ressaltar que algumas palestras nacionais também enriqueceram muito o evento, demonstrando que temos em nosso país profissionais extremamente capazes.

Gostei muito do congresso e as palestras que mais me chamaram a atenção foram:
  • Teste de Segurança em Aplicações WEB - Palestrante: Eduardo Habib
  • Lidando com os Desafios do Teste para as Metodologias Ágeis - Palestrante: Rex Black
  • A Importância da Especialização dos Papéis em uma Fábrica de Testes - Palestrante: Emílio Castro
  • Qualidade e Produtividade em Sistemas de Software: Um Desafio Brasileiro - Palestrante: Mauro Spínola
  • Melhoria do teste com TMMi - Melhoria do processo para o presente e futuro - Palestrante: Erik van Veenendaal
  • Ilusões Cognitivas no Desenvolvimento e Teste - Palestrante: Dorothy Graham
Outro aspecto importante desse tipo de evento, além das palestras com conteúdo de muita qualidade, é a oportunidade de contatos com diversos profissionais da área, que muitas vezes conhecemos apenas por listas de discussão ou através de seus blogs e artigos publicados. Um bom exemplo disso é o Fabrício Ferrari, que tive a oportunidade  de conhecer pessoalmente durante o evento. Pude perceber o entusiasmo e a dedicação do Fabrício em cobrir o evento e compartilhar com a comunidade tudo o que vimos nesses dois dias de congresso. O QualidadeBR, blog do Fabrício, traz uma cobertura bem completa e detalhada de todas as palestras. Não deixem de visitar esse excelente conteúdo!

Para quem não pôde participar neste ano, fica a dica: ao final do evento foi anunciado o CInTeQ 2011, que ocorrerá nos dias 28 e 29 de março do próximo ano. Programem-se desde já!

sábado, 20 de março de 2010

CInTeQ 2010

Acontecerá em São Paulo, nos dias 22 e 23 de março o CINTEQ 2010, um evento internacional sobre teste de software, promovido pelo BSTQB. Participaremos do evento, juntamente com outros profissionais do Banco do Brasil, que atuam na área. 

Seguem abaixo informações sobre o evento, que contará com a participação de vários nomes do teste nacional e internacional.

"O CInTeQ é um Congresso Internacional que apresenta assuntos relevantes sobre Teste e Qualidade de Software.
Ele vem preencher uma lacuna nos eventos nacionais, trazendo as mais importantes celebridades no assunto Teste de Software em âmbito mundial para o Brasil.
O Congresso vem em parceria com o encontro geral dos representantes mundiais do ISTQB organização que reúne mais de 40 países este ano na cidade do Rio de Janeiro. Por ser um evento fechado o BSTQB (representante brasileiro da organização) se mobilizou para trazer alguns destes representantes para realizar palestras e treinamentos para um evento que toda a comunidade tenha a oportunidade de falar e trocar informações com estes gurus da área.
Sendo realizado em São Paulo o CInTeQ pretende trazer um número elevado de participantes de todo o território nacional, já que possui toda a infra-estrutura de hotéis e transporte para os profissionais que desejem participar deste evento único no país."
Fonte: CINTEQ 2010.

Maiores informações: http://www.cinteq.org.br/

quinta-feira, 18 de fevereiro de 2010

Gerenciamento do Tempo em Projetos de Teste

Quando falamos sobre o gerenciamento do tempo em nosso último post, destacamos que algumas atividades podem nos ajudar a obter um maior controle sobre o tempo. Sob a visão de gerenciamento de projetos, essas atividades estão relacionadas principalmente à área de conhecimento de Gerenciamento do Tempo. Mas podemos perceber uma forte relação também com outras áreas, como  Gerenciamento de Custos, Riscos, Escopo, Qualidade e Integração.

Um dos primeiros e principais insumos para o gerenciamento do tempo dos projetos é o seu escopo,  que pode ser representado pela  Declaração de Escopo do Projeto, pela Estrutura Analítica do Projeto (EAP) e pelo Dicionário da EAP. Além do escopo, o Plano de Gerenciamento do Projeto também é um importante insumo para que o líder do projeto possa identificar as atividades que devem ser executadas.

Notem que quando falamos do projeto de teste, temos um escopo que é definido principalmente pelos requisitos do software, os quais serão validados através dos testes. Esses requisitos normalmente são entregues em pacotes, o que nos permite organizar as atividades de teste seguindo essa previsão de entregas. Mas atividades adicionais podem ser necessárias para cumprirmos os objetivos dos testes,  mesmo não sendo atividades de teste propriamente ditas e devem ser consideradas para um efetivo gerenciamento do tempo. Um bom exemplo disso, seriam atividades relacionadas à capacitação da equipe ou à aquisição e implantação de alguma ferramenta necessária à realização dos testes.

Definidas as atividades necessárias ao cumprimento dos objetivos do projeto de testes, precisamos organizá-las no tempo, estabelecendo uma sequência lógica de execução. Para esta organização, além das técnicas de sequenciamento previstas na literatura para todos os tipos de projetos, nos projetos de teste devemos observar também a relevância e os riscos associados aos requisitos, para estabelecermos aquilo que merece maior atenção. Isso pode afetar as relações de precedência entre as atividades. Em seguida, deve ser identificado o que será necessário prover para que cada atividade possa ser realizada, incluindo pessoas, equipamentos e ferramentas. O quanto de cada recurso, quando será utilizado e por quanto tempo, são também definições que ocorrem nesse momento e impactam fortemente os custos do projeto.

Todas essas definições são pré-requisitos para o desenvolvimento do cronograma de testes, que é um processo iterativo. Mas elas podem também ser afetadas pelo cronograma, o que pode exigir revisões sobre as estimativas de recursos e prazos já estabelecidos. É importante observarmos que o cronograma evolui  ao longo do projeto de teste, sensibilizado por mudanças no plano do projeto e em seu cronograma ou por ações decorrentes do gerenciamento de riscos associados ao projeto e seu escopo.

Gerenciar o tempo de projetos e principalmente de um projeto de testes, exige um acompanhamento cuidadoso do andamento das atividades, das mudanças ocorridas e da evolução dos riscos e do escopo do projeto. Em muitas ocasiões pode ser necessário sacrificar determinadas atividades para que os prazos do projeto sejam cumpridos. Nestas situações, é importante termos total controle sobre o cronograma e sobre o escopo dos testes. Isso nos permitirá reportar com propriedade aos intervenientes do projeto, o que está sendo sacrificado e quais os prejuízos à qualidade dos testes, informações preciosas para a tomada de decisão.

sábado, 13 de fevereiro de 2010

Gerenciando o Tempo

Há alguns dias eu estava discutindo a importância de se gerenciar adequadamente o tempo dos nossos projetos de teste. E apesar disso parecer tão óbvio, cheguei a conclusão que quase nunca conseguimos fazer isso muito bem, nem nos projetos, nem em nossa vida profissional ou mesmo na pessoal.

Geralmente gastamos grande parte do nosso tempo em atividades que agregam pouco valor e nem percebemos isso. É um tempo enorme lendo um caminhão de e-mails, navegando na web sem muita direção, ou simplesmente sentados à frente de uma TV, ao final de um dia pesado de trabalho.

É interessante sempre repensarmos a priorização que fazemos em nossas vidas, para que seja possível encontrar o equilíbrio entre as atividades que temos no dia-a-dia, conseguindo conciliar a vida profissional e pessoal, mantendo o prazer e a motivação nessas duas frentes.

Quando conseguimos identificar com clareza as atividades que são mais importantes e as colocamos numa sequência adequada, temos mais chances de executar a maior parte delas, o que pode nos trazer grande satisfação e sentimento de realização. Sem esse cuidado em identificar claramente o que precisamos ou queremos fazer e sem uma priorização adequada, dificilmente realizamos muita coisa.

Esse raciocínio é totalmente válido para as atividades de teste em nossos projetos, pois normalmente temos um escopo de teste muito maior que o tempo disponível para testá-lo adequadamente. Assim, se conseguirmos priorizar os nossos requisitos de teste, poderemos direcionar nossos esforços para aquilo que tem maior relevância. Não esqueçamos do Princípio de Pareto ao priorizarmos os nossos esforços.

É importante lembrarmos sempre de estabelecer prioridades e não querermos fazer tudo ao mesmo tempo. Dê importância ao que é importante.

domingo, 7 de fevereiro de 2010

Falando sobre Automação de Testes

Recebemos em Brasília no dia 05/02, em um evento direcionado aos profissionais de teste do Banco do Brasil, o consultor e instrutor na área de testes e qualidade, José Correia da Iterasys, que nos apresentou sua visão sobre o processo de testes e estratégias de automação.

A palestra tratou dos desafios da automação de testes, dos aspectos positivos e das possíveis frustrações. Foi ressaltada a importância de um bom planejamento, por parte da organização, nessa fase de automação do seu processo de  testes, abordando muito além da simples execução automatizada de atividades com maior velocidade. É necessário também que os processos sejam efetivamente melhorados.

Alguns aspectos abordados:

"Testar mais é possível" - Um forte argumento utilizado em defesa da automação é o ganho de produtividade decorrente. Mas para que isso realmente aconteça, não basta apenas automatizar o processo atual. É necessário pensar na melhor forma de se implementar a automação. "Mais, não necessariamente é melhor". "Se um processo produz um produto com defeito, automatizar esse processo só servirá para produzir uma grande quantidade de produtos defeituosos em menos tempo".

"Vai ficar pior antes de melhorar"- Ao automatizar os testes, possivelmente o processo ficará mais caro e lento, pois existe uma curva de aprendizagem. Somente depois de algum tempo é que os ganhos da automação serão percebidos.

"Vocabulário de Testes" - É um grande desafio no mercado de testes brasileiro, pois cada empresa tem um vocabulário diferente. As certificações têm um grande papel na unificação desse vocabulário.

"Testar melhor" -  Importante a utilização de uma metodologia de testes. Foi descrito o  Modelo V em sua representação mais conhecida e também como uma sequência de 8 peneiras (Requisitos, Análise, Arquitetura, Codificação, Testes Unitários, de Integração, Sistema e Aceitação), sendo que o profissional de testes pode participar em todas as fases do processo, pois qualidade deve ser uma preocupação em todas elas. Ao passar por todas essas peneiras, o produto possivelmente terá mais qualidade.

"Ferramentas de Automação" - Foram citados os principais tipos de ferramentas que apóiam o processo de testes: Planejamento de Testes, Gerência de Configuração, Virtualização, Registro de Defeitos, Padrões e Práticas, Cobertura de Código, Testes Unitários, Performance, Segurança e Robôs.

"ISO 9126 " - Características de Qualidade - Necessidade de se ampliar o escopo dos testes, utilizando o conjunto de características e sub-características de qualidade para direcionar os esforços da equipe.

"Testar mais rápido" - Para que isso seja possível é preciso antecipar os testes, acompanhando o processo de desenvolvimento desde suas fases iniciais. É preciso também saber quando interromper os testes. O tempo das áreas de negócio pode ser diferente do tempo da qualidade. 

"Testar a coisa certa" - Para se ter segurança do que se está testando, são necessárias ferramentas para Gerenciamento de Testes, Gerenciamento de Defeitos e Gerência de Configuração.

"Testar no ambiente certo" - O ambiente de testes foi descrito como um conjunto de fatores , não apenas de hardware. Fazem parte do ambiente, por exemplo, as pessoas envolvidas nas atividades de teste, softwares como ferramentas de teste, documentações do sistema, além do próprio hardware e ambiente físico.

"Virtualização" - Foi abordada a reprodução de ambientes de teste. No futuro os ambientes de produção também serão virtualizados, permitindo que os testes de uma aplicação sejam realizados compartilhando as mesmas condições de hardware e software disponíveis no ambiente produtivo.

"Testar mais barato" - Quando os testes se iniciam mais cedo dentro do ciclo de desenvolvimento, tem-se menos retrabalho e menor tempo para a liberação das soluções.

"Testar o que realmente importa" - Utilizar o gerenciamento de riscos para priorizar o que é mais importante, auxiliando no direcionamento dos esforços de teste. Uma estratégia de teste bem elaborada, considerando prioridades, é o que diferencia um teste produtivo de um teste improdutivo. Foram abordados também o Princípio de Pareto e o Diagrama de Causa e Efeito,ou Ishikawa, como ferramentas importantes para se priorizar o escopo de teste.

Concluindo sua palestra, José Correia ressaltou que o grande desafio na introdução da automação de testes numa organização não é aprender a utilizar as ferramentas ou se escolher a melhor ferramenta do mercado. O maior desafio é ter um processo robusto, que dê o embasamento necessário às atividades de teste.

Na sequência da palestra, foram abordadas as características das principais certificações em teste, especificamente a CSTE, a CBTS e a CTFL. Nessa exposição, foi ressaltada a grande oportunidade existente na área de testes e qualidade, onde temos uma carência enorme de profissionais e mesmo de conhecimentos sobre os temas da área. Os profissionais pioneiros certamente terão destaque nesse contexto.

Ao José Correia, o nosso agradecimento por compartilhar sua experiência profissional e vasto conhecimento. Esperamos tê-lo novamente conosco em outros eventos, contribuindo para a disseminação da cultura de testes e para o fortalecimento da área de testes e qualidade.

sábado, 6 de fevereiro de 2010

O futuro do Teste de Software

Aconteceu recentemente no DFTestes, uma boa discussão sobre o futuro do Teste de Software e gostaria de compartilhar com os leitores do Base de Teste a minha visão sobre esse tema.

Vejo o mercado de testes de software crescendo com muita velocidade nos últimos anos.
Há 3 ou 4 anos atrás, poucas empresas tinham equipes de teste independentes bem estruturadas. Hoje vemos essa estrutura se multiplicar, tanto em empresas que trabalham com desenvolvimento, como naquelas que utilizam os serviços de fábricas de teste para validar as aplicações desenvolvidas por terceiros.

A terceirização de serviços de teste é uma forte tendência, complementando a capacidade de teste interna das organizações. A especialização conseguida com as estruturas de fábrica trazem muitos benefícios para o contratante, principalmente na escalabilidade no atendimento de suas demandas e na independência dos testes em relação ao desenvolvimento.

Com esse mercado aquecido, as empresas investirão maior esforço na seleção de seus times, pois aquelas que estiverem melhor estruturadas, vencerão a corrida pelos melhores contratos. Por outro lado, os profissionais de teste também deverão investir mais em sua empregabilidade. Nesse aspecto, as certificações serão um grande diferencial, principalmente aquelas que conseguirem distinguir profissionais com maior conhecimento e experiência.

Venho comentando há tempos com alguns colegas, que o teste é o carro chefe para a melhoria de muitos processos. É um processo que catalisa uma mudança cultural nas organizações, na direção de uma busca contínua pela qualidade.

É bonito ver isso acontecendo com a nossa área e saber que fazemos parte desse movimento!

sábado, 9 de janeiro de 2010

Garantia da Qualidade de Software

Conforme o QAI - Quality Assurance Institute, o processo de Garantia da Qualidade é formado por um conjunto planejado e sistemático de atividades, que tem por objetivo prover confiança sobre a conformidade de produtos e serviços a requisitos especificados e que venham ao encontro das necessidades dos usuários. Já para o MPS-br - Melhoria do Processo de Software Brasileiro, o propósito do processo Garantia da Qualidade é assegurar que os produtos de trabalho e a execução dos processos estão em conformidade com os planos e recursos predefinidos.

Estas duas visões normalmente conduzem a uma confusão muito comum, ao compararmos os processos de Controle e de Garantia de Qualidade de Software. Notamos que o conceito de Garantia da Qualidade é muito próximo daquele que já discutimos sobre o Controle da Qualidade, principalmente pelo fato de os dois processos definirem atividades que tratam da qualidade do software.

Entretanto, a Garantia da Qualidade tem seu foco na prevenção de inconformidades e na melhoria contínua de processos, enquanto o Controle da Qualidade busca identificar e corrigir estas inconformidades, num processo muito mais reativo. Esses dois processos são complementares e muitas vezes são executados através de atividades semelhantes, como na aplicação de Listas de Verificação ou checklists. A grande diferença é o foco em prevenção ou em detecção.

Assim, se você estiver verificando um documento com a intenção de identificar e corrigir eventuais inconformidades, certamente estará trabalhando em uma atividade de Controle da Qualidade. Mas se o seu objetivo é avaliar o processo que gerou este documento, procurando analisar suas fragilidades e otimizar a execução das atividades previstas, estará trabalhando na Garantia da Qualidade deste processo.

Então, como diferenciar esses dois processos no dia-a-dia? Não parece muito fácil, mas uma forma bem simples é lembrarmos das palavras Prevenção e Detecção.
    • Prevenção refere-se à Garantia da Qualidade
    • Detecção refere-se ao Controle da Qualidade
Esta diferenciação é válida, principalmente no contexto do Teste de Software e das certificações como a CSTE. Entretanto, observando a definição de Garantia da Qualidade feita pelo MPS-br, percebemos que é importante termos o cuidado de avaliar o contexto onde os termos Controle e Garantia são utilizados, para construirmos o entendimento mais adequado a cada caso.


Referências

Guia de Implementação - Parte 2 - Fundamentação para Implementação Nível F do MR-MPS
Disponível em: http://www.softex.br/mpsbr/...

Guide to the CSTE COMMON BODY OF KNOWLEDGE - Version 6.2 - 2006
QAI - Quality Assurance Institute

    domingo, 3 de janeiro de 2010

    Controle da Qualidade de Software

    Controle da Qualidade, no contexto de software, é o processo que compara um produto com normas, padrões e requisitos estabelecidos, procurando identificar inconformidades, para que estas possam ser corrigidas antes que o produto chegue ao seu ambiente de uso. Tendo seu foco na detecção de defeitos, trata-se de um processo essencial na indústria de software atual, cada vez mais competitiva e exigente. Nessa indústria, qualidade não é mais diferencial competitivo, mas requisito básico para que os produtos desenvolvidos sejam bem recebidos pelo mercado.

    Ao contrário do que se pode imaginar de um processo que busca por defeitos em produtos, o Controle da Qualidade não ocorre apenas ao final de um processo produtivo, principalmente quando falamos de desenvolvimento de software. O Controle da Qualidade pode ser aplicado sobre os produtos do processo de desenvolvimento desde suas fases iniciais, permitindo que produtos intermediários sejam verificados e que os defeitos identificados sejam corrigidos antes que se propaguem às fases seguintes da construção do software.

    Dessa forma, podemos controlar a qualidade de um Documento de Especificação de Requisitos ou de um Modelo de Dados por exemplo, identificando precocemente defeitos que poderiam causar grandes prejuízos  no futuro. Isso é possível, dentre outras formas, através da aplicação de Listas de Verificação sobre os documentos gerados durante a construção do software ou pela aplicação de Testes de Software. Quando as inconformidades identificadas são corrigidas, as fases seguintes do processo de desenvolvimento recebem insumos de maior qualidade, o que contribui substancialmente para a qualidade final do software.

    Investir na detecção de defeitos, através de um Controle da Qualidade sistemático, é muito mais que uma forma eficiente de se reduzir o custo total do software, ao evitar prejuízos decorrentes de falhas em produção. Envolve a satisfação do cliente final, que espera receber um software com qualidade superior e que atenda satisfatoriamente as suas expectativas.