Essa é a minha contribuição para o livro do DFTestes.
Falei um pouco sobre a problemática da falta de documentação para a equipe de testes.
Confiram outros capítulos na página do livro.
1. Introdução
De acordo com o RUP, caso de teste "é a definição (geralmente formal) de um conjunto específico de inputs de teste, condições de execução e resultados esperados, identificados com a finalidade de avaliar um determinado aspecto de um item de Teste-alvo". Duas disciplinas da Engenharia de Software provêem informações para criação dos casos de teste. São elas: Engenharia de Requisitos e Projeto.
De acordo com o IEEE, a Engenharia de Requisitos é o processo de aquisição, refinamento e verificação das necessidades do cliente. Dentro das diversas metodologias de desenvolvimento há maneiras distintas de documentar requisitos. No RUP, o principal documento gerado, que é utilizado pela equipe de teste, são os Modelos de Caso de Uso; já nas metodologias ágeis, um documento mais comum é o conjunto de User Stories. Na prática, muitas equipes não têm nem os Casos de Uso e nem as User Stories, mas sim, descrições em alto nível dos requisitos, sejam elas por escrito ou não.
A disciplina de Projeto, por sua vez gera documentos complementares às especificações de Requisitos. Nessa etapa, a estrutura interna do software é descrita através de diagramas. A utilização da linguagem UML é bastante recomendada na geração desses diagramas. Exemplos de diagramas de projeto são Diagramas de Estados, Diagramas de Seqüência e Diagrama de Atividades, entre outros.
Essa documentação serve como apoio para a elaboração dos testes. Todas elas são de grande valia para o analista no seu projeto de casos de teste. Mas e se o analista não as tiver? É possível, mesmo assim, testar? Essa é a pergunta tema da Nona Mesa Redonda do DFTestes.
Esse tema nos fez refletir sobre a necessidade da documentação para o teste. Primeiramente não vamos confundir necessidade com importância. Denotativamente o termo necessidade significa uma obrigação imprescindível, enquanto que importância ou relevância significa valor.
As participações nessa mesa redonda são freqüentemente utilizadas no texto que segue para expressar a opinião da comunidade sobre o assunto.
2. Testes Exploratórios
É possível sim testar sem scripts e isso já não se pode chamar de novidade. O termo "testes exploratórios" foi citado pela primeira vez por Cem Kaner em seu livro Testing Computer Software (1999).
Segundo James Bach, testes exploratórios são simultaneamente um aprendizado, um projeto e uma execução de teste. Através da profunda exploração das habilidades de ouvir, ler, pensar e reportar eficazmente, os testes exploratórios podem trazer informações muito importantes de maneira tão ou mais produtiva que os testes baseados em casos de teste. A falta de um script a ser seguido tende a potencializar essas habilidades.
3. Escolas de Teste
Sobre a documentação em que iremos embasar a criação dos casos de teste, o Jorge Diz disse: "não coloquemos todas as nossas fichas na documentação do sistema. Com certeza, é possível testar sem documentação formal: pode ser mais ou menos eficaz, dependendo do contexto. E sempre devemos lembrar que o documento mais atualizado é sempre o próprio sistema sendo testado."
O contexto! Esse é o grande segredo dessa discussão. A eficácia do seu teste pode ou não ser impactada pela falta de documentação considerando diversos cenários. É papel do analista de testes sinalizar até que ponto ele consegue aferir a qualidade do sistema com as ferramentas (documentação, especialista, etc.) que lhe foram dadas.
Dentro das Escolas de Teste, veremos que de acordo com as características de cada escola (um contexto), o tema "testar sem documentação é possível?" é tratado de maneiras diferentes.
De acordo com Pettichord (2007), uma escola é definida por afinidades intelectuais, interação social e objetivos comuns. São compostas por uma hierarquia de valores, técnicas, padrões de crítica, instituições organizadas e vocabulário comum.
Existem cinco escolas de teste e suas visões são:
Escola Analítica: o teste deve ser rigoroso e técnico, com base na academia
Escola Padrão: o teste é uma maneira de medir o progresso com ênfase no custo e padrões repetíveis
Escola da Qualidade: enfatiza o processo e policia os desenvolvedores
Escola baseada em Contexto: enfatiza as pessoas, procuram bugs com os quais os clientes se importam mais
Escola Ágil: usa o teste para provar que o desenvolvimento está completo. Enfatiza o teste automatizado
Sobre os testes sem documentação, são a favor:
Escola baseada em Contexto: "Faça o que puder para ser útil. Faça perguntas se necessário. Desencave especificações escondidas."
Escola Ágil: "Conversas são mais importantes que documentação"
E são contra:
Escola Analítica: "É impossível"
Escola Padrão: "Algum tipo de documentação é necessária"
Escola da Qualidade: "Force os desenvolvedores a seguir o processo"
Como cada escola vive um contexto e analisa o teste de acordo com os seus cenários, cada uma expressa uma visão diferente da possibilidade de testar sem documentação. Na visão geral dos participantes da discussão, testar sem documentação não é impossível, mas essa abordagem também não foi defendida como a melhor prática. A comunidade do DFTestes parece ter uma tendência muito próxima a da Escola baseada em Contexto, entendendo que não devemos olhar as nossas dificuldades de documentação como muros intransponíveis, mas como empecilhos que devem ser vencidos.
4. Reflexões da Mesa Redonda
"À medida que os sistemas se tornam mais complexos, os riscos se tornam maiores, chegando ao ponto no qual ninguém conhece o que há no sistema. Isto é ruim não só para o teste, mas também para todas as fases anteriores do desenvolvimento.
Falando de casos de uso ou similares, um dos problemas comuns de quem não tem essa documentação é o de não saber o que testar. Recentemente fiz uma análise de cobertura de código em um programa de pedidos e concluí que ao incluir um pedido neste sistema com o máximo de opções que consegui informar, não cobri nem 20% do código. Se você não tem nada para consultar, como testar os outros 80% de forma eficiente? Agora imaginem se este programa estivesse 60% documentado com casos de uso e casos de teste. Já seria uma garantia bem maior.
Outro problema é o de não saber o que alterar. Recentemente em um projeto foi esquecido de alterar um programa, e só esse programa gerou mais estresse que todas as outras alterações juntas porque estava dando problema lá no cliente. Sem documentação, não há rastreabilidade." [Ismael Munchen]
Na colocação do Ismael conclui-se que:
1. Falta de documentação pode prejudicar a cobertura dos testes
2. Falta de documentação implica em falta de rastreabilidade e aumento dos riscos nas manutenções do sistema
A visão do Marcelo Andrade complementa o primeiro cenário do Ismael:
"Claro que não dá para testar tirando conclusões sobre regras de negócio da própria cabeça do testador. Neste caso, se a informação está disponível (com o cliente ou com quem quer que seja) é ela que deve ser buscada."
Então, na falta de uma documentação, caso haja alguma outra fonte de conhecimento sobre os requisitos, ela viabiliza os testes e também aumenta a sua cobertura. Essa opinião também foi expressa pela Andrea Cruz quando ela fala que "testar sem documentação é possível, porém podem existir em determinados sistemas requisitos implícitos importantes que podem não ser cobertos pelo teste."
Existe sem dúvida um risco na falta de documentação. Para ser bem sucedido, o Analista de Teste precisa contar com alguma outra fonte de informação, ou a sua cobertura poderá ser seriamente prejudicada.
Segundo Daniel Goettenauer, "o beneficio da documentação só é percebido atualmente em grandes projetos, onde os testes de regressão são constantes e existem muitas mudanças.
[...] dependendo do tamanho do projeto de teste a documentação poderia ser tratada de forma mais simples (documentos básicos) ou complexa (todos os documentos). Dessa forma não teríamos projetos desenvolvidos em 16 horas e testados em 72 horas por conta do volume de documentação."
Ter algum nível de documentação é mesmo importante, entretanto o que define sua necessidade? Uma documentação necessária é aquela que é consultada e mantida, que serve de apoio para o time ou, não se encaixando em nenhum desses objetivos, ela se torna necessária apenas se for uma requisição do cliente. Jeffries, 2001 expõe em seu blog esse mesmo ponto quando fala que "você pode precisar de um UML bem formatado para o seu projeto, ou você pode precisar imprimir o Javadoc quando distribuir o seu código para outros, ou você pode precisar documentar os requisitos para o gerenciamento ou como parte de um contrato. Se e quando você realmente precisar dessas documentações, você deve realmente tê-las." Se elas não forem realmente necessárias apenas demandam tempo da equipe e nem sempre são mantidas adequadamente.
Um sem número de documentos que são criados no início do projeto e não sofrem mais atualizações é uma realidade em muitos projetos. De acordo com o Shmuel, "uma documentação desatualizada é menos útil, mas ainda pode ser usada da mesma maneira. Mas essa ajuda não é um pré-requisito necessário, e podemos testar mesmo sem tê-la. Por meio de abstrações e inferências, é possível aprender sobre o programa de várias outras maneiras, durante os testes, durante conversas, durante as discussões sobre bugs etc.”
Essa opinião está alinhada com uma pesquisa do IEEE, 2003 em que entrevistas com engenheiros de software revelaram as seguintes opiniões sobre documentação:
"- Documento de arquitetura e outras documentações abstratas são freqüentemente válidos ou ao menos provêem um guia histórico que pode ser útil para manutenção.
- Documentações de todos os tipos freqüentemente estão desatualizadas
- Uma fração considerável da documentação não é confiável. "
O Felipe da Silva trouxe um ponto diferente sobre a necessidade e assinalou outro uso dado à documentação fora o projeto de testes que é o de contrato. É comum utilizarmos uma documentação e a aprovação do cliente como um contrato ou parte dele na definição de escopo e base para cronograma. Segundo Felipe, "na maioria dos casos além de brigarmos para querer ter um sistema testável por qualquer um, em determinados processos de engenharia de software também brigamos porque queremos ter um documento como "defesa" contra a insatisfação do cliente. É aquele problema que se você não documenta, o cliente não assina, se ele não assina, não existe um registro que ele havia dito que era aquilo que ele queria, correndo o risco do cliente reclamar e ter melhorias no sistema sem pagar por elas nem ajustar cronograma e etc."
5. Conclusão
As opiniões expostas na Mesa Redonda levaram a um entendimento de que a documentação pode não ser necessária, mas é importante. O tema é bastante abrangente e a cada participação na lista foi possível idealizar novos cenários para responder a mesma pergunta. E você? A que conclusão chegou após ler o que discutimos em mais uma edição da Mesa Redonda do DFTestes?
Participantes da Nona Mesa Redonda:
Fabrício, Shmuel Gershon, Juliana Kryszczun, Ueslei Aquino, Ana Rosa, Sarah Pimentel, Fernanda Coelho, Ismael Munchen, Daniel Goettenauer, Felipe da Silva, Cristiana Yukie, Rodrigo Almeida, Rodrigo Souza, Andrea Cruz, Marcelo Andrade e Jorge Diz.
Referências:
Much Ado About Nothing: Documentation
Ron Jeffries 2001
Schools of Software Testing
Bret Pettichord, 2007
How Software Engineers Use Documentation: The State of the Practice
Timothy C. Lethbridge, Janice Singer, Andrew Forward
IEEE Computer Society
2003
Exploratory Testing Explained
James Bach, 2003
Mostrando postagens com marcador qualidade. Mostrar todas as postagens
Mostrando postagens com marcador qualidade. Mostrar todas as postagens
segunda-feira, 16 de agosto de 2010
terça-feira, 29 de setembro de 2009
Pragas do Teste de Software
Em Junho o James Whittaker começou uma série de publicações entituladas The 7 Plagues of Software Testing (As 7 pragas do teste de software), baseadas em um encontro interno na Google em que ele falou sobre o tema. No GTAC (Google Test Automation Conference) ele abordou o mesmo assunto.
Achei muito interessante e resolvi fazer um post reunindo essas publicações que podem ser encontradas no blog do google. Quem se interessar em ver os artigos na íntegra, seguem os links na ordem de publicação:
The 7 Plagues of Software Testing
June 22, 2009
The plague of repetitiveness
June 24, 2009
The Plague of Amnesia
July 13, 2009
The Plague of Boredom
July 21, 2009
The Plague of Homelessness
July 23, 2009
The Plague of Blindness
July 29, 2009
The 7th Plague?
August 10, 2009
The 7th Plague and Beyond
September 02, 2009
The Plague of Entropy
September 14, 2009
A PRAGA DA FALTA DE PROPÓSITO
Whittaker fala sobre a falta de um pool de conhecimento comum, sobre estarmos sempre reinventando a roda que alguém, as vezes até mesmo dentro da nossa empresa, já inventou. Sobre a falta de compartilhamento de conhecimentos, a falta de objetivos.
Por que testamos? Já se fez essa pergunta? Sabe respondê-la? Muitas das respostas poderiam ser: “Porque meu gerente me disse pra testar”. E por que automatizar? Também muitas das respostas poderiam ser: “Porque eu sei programar”. Infelizmente não seria um concenso responder que isso faz parte de uma estratégia e mesmo do set dos que pensaram nisso como resposta, apenas uma parte saberia explicar essa estratégia.
Contrariando o slogan da Nike “just do it”, que funciona muito bem para execicios físicos, mas péssimamente mal para teste de software, Whittaker nos convida a parar, pensar e perguntar-se: “Qual o meu objetivo?”, “Qual o propósito desse teste?”
Documente seu sucesso, avalie seus fracassos e compartilhe o resultado da sua introspecção com seus colegas.
A PRAGA DA REPETIÇÃO
Se a falta de proposito é resultado do “just do it”, então a repetição é o “just do it” várias e várias vezes.
Nesse post Whittaker cita o paradoxido do pesticida de Boris Beizer’s. Pesticidas matam insetos (bugs ;) ), mas se usar sempre o mesmo veneno, os insetos que sobreviveram vão ficar imunes a ele. Em testes, se usarmos sempre as mesmas estratégias, os mesmos testes, teremos a falsa sensação de não ter bugs, mascarando métricas e resultados, onde na verdade o que ocorre é o efeito do noss teste não é mais tão abrangente.
Questione-se qual o valor que os seus testes estão agregando, varie, mude a ordem de execução, encontre variações de ambientes e dados aplicáveis e impeça a sua aplicação de ficar imune aos seus testes.
A PRAGA DA AMNÉSIA
Whittaker fala sobre dois tipos de amnésia: a do time e a da indústria.
Sobre a do time, parece que cada projeto é um novo começo. O time esquece dos seus projetos anteriores, dos bugs encontrados anteriormente, dos testes, etc. Na verdade cada novo projeto é um objetivo novo para um time que já ganhou experiências em outros projetos. O que falta é um mecanismo de retenção de conhecimento.
Sobre a da indústria: você já tinha ouvido falar ou lido sobre o exemplo dado do pesticida de Boris Beizer? As chances de ninguém ter passado pela mesma dificuldade que você está tendo agora nos seus testes é mínima. Mas a memória coletiva da indústria é muito fraca e falta compartilhamento de conhecimento o que leva as pessoas a estarem sempre perdendo tempo e reinventando a roda.
A PRAGA DO TÉDIO
“Testar é chato”. Eu mesma já disse isso em algum momento :). Há alguns aspectos monótonos e não criativos no teste. No início, a sensação de estar caçando bugs e encontrá-los pode manter o profissional motivado por algum tempo, mas depois é preciso algo mais.
Projetar testes, definir estratégias, selecionar o que vai ou não ser testado, como vai ser testado, são atividades mais desafiadoras intectualmente que podem afastar a mesmice.
A PRAGA DA FALTA DE AMBIENTE
Há dois grupos de detectores de bugs, os profissionais de teste e os usuários. No caso dos usuários, eles encontram os erros casualmente executando suas rotinas, não planejam encontrar os bugs, simplesmente os encontram.
E porque não achamos todos os bugs do sistema? Por que por melhor que seja a nossa estratégia, ainda assim há o risco de o usuário encontrar falhas que não encontramos? Porque ele que está em contato com o sistema no habitat ideal.
Whittaker faz uma compração com uma casa. Por mais que uma obra seja conduzida com todo esmero, supervisão, etc, alguns problemas só serão encontrados quando houver alguém morando lá e utilizando a estrutura no dia a dia.
Por mais que tentemos criar um ambiente igual ao do usuário (que já é muito difícil) ainda assim ficarão gaps que podem ser espaço de bugs. Por isso o período de garantia de um software.
A PRAGA DA CEGUEIRA
Testar um software é similar a jogar vendado um jogo de videogame sem informação alguma das variáveis em jogo. Se você é o Hyu e consegue dar uma série de Ha Dou Kens sem o seu adversário se mexer até fica fácil, mas sem saber o lifescore do seu personagens fica dificil tomar decisões. Agora imagine-se jogando Warcraft sem ver seus inimigos ou qualquer outro jogo que você tenha que acertar (mesmo que nao seja matando :P) um alvo e não consegue vê-lo. Bom, teste tem muito disso. Você não sabe onde estão os bugs. Pior ainda, muitas vezes não se pode atestar a cobertura dos testes e as vezes sequer tomamos conhecimento de mudanças no código.
É preciso ter a segurança de poder responder perguntas como a cobertura de testes, o que mudou de um build para outro, que partes do software costumam ter mais bugs, quais são alteradas com mais frequencia, etc.
THE 7TH PLAGUE AND BEYOND
No post The 7th Plague and Beyond, Whittaker fala que recebeu várias sugestões do que poderia ser a sétima praga. Seguem abaixo:
A praga das métricas: Métricas as vezes mudam comportamentos e deixam de ser uma medida de comportamento para ser um alvo, um objetivo.
A praga da semantica: Não há um dialeto comum. Alguns termos de especificações são comumente mal interpretados por essa falta de senso.
A praga da inifinidade ou da exastão: Saimos do foco muitas vezes por sermos obrigados a passar a maior parte do tempo explicando porque estamos ou não testando algo. Sempre que temos um novo objeto de testes temos riscos associados e começa tudo de novo.
A praga da má comunicação: A linguagem de criação (desenvolvimento) e a de destruição (testes) são diferentes.Os desenvolvedores não entendem os reports de defeito dos testers. Alguns dos casos de reabertura de defeito por má ou falta de correção dos desevolvedores são por falta de entendimento do desenvolvedor em relação ao bug. Nesse caso ao inves de má comunicação, as vezes é falta de comunicação mesmo.
A praga da rigidez: A criatividade muitas vezes não é permitida. Há rigidez nos processos, nas estratégias e isso se torna um empecilho ao desenvolvimento do nosso trabalho.
A PRAGA DA ENTROPIA
Entropia é uma medida de incerteza. Considerando 5 eventos, se a probabilidade deles acontecerem é igual, então temos o valor máximo de entropia e se um evento é certo e os outros 4 impossívels, temos o valor mínimo de entropia.
Testers inserem entropia no desenvolvimento quando adicionam tarefas aos desenvolvedores. Quando os devs estão apenas escrevendo o codigo da aplicação, a entropia é baixa, quando submetemos bugs, a entropia começa a aumentar. Quanto mais tarefas paralelas, maior a entropia, maior a probabilidade de inserção de novos bugs.
Acabar com a entropia é “fácil”. Basta termos desenvolvedores que nunca erram :). Ou uma solução mais tangível é estarmos atentos a essa entropia e gerenciarmos melhor essas atividades.
E quais são as pragas que afetam o seu dia a dia?
Achei muito interessante e resolvi fazer um post reunindo essas publicações que podem ser encontradas no blog do google. Quem se interessar em ver os artigos na íntegra, seguem os links na ordem de publicação:
The 7 Plagues of Software Testing
June 22, 2009
The plague of repetitiveness
June 24, 2009
The Plague of Amnesia
July 13, 2009
The Plague of Boredom
July 21, 2009
The Plague of Homelessness
July 23, 2009
The Plague of Blindness
July 29, 2009
The 7th Plague?
August 10, 2009
The 7th Plague and Beyond
September 02, 2009
The Plague of Entropy
September 14, 2009
A PRAGA DA FALTA DE PROPÓSITO
Whittaker fala sobre a falta de um pool de conhecimento comum, sobre estarmos sempre reinventando a roda que alguém, as vezes até mesmo dentro da nossa empresa, já inventou. Sobre a falta de compartilhamento de conhecimentos, a falta de objetivos.
Por que testamos? Já se fez essa pergunta? Sabe respondê-la? Muitas das respostas poderiam ser: “Porque meu gerente me disse pra testar”. E por que automatizar? Também muitas das respostas poderiam ser: “Porque eu sei programar”. Infelizmente não seria um concenso responder que isso faz parte de uma estratégia e mesmo do set dos que pensaram nisso como resposta, apenas uma parte saberia explicar essa estratégia.
Contrariando o slogan da Nike “just do it”, que funciona muito bem para execicios físicos, mas péssimamente mal para teste de software, Whittaker nos convida a parar, pensar e perguntar-se: “Qual o meu objetivo?”, “Qual o propósito desse teste?”
Documente seu sucesso, avalie seus fracassos e compartilhe o resultado da sua introspecção com seus colegas.
A PRAGA DA REPETIÇÃO
Se a falta de proposito é resultado do “just do it”, então a repetição é o “just do it” várias e várias vezes.
Nesse post Whittaker cita o paradoxido do pesticida de Boris Beizer’s. Pesticidas matam insetos (bugs ;) ), mas se usar sempre o mesmo veneno, os insetos que sobreviveram vão ficar imunes a ele. Em testes, se usarmos sempre as mesmas estratégias, os mesmos testes, teremos a falsa sensação de não ter bugs, mascarando métricas e resultados, onde na verdade o que ocorre é o efeito do noss teste não é mais tão abrangente.
Questione-se qual o valor que os seus testes estão agregando, varie, mude a ordem de execução, encontre variações de ambientes e dados aplicáveis e impeça a sua aplicação de ficar imune aos seus testes.
A PRAGA DA AMNÉSIA
Whittaker fala sobre dois tipos de amnésia: a do time e a da indústria.
Sobre a do time, parece que cada projeto é um novo começo. O time esquece dos seus projetos anteriores, dos bugs encontrados anteriormente, dos testes, etc. Na verdade cada novo projeto é um objetivo novo para um time que já ganhou experiências em outros projetos. O que falta é um mecanismo de retenção de conhecimento.
Sobre a da indústria: você já tinha ouvido falar ou lido sobre o exemplo dado do pesticida de Boris Beizer? As chances de ninguém ter passado pela mesma dificuldade que você está tendo agora nos seus testes é mínima. Mas a memória coletiva da indústria é muito fraca e falta compartilhamento de conhecimento o que leva as pessoas a estarem sempre perdendo tempo e reinventando a roda.
A PRAGA DO TÉDIO
“Testar é chato”. Eu mesma já disse isso em algum momento :). Há alguns aspectos monótonos e não criativos no teste. No início, a sensação de estar caçando bugs e encontrá-los pode manter o profissional motivado por algum tempo, mas depois é preciso algo mais.
Projetar testes, definir estratégias, selecionar o que vai ou não ser testado, como vai ser testado, são atividades mais desafiadoras intectualmente que podem afastar a mesmice.
A PRAGA DA FALTA DE AMBIENTE
Há dois grupos de detectores de bugs, os profissionais de teste e os usuários. No caso dos usuários, eles encontram os erros casualmente executando suas rotinas, não planejam encontrar os bugs, simplesmente os encontram.
E porque não achamos todos os bugs do sistema? Por que por melhor que seja a nossa estratégia, ainda assim há o risco de o usuário encontrar falhas que não encontramos? Porque ele que está em contato com o sistema no habitat ideal.
Whittaker faz uma compração com uma casa. Por mais que uma obra seja conduzida com todo esmero, supervisão, etc, alguns problemas só serão encontrados quando houver alguém morando lá e utilizando a estrutura no dia a dia.
Por mais que tentemos criar um ambiente igual ao do usuário (que já é muito difícil) ainda assim ficarão gaps que podem ser espaço de bugs. Por isso o período de garantia de um software.
A PRAGA DA CEGUEIRA
Testar um software é similar a jogar vendado um jogo de videogame sem informação alguma das variáveis em jogo. Se você é o Hyu e consegue dar uma série de Ha Dou Kens sem o seu adversário se mexer até fica fácil, mas sem saber o lifescore do seu personagens fica dificil tomar decisões. Agora imagine-se jogando Warcraft sem ver seus inimigos ou qualquer outro jogo que você tenha que acertar (mesmo que nao seja matando :P) um alvo e não consegue vê-lo. Bom, teste tem muito disso. Você não sabe onde estão os bugs. Pior ainda, muitas vezes não se pode atestar a cobertura dos testes e as vezes sequer tomamos conhecimento de mudanças no código.
É preciso ter a segurança de poder responder perguntas como a cobertura de testes, o que mudou de um build para outro, que partes do software costumam ter mais bugs, quais são alteradas com mais frequencia, etc.
THE 7TH PLAGUE AND BEYOND
No post The 7th Plague and Beyond, Whittaker fala que recebeu várias sugestões do que poderia ser a sétima praga. Seguem abaixo:
A praga das métricas: Métricas as vezes mudam comportamentos e deixam de ser uma medida de comportamento para ser um alvo, um objetivo.
A praga da semantica: Não há um dialeto comum. Alguns termos de especificações são comumente mal interpretados por essa falta de senso.
A praga da inifinidade ou da exastão: Saimos do foco muitas vezes por sermos obrigados a passar a maior parte do tempo explicando porque estamos ou não testando algo. Sempre que temos um novo objeto de testes temos riscos associados e começa tudo de novo.
A praga da má comunicação: A linguagem de criação (desenvolvimento) e a de destruição (testes) são diferentes.Os desenvolvedores não entendem os reports de defeito dos testers. Alguns dos casos de reabertura de defeito por má ou falta de correção dos desevolvedores são por falta de entendimento do desenvolvedor em relação ao bug. Nesse caso ao inves de má comunicação, as vezes é falta de comunicação mesmo.
A praga da rigidez: A criatividade muitas vezes não é permitida. Há rigidez nos processos, nas estratégias e isso se torna um empecilho ao desenvolvimento do nosso trabalho.
A PRAGA DA ENTROPIA
Entropia é uma medida de incerteza. Considerando 5 eventos, se a probabilidade deles acontecerem é igual, então temos o valor máximo de entropia e se um evento é certo e os outros 4 impossívels, temos o valor mínimo de entropia.
Testers inserem entropia no desenvolvimento quando adicionam tarefas aos desenvolvedores. Quando os devs estão apenas escrevendo o codigo da aplicação, a entropia é baixa, quando submetemos bugs, a entropia começa a aumentar. Quanto mais tarefas paralelas, maior a entropia, maior a probabilidade de inserção de novos bugs.
Acabar com a entropia é “fácil”. Basta termos desenvolvedores que nunca erram :). Ou uma solução mais tangível é estarmos atentos a essa entropia e gerenciarmos melhor essas atividades.
E quais são as pragas que afetam o seu dia a dia?
quinta-feira, 3 de setembro de 2009
Processo de Teste: Avaliando critérios de saída e reportando
Falamos sobre Análise e Projeto de Teste de Software:
Estudo CTAL: Processo de Teste
Falamos sobre Implementação e Execução em dois artigos:
Processo de Teste: Implementação e Execução
Processo de Teste: Implementação e Execução II
E o próximo ponto importante para o Analista de Testes é avaliar os critérios de saída e gerar relatórios para acompanhamento do gerente.
Nesse ponto do processo serão coletadas informações para o gerenciamento e medido o progresso, que consequentemente leva a detecção de desvios do plano.
Para medir a completude do teste é possível considerar informações como:
- Número de condições de teste, casos de teste, ou procedimentos de teste planejados, executados, passados, e falhados
- Número total de defeitos classificados por severidade, prioridade, status, ou outro fator relevante
- Requisições de mudanças (change requests) propostas, aceitas, testadas
- Planejado versus real: Custos, cronograma, esforço...
- Riscos de qualidade mitigados e os restantes
- Tempo de teste perdido com eventos que bloquearam testes (time de implementação não liberou a versão na data planejada, o ambiente estava fora, etc)
- Resultados dos testes de confirmação e regressão
Resumo do Test Suite
Permite fazer um tracking de algumas propriedades importantes da execução
Nesta tabela podemos avaliar:
- Progresso dos testes cases
- Taxas de testes passados e falhados
- Defeitos por test suite de acordo com prioridade/severidade (weighted failure)
- Valor agregado
No lado esquerdo, as duas primeiras colunas são o nome do test suite e o número de caso de testes dele.
Depois, sob Planning Tests Fulfilled, tem-se os testes que estão prontos, que não tem nenhum trabalho adicional a ser feito neles.
Weighted Failure é uma métrica para os bugs encontrados em casa suite. O peso de cada um é medido de acordo com a sua prioridade e severidade num cálculo simples. Bugs com severidade 1 prioridade 1 tem o ponto total (1.00) e considerando 5 niveis de prioridade e 5 niveis de severidade, o bug de menor severidade e menor prioridade vale o mínimo de 0.04. Acrescendo esse valor a cada relação severidade x prioridade, temos valores médios para cada combinação severidade x prioridade, como fica mais claro na figura abaixo:
Em Planned Tests Unfulfilled estão os testes incompletos, que ainda há algum trabalho a ser feito neles. A propósito, caso gere dúvidas, IP é In Progress.
Earned Value é um conceito de gerenciamento de projetos que diz que em um projeto, nós realizamos tarefas gastando recursos (faz sentido, não?). Então se o percentual de tarefas realizadas é mais ou menos igual ao percentual de recursos gastos, estamos no caminho certo. Se o percentual de tarefas realizadas é maior que o percentual de recursos gastos, estamos em um caminho melhor ainda :), a tendência é ficar abaixo do orçamento. Se o percentual de tarefas realizadas é menor que o percentual de recursos gastos, estamos a caminho de passar do orçamento.
Do ponto de vista de cronograma, o percentual das tarefas realizadas deveria ser aproximadamente igual a percentual de periodo decorrido do projeto (elapsed time). Então se o percentual de tarefas está acima do percentual do cronograma, ficamos felizes e satisfeitos e se está abaixo, ficamos tristes e preocupados :P.
Na execução de testes, consideramos o caso de teste ou o procedimento de teste como nossa tarefa básica. Os recursos (para testes manuais) são “pessoa-hora” para rodar os testes.
Fácil? Difícil? :)
Mais um então!
Defect Breakdown
Uma das muitas formas de olhar um defeito é analisando ele sob a perspectiva de severidade x prioridade ou uma combinação dos dois.
Na figura abaixo, temos um gráfico que, comparado a gráficos similares de projetos anteriores, pode nos dizer se estamos indo bem ou não. O ideal é que ele inicia com mais bugs de prioridade/severidade maior, isso demonstraria uma boa aplicação de risk-based testing.
Temos nesse gráfico, 5 pontos de severidade. A definição de como aplicar o nível de severidade e prioridade deve estar bem clara para todos os envolvidos no projeto. É bastante comum descobrir, atraves da avaliação desses gráficos, erros na classificação de defeitos.
Para um projeto que esteja no início, parece um bom comportamento gráfico, entretando para um projeto que esteja que esteja próximo ao término do ciclo de execução, é um gráfico bem preocupante.
Taxa de Falha de Confirmação
Um evento que poucos (ao menos eu vi poucos) se preocupam em medir é a taxa de falha de confirmação. O testador encontra um bug, o desenvolvedor resolve, o testador re-testa para confirmar a correção e ..... ? devolve para o desenvolvedor porque o problema não foi resolvido. Esse tipo de situação, que é comum, é uma perda de tempo. E pode ser medida através de um gráfico como esse:
Nesse exemplo, vários bugs foram reabertos, uma média de 1 a cada 6 defeitos reportados.
Padrões
De acordo com o famoso padrão IEEE 829, alguns itens que devem ser incluídos em um report de testes:
- Identificador do report
- Resumo (o que foi testado, quais são as conclusões, etc)
- Variações (do plano, dos casos, dos procedimentos)
- Avaliação compreensível
- Resumo dos resultados (métricas, etc)
- Avaliação de cada item de acordo com seus critérios de falha ou sucesso
- Resumo das atividades (uso de recursos, eficiência, etc)
- Aprovações
Esses resumos podem ser entregues durante a execução do teste, não necessáriamente só no final, e usado como ferramenta de acompanhamento.
Ainda sobre o assunto, eu sugiro a leitura dos seguintes artigos:
Execução e Relatório de Teste
Relatório Parcial de Execução de Teste
E um agradecimento especial ao autor desses dois artigos, o Gustavo Quezada, por nossa conversa sobre métricas. Ajudou bastante :)
Estudo CTAL: Processo de Teste
Falamos sobre Implementação e Execução em dois artigos:
Processo de Teste: Implementação e Execução
Processo de Teste: Implementação e Execução II
E o próximo ponto importante para o Analista de Testes é avaliar os critérios de saída e gerar relatórios para acompanhamento do gerente.
Nesse ponto do processo serão coletadas informações para o gerenciamento e medido o progresso, que consequentemente leva a detecção de desvios do plano.
Para medir a completude do teste é possível considerar informações como:
- Número de condições de teste, casos de teste, ou procedimentos de teste planejados, executados, passados, e falhados
- Número total de defeitos classificados por severidade, prioridade, status, ou outro fator relevante
- Requisições de mudanças (change requests) propostas, aceitas, testadas
- Planejado versus real: Custos, cronograma, esforço...
- Riscos de qualidade mitigados e os restantes
- Tempo de teste perdido com eventos que bloquearam testes (time de implementação não liberou a versão na data planejada, o ambiente estava fora, etc)
- Resultados dos testes de confirmação e regressão
Resumo do Test Suite
Permite fazer um tracking de algumas propriedades importantes da execução
Figura do livro Advanced Software Testing
Nesta tabela podemos avaliar:
- Progresso dos testes cases
- Taxas de testes passados e falhados
- Defeitos por test suite de acordo com prioridade/severidade (weighted failure)
- Valor agregado
No lado esquerdo, as duas primeiras colunas são o nome do test suite e o número de caso de testes dele.
Depois, sob Planning Tests Fulfilled, tem-se os testes que estão prontos, que não tem nenhum trabalho adicional a ser feito neles.
Weighted Failure é uma métrica para os bugs encontrados em casa suite. O peso de cada um é medido de acordo com a sua prioridade e severidade num cálculo simples. Bugs com severidade 1 prioridade 1 tem o ponto total (1.00) e considerando 5 niveis de prioridade e 5 niveis de severidade, o bug de menor severidade e menor prioridade vale o mínimo de 0.04. Acrescendo esse valor a cada relação severidade x prioridade, temos valores médios para cada combinação severidade x prioridade, como fica mais claro na figura abaixo:
Em Planned Tests Unfulfilled estão os testes incompletos, que ainda há algum trabalho a ser feito neles. A propósito, caso gere dúvidas, IP é In Progress.
Earned Value é um conceito de gerenciamento de projetos que diz que em um projeto, nós realizamos tarefas gastando recursos (faz sentido, não?). Então se o percentual de tarefas realizadas é mais ou menos igual ao percentual de recursos gastos, estamos no caminho certo. Se o percentual de tarefas realizadas é maior que o percentual de recursos gastos, estamos em um caminho melhor ainda :), a tendência é ficar abaixo do orçamento. Se o percentual de tarefas realizadas é menor que o percentual de recursos gastos, estamos a caminho de passar do orçamento.
Do ponto de vista de cronograma, o percentual das tarefas realizadas deveria ser aproximadamente igual a percentual de periodo decorrido do projeto (elapsed time). Então se o percentual de tarefas está acima do percentual do cronograma, ficamos felizes e satisfeitos e se está abaixo, ficamos tristes e preocupados :P.
Na execução de testes, consideramos o caso de teste ou o procedimento de teste como nossa tarefa básica. Os recursos (para testes manuais) são “pessoa-hora” para rodar os testes.
Fácil? Difícil? :)
Mais um então!
Defect Breakdown
Uma das muitas formas de olhar um defeito é analisando ele sob a perspectiva de severidade x prioridade ou uma combinação dos dois.
Na figura abaixo, temos um gráfico que, comparado a gráficos similares de projetos anteriores, pode nos dizer se estamos indo bem ou não. O ideal é que ele inicia com mais bugs de prioridade/severidade maior, isso demonstraria uma boa aplicação de risk-based testing.
Figura do livro Advanced Software Testing
Temos nesse gráfico, 5 pontos de severidade. A definição de como aplicar o nível de severidade e prioridade deve estar bem clara para todos os envolvidos no projeto. É bastante comum descobrir, atraves da avaliação desses gráficos, erros na classificação de defeitos.
Para um projeto que esteja no início, parece um bom comportamento gráfico, entretando para um projeto que esteja que esteja próximo ao término do ciclo de execução, é um gráfico bem preocupante.
Taxa de Falha de Confirmação
Um evento que poucos (ao menos eu vi poucos) se preocupam em medir é a taxa de falha de confirmação. O testador encontra um bug, o desenvolvedor resolve, o testador re-testa para confirmar a correção e ..... ? devolve para o desenvolvedor porque o problema não foi resolvido. Esse tipo de situação, que é comum, é uma perda de tempo. E pode ser medida através de um gráfico como esse:
Figura do livro Advanced Software Testing
Nesse exemplo, vários bugs foram reabertos, uma média de 1 a cada 6 defeitos reportados.
Padrões
De acordo com o famoso padrão IEEE 829, alguns itens que devem ser incluídos em um report de testes:
- Identificador do report
- Resumo (o que foi testado, quais são as conclusões, etc)
- Variações (do plano, dos casos, dos procedimentos)
- Avaliação compreensível
- Resumo dos resultados (métricas, etc)
- Avaliação de cada item de acordo com seus critérios de falha ou sucesso
- Resumo das atividades (uso de recursos, eficiência, etc)
- Aprovações
Esses resumos podem ser entregues durante a execução do teste, não necessáriamente só no final, e usado como ferramenta de acompanhamento.
Ainda sobre o assunto, eu sugiro a leitura dos seguintes artigos:
Execução e Relatório de Teste
Relatório Parcial de Execução de Teste
E um agradecimento especial ao autor desses dois artigos, o Gustavo Quezada, por nossa conversa sobre métricas. Ajudou bastante :)
sexta-feira, 21 de agosto de 2009
Salvando Vendas
É comum vermos problemas em sites de vendas que nos afugentam e fazem com que desistamos da compra. Hoje uma colega passou por uma situação dessas, mas houve um outro evento que me fez simpatizar bastante com o mesmo site. Vou fazer um comentário negativo e um positivo, um elogio ao profissionalismo com que uma situação foi tratada.
Uma colega estava olhando uns apartamentos no site da Imobiliária DUCATI e não conseguiu entrar no chat Corretor Online exibido no site. Esse foi o problema. Ela preencheu os dados indicados (todos) e o site dava a mensagem de que o e-mail não estava preenchido. (Vou ficar devendo a imagem pois esse problema só aconteceu no computador dela). <-- Esse é o negativo.
(Mas...)
Em seguida eu tentei entrar no chat para ver qual era o problema. De repente eu descobria algum furo na validação e a avisava como sobre como entrar no chat. Mas com os meus dados, funcionou! :) Entrei no chat por duas vezes e sai, pois estava apenas testando (entretanto poderia ser algum problema com a conexão).
Em menos de 2 minutos após a minha última entrada no chat, meu telefone tocou. Era o corretor que me "atendeu" no chat. Ele comentou que eu estava tentando entrar no chat sem sucesso e perguntou se poderia me ajudar. Nota 1000 pro atendimento. Expliquei a situação e passei o telefone para minha amiga que ficou bem feliz também e elogiou um monte o atendimento.
Parabéns ao atendimento e fica a dica para outros sites que utilizam funcionalidades similares.
Uma colega estava olhando uns apartamentos no site da Imobiliária DUCATI e não conseguiu entrar no chat Corretor Online exibido no site. Esse foi o problema. Ela preencheu os dados indicados (todos) e o site dava a mensagem de que o e-mail não estava preenchido. (Vou ficar devendo a imagem pois esse problema só aconteceu no computador dela). <-- Esse é o negativo.
(Mas...)
Em seguida eu tentei entrar no chat para ver qual era o problema. De repente eu descobria algum furo na validação e a avisava como sobre como entrar no chat. Mas com os meus dados, funcionou! :) Entrei no chat por duas vezes e sai, pois estava apenas testando (entretanto poderia ser algum problema com a conexão).
Em menos de 2 minutos após a minha última entrada no chat, meu telefone tocou. Era o corretor que me "atendeu" no chat. Ele comentou que eu estava tentando entrar no chat sem sucesso e perguntou se poderia me ajudar. Nota 1000 pro atendimento. Expliquei a situação e passei o telefone para minha amiga que ficou bem feliz também e elogiou um monte o atendimento.
Parabéns ao atendimento e fica a dica para outros sites que utilizam funcionalidades similares.
segunda-feira, 17 de agosto de 2009
Processo de Teste: Implementação e Execução
Nada de gripe suína por aqui. Estava sem postar porque o trabalho estava tomando mais tempo, neurônios e energia do que o normal.
Sem mais ladainhas, vamos ao que interessa:
No último post de processo de teste falei sobre Análise e Projeto de testes. Agora é a vez de Implementação e Execução.
A referência é a mesma: Advanced Software Testing Vol.1 – Rex Black
Implementação e Execução
Passadas as fases de Análise e Projeto, tudo o que falta para que possamos executar o teste encontra-se agora na fase de Implementação. E o que falta? :) Se quisermos estruturar nossos testes em roteiros ao invés de depender do conhecimento do testador do sistema, nessa fase vamos organizá-los em procedimentos de teste, ou seja, documentar todos os detalhes que restam para a execução do teste. O nível de detalhes depende sempre da estratégia de teste adotada.
Para a execução dos testes, também é necessário que estejam bem resolvidas as dependências de dados e ambiente e pode ser que nesse ponto seja necessário utilizar ferramentas para produzir dados em massa.
Precisamos também definir o cronograma de execução e responder perguntas como: Quem vai testar? Em que ordem? Quais são os ambientes necessários?
É importante procurar assegurar ao máximo que as áreas mais importantes/críticas do sistema serão testadas primeiro.
E claro, para a execução dos testes, é necessário que o critério de entrada dessa fase tenha sido atendido.
Test Procedure Readiness
A pergunta que guia essa seção é: Os roteiros de teste estão prontos para serem rodados?
Deve ser determinada uma seqüência clara (e obviamente lógica) de execução dos testes, que engloba a definição de quem vai rodar o quê, quando, com que dados, em que ambiente, em que ordem. Note que “em que ordem” pode não ser uma decisão obvia técnica. Pode ser uma boa idéia pedir auxílio de stakeholders pra entender qual a ordem ideal de execução dos testes.
Se utilizados testes automatizados, devemos organizar a participação deles nesse roteiro. O ideal seria um ambiente separado para os testes automatizados para evitar corrupção de dados que acabam por afetar os resultados não só dos testes automatizados, mas também dos testes manuais, se rodados no mesmo ambiente.
Teoricamente os test scripts e o test harness são construídos na fase de Implementação. Porque “na teoria”? Porque o test harness deveria estar pronto semanas ou mesmo antes de você começar a automatizar seus testes, mas vamos, a título de ISTQB, considerar que são construídos nessa fase.
Também nessa fase trabalhamos as dependências dos testes. Duas bem fortes são: ambiente e dados. Alguns podem agora soltar um “não diz!”. Quem nunca passou por esses problemas? Em uma empresa que trabalhei isso era um suplício e essas eram as maiores causas de desperdício de recursos.
Test Environment Readiness
Se eu rodar meus testes em um ambiente mal configurado, o que acontece? Eu vou ter que rodá-los novamente. Esses resultados não poderão ser ditos confiáveis. Vão gerar “falsos positivos”.
Falsos positivos são testes que passaram, mas deveriam ter falhado, assim como falsos negativos são testes que falharam, mas deveriam ter passado.
Os dois problemas podem acontecer por problemas no ambiente, o que vai aumentar o número de rejeições de defeitos, e gerar uma grande perda de tempo para testadores, desenvolvedores e gerentes.
Um ambiente bem configurado permite que rodemos nossos testes dentro das condições previstas. É um ambiente que opera normalmente quando não há falhas (não gera falsos positivos). Para testes de sistema e testes de integração de sistemas, um ambiente bem configurado deve replicar o ambiente de produção. Defeitos reais de performance, em especial, são difíceis de achar se não forem fornecidas essas condições.
Para ambientes complexos, é comum ter uma pessoa dedicada à manutenção desses ambientes.
É importante também checar todas as ferramentas para gerência de configuração, report de testes, gerenciamento de incidentes, o próprio gerenciamento de testes, etc.
Combinação de estratégias de teste
Geralmente é uma boa idéia usar uma combinação de estratégias de teste para balancear a abordagem, por exemplo, planejando uma porção de estratégias dinâmicas com estratégias risk-based.
É importante, entretanto, que essa porção reativa esteja bem controlada. Os testes não podem ser ad-hoc. E também esses testes têm pouca previsibilidade de duração e cobertura. Sobre esse último ponto, pode-se aplicar uma técnica de gerenciamento de testes chamada session-based, e para estruturar melhor esses testes, aplicam-se técnicas como attacks, error guessing, e exploratory testing.
E porque isso? Testes baseados em experiência tendem a ser responsáveis pela descoberta de 5 a 10 vezes mais bugs que as técnicas scripted. Mesmo sendo de difícil previsibilidade e necessitando de um testador expert, pode ser uma técnica complementar que vá agregar valor à sua estratégia.
Para cada decisão em relação a técnicas e estratégias adotadas, pergunte-se sempre que valor agregará a sua adoção e que contras ela trará? Balanceie e tire dessa reflexão a sua decisão.
(Continua aqui)
Sem mais ladainhas, vamos ao que interessa:
No último post de processo de teste falei sobre Análise e Projeto de testes. Agora é a vez de Implementação e Execução.
A referência é a mesma: Advanced Software Testing Vol.1 – Rex Black
Implementação e Execução
Passadas as fases de Análise e Projeto, tudo o que falta para que possamos executar o teste encontra-se agora na fase de Implementação. E o que falta? :) Se quisermos estruturar nossos testes em roteiros ao invés de depender do conhecimento do testador do sistema, nessa fase vamos organizá-los em procedimentos de teste, ou seja, documentar todos os detalhes que restam para a execução do teste. O nível de detalhes depende sempre da estratégia de teste adotada.
Para a execução dos testes, também é necessário que estejam bem resolvidas as dependências de dados e ambiente e pode ser que nesse ponto seja necessário utilizar ferramentas para produzir dados em massa.
Precisamos também definir o cronograma de execução e responder perguntas como: Quem vai testar? Em que ordem? Quais são os ambientes necessários?
É importante procurar assegurar ao máximo que as áreas mais importantes/críticas do sistema serão testadas primeiro.
E claro, para a execução dos testes, é necessário que o critério de entrada dessa fase tenha sido atendido.
Test Procedure Readiness
A pergunta que guia essa seção é: Os roteiros de teste estão prontos para serem rodados?
Deve ser determinada uma seqüência clara (e obviamente lógica) de execução dos testes, que engloba a definição de quem vai rodar o quê, quando, com que dados, em que ambiente, em que ordem. Note que “em que ordem” pode não ser uma decisão obvia técnica. Pode ser uma boa idéia pedir auxílio de stakeholders pra entender qual a ordem ideal de execução dos testes.
Se utilizados testes automatizados, devemos organizar a participação deles nesse roteiro. O ideal seria um ambiente separado para os testes automatizados para evitar corrupção de dados que acabam por afetar os resultados não só dos testes automatizados, mas também dos testes manuais, se rodados no mesmo ambiente.
Teoricamente os test scripts e o test harness são construídos na fase de Implementação. Porque “na teoria”? Porque o test harness deveria estar pronto semanas ou mesmo antes de você começar a automatizar seus testes, mas vamos, a título de ISTQB, considerar que são construídos nessa fase.
Também nessa fase trabalhamos as dependências dos testes. Duas bem fortes são: ambiente e dados. Alguns podem agora soltar um “não diz!”. Quem nunca passou por esses problemas? Em uma empresa que trabalhei isso era um suplício e essas eram as maiores causas de desperdício de recursos.
Test Environment Readiness
Se eu rodar meus testes em um ambiente mal configurado, o que acontece? Eu vou ter que rodá-los novamente. Esses resultados não poderão ser ditos confiáveis. Vão gerar “falsos positivos”.
Falsos positivos são testes que passaram, mas deveriam ter falhado, assim como falsos negativos são testes que falharam, mas deveriam ter passado.
Os dois problemas podem acontecer por problemas no ambiente, o que vai aumentar o número de rejeições de defeitos, e gerar uma grande perda de tempo para testadores, desenvolvedores e gerentes.
Um ambiente bem configurado permite que rodemos nossos testes dentro das condições previstas. É um ambiente que opera normalmente quando não há falhas (não gera falsos positivos). Para testes de sistema e testes de integração de sistemas, um ambiente bem configurado deve replicar o ambiente de produção. Defeitos reais de performance, em especial, são difíceis de achar se não forem fornecidas essas condições.
Para ambientes complexos, é comum ter uma pessoa dedicada à manutenção desses ambientes.
É importante também checar todas as ferramentas para gerência de configuração, report de testes, gerenciamento de incidentes, o próprio gerenciamento de testes, etc.
Combinação de estratégias de teste
Geralmente é uma boa idéia usar uma combinação de estratégias de teste para balancear a abordagem, por exemplo, planejando uma porção de estratégias dinâmicas com estratégias risk-based.
É importante, entretanto, que essa porção reativa esteja bem controlada. Os testes não podem ser ad-hoc. E também esses testes têm pouca previsibilidade de duração e cobertura. Sobre esse último ponto, pode-se aplicar uma técnica de gerenciamento de testes chamada session-based, e para estruturar melhor esses testes, aplicam-se técnicas como attacks, error guessing, e exploratory testing.
E porque isso? Testes baseados em experiência tendem a ser responsáveis pela descoberta de 5 a 10 vezes mais bugs que as técnicas scripted. Mesmo sendo de difícil previsibilidade e necessitando de um testador expert, pode ser uma técnica complementar que vá agregar valor à sua estratégia.
Para cada decisão em relação a técnicas e estratégias adotadas, pergunte-se sempre que valor agregará a sua adoção e que contras ela trará? Balanceie e tire dessa reflexão a sua decisão.
(Continua aqui)
quinta-feira, 9 de julho de 2009
Softwares que decidem nosso futuro
Quantos exames você já fez em máquinas que poderiam de alguma forma, se mal configuradas, prejudicar a sua saúde? Softwares que lidam com a saúde humana são considerados software de segurança crítica. Preciso comentar que esses softwares devem passar por uma bateria de verificações e validações bem mais rígida que quaisquer outros? Ou explicar os motivos? Estamos lidando com a vida do ser humano, e um erro pode causar danos sérios, quiçá irreversíveis.
Em junho a lei seca, também conhecida como de tolerância zero, fez seu primeiro aniversário. Uma lei que estipula condições de liberdade caso o condutor de um veículo apresente mais de 0,2 grama de álcool por litro de sangue.
Numa pesquisa rápida no Google cheguei ao resultado que na capital paulista em 2005, o álcool foi responsável por 45% das mortes no trânsito. Fora que o álcool é responsável por alterações nos sentidos, favorecendo o acontecimento de outros crimes e acidentes com seu consumo excessivo. Em um cenário caótico como esse, talvez a lei de tolerância zero seja mesmo a melhor opção para um combate radical a esses números absurdos.
A teoria, na minha opinião, é belíssima.
Mas vamos à prática. Como ocorre essa fiscalização? Através de testes de bafômetros. Como aparecem aqueles números? Através de um software! Um software que pode decidir a sua liberdade. Então, se esse software é responsável por algo tão sério, obviamente é um software que passa por uma bateria de verificações e validações bem mais rígida que quaisquer outros, certo?
“The program presented shows ample evidence of incomplete design, incomplete verification of design, and incomplete “white box” and “black box” testing. Therefore the software has to be considered unreliable and untested, and in several cases it does not meet stated requirements.”, é o que diz este artigo.
Vou reforçar em português: O programa apresenta ampla evidência de projeto incompleto, verificação de projeto incompleta, testes caixa branca e caixa preta incompletos. O software deve, portanto ser considerado não confiável e não testado, e em vários casos ele não atende os requisitos.
Este é o software que define ou não se um condutor será penalizado por essa lei. Veja a pena:.
Quem for flagrado com uma dosagem superior a 0,2 gramas de álcool por litro de sangue (equivalente à ingestão de uma lata de cerveja ou um cálice de vinho) pagará multa de 957 reais, receberá sete pontos na carteira de motorista e terá suspenso o direito de dirigir por um ano. Aqueles cuja dosagem de álcool no sangue superar 0,6 g/l (duas latas de cerveja) deverão ser presos em flagrante. As penas poderão variar de seis meses a três anos de cadeia, sendo afiançáveis por valores entre 300 e 1.200 reais. Os infratores também perderão o direito de dirigir por um ano.
Silvio Meira, professor Titular de Engenharia de Software do Centro de Informática da Universidade Federal de Pernambuco em Recife, cientista-chefe do Centro de Estudos e Sistemas Avançados do Recife (C.E.S.A.R) e engenheiro formado pelo Instituto Tecnológico de Aeronáutica (ITA), fala sobre ao assunto no seu blog.
Obviamente não estou questionando a necessidade de controle do álcool nas nossas vias, nem estou questionando a tolerância da lei. Estou questionando as ferramentas utilizadas para verificar o seu comprimento, ou melhor, a falta de comprometimento social das empresas e dos profissionais que liberam esse tipo de aplicação para serem usados pelo mundo.
A equipe desse software precisaria entender que seus clientes não eram seu gerente, o dono da empresa ou em primeira mão o governo que o compraria, mas pessoas que podem em algum momento ao invés de serem protegidas, serem penalizadas por esse produto.
Em junho a lei seca, também conhecida como de tolerância zero, fez seu primeiro aniversário. Uma lei que estipula condições de liberdade caso o condutor de um veículo apresente mais de 0,2 grama de álcool por litro de sangue.
Numa pesquisa rápida no Google cheguei ao resultado que na capital paulista em 2005, o álcool foi responsável por 45% das mortes no trânsito. Fora que o álcool é responsável por alterações nos sentidos, favorecendo o acontecimento de outros crimes e acidentes com seu consumo excessivo. Em um cenário caótico como esse, talvez a lei de tolerância zero seja mesmo a melhor opção para um combate radical a esses números absurdos.
A teoria, na minha opinião, é belíssima.
Mas vamos à prática. Como ocorre essa fiscalização? Através de testes de bafômetros. Como aparecem aqueles números? Através de um software! Um software que pode decidir a sua liberdade. Então, se esse software é responsável por algo tão sério, obviamente é um software que passa por uma bateria de verificações e validações bem mais rígida que quaisquer outros, certo?
“The program presented shows ample evidence of incomplete design, incomplete verification of design, and incomplete “white box” and “black box” testing. Therefore the software has to be considered unreliable and untested, and in several cases it does not meet stated requirements.”, é o que diz este artigo.
Vou reforçar em português: O programa apresenta ampla evidência de projeto incompleto, verificação de projeto incompleta, testes caixa branca e caixa preta incompletos. O software deve, portanto ser considerado não confiável e não testado, e em vários casos ele não atende os requisitos.
Este é o software que define ou não se um condutor será penalizado por essa lei. Veja a pena:.
Quem for flagrado com uma dosagem superior a 0,2 gramas de álcool por litro de sangue (equivalente à ingestão de uma lata de cerveja ou um cálice de vinho) pagará multa de 957 reais, receberá sete pontos na carteira de motorista e terá suspenso o direito de dirigir por um ano. Aqueles cuja dosagem de álcool no sangue superar 0,6 g/l (duas latas de cerveja) deverão ser presos em flagrante. As penas poderão variar de seis meses a três anos de cadeia, sendo afiançáveis por valores entre 300 e 1.200 reais. Os infratores também perderão o direito de dirigir por um ano.
Silvio Meira, professor Titular de Engenharia de Software do Centro de Informática da Universidade Federal de Pernambuco em Recife, cientista-chefe do Centro de Estudos e Sistemas Avançados do Recife (C.E.S.A.R) e engenheiro formado pelo Instituto Tecnológico de Aeronáutica (ITA), fala sobre ao assunto no seu blog.
Obviamente não estou questionando a necessidade de controle do álcool nas nossas vias, nem estou questionando a tolerância da lei. Estou questionando as ferramentas utilizadas para verificar o seu comprimento, ou melhor, a falta de comprometimento social das empresas e dos profissionais que liberam esse tipo de aplicação para serem usados pelo mundo.
A equipe desse software precisaria entender que seus clientes não eram seu gerente, o dono da empresa ou em primeira mão o governo que o compraria, mas pessoas que podem em algum momento ao invés de serem protegidas, serem penalizadas por esse produto.
Verificação – Inspeção
Sou uma pessoa privilegiada. Posso começar o post dizendo que ontem estava conversando com meu namorado sobre inspeções (e ele me entendia! :D). E foi isso que motivou o post.
Se você já leu Software Inspection de Gilb e Graham, talvez não tenha muita coisa interessante (ou melhor, nova) nesse post. Se não, eu o convido a refletir comigo sobre uma seção desse livro.
Na sua empresa, vocês inspecionam artefatos? Mesmo? Inspecionam ou 'revisam'? :)
Inspeção formal como estudamos vem da experiência de Michael E. Fagan na IBM, publicada como um artigo em 1974. Nesse livro, Tom Gilbs e Dorothy Graham explanam sobre esse trabalho, também com base em outros casos posteriores e complementares ao de Fagan, e com o suporte também de outras empresas que contribuíram para o livro.
No prefácio há um self-assessment para que você analise o seu processo de inspeção. Segue o mesmo abaixo com uma tradução livre :).
1. Você nega a entrada no processo de inspeção quando o produto a ser inspecionado não saiu de uma inspeção prévia? Se a resposta é não, você realiza primeiramente uma mini inspeção nesses artefatos ou pelo menos em uma amostra deles? Você proíbe a inspeção se os artefatos não estão com nível de qualidade adequado como resultado de uma mini inspeção ou similar?
Sempre – Geralmente – Algumas Vezes – Nunca
2. A reunião de abertura determina os objetivos da inspeção numericamente, e estabelece as estratégias correspondentes para alcançá-los?
Sempre – Geralmente – Algumas Vezes – Nunca
3. Os papéis são designados e definidos em checklists de papéis? Há uma biblioteca com esses checklists disponível para todos os líderes da inspeção?
Sempre – Geralmente – Algumas Vezes – Nunca
4. O líder da inspeção verifica que para cada desvio registrado houve alguma ação do editor?
Sempre – Geralmente – Algumas Vezes – Nunca
5. As taxas de revisão individual e em reunião são atualizadas e comparadas com as taxas ideais, e usadas para planejar a próxima inspeção?
Sempre – Geralmente – Algumas Vezes – Nunca
6. A razoabilidade das taxas é usada como critério de saída?
Sempre – Geralmente – Algumas Vezes – Nunca
7. O número de defeitos restantes após a edição é previsível? Se esse número é muito alto para o tipo de documento, o mesmo falha na inspeção? Em outras palavras, o número estimado de defeitos restantes é um critério de saída?
Sempre – Geralmente – Algumas Vezes – Nunca
8. A eficiência de detecção de defeitos é registrada? Esse dado é usado para estimar os defeitos restantes ao fim do ciclo de inspeção?
Sempre – Geralmente – Algumas Vezes – Nunca
9. A quantidade substancial de desvios encontrados no documento é registrada? (Ex. uma média de 10% a 25% dos desvios registrados resultaram em requisições de mudança (CR))
Sempre – Geralmente – Algumas Vezes – Nunca
10. Líderes de inspeção são formalmente certificados de acordo com um critério documentado? Há uma lista atualizada de líderes certificados? Líderes não certificados são proibidos de rodar uma inspeção de software (a não ser sobre devida supervisão)?
Sempre – Geralmente – Algumas Vezes – Nunca
11. Há melhorias nas regras, procedimentos e checklists regurlamente?
Sempre – Geralmente – Algumas Vezes – Nunca
12. Os resultados das melhorias nos padrões de inspeção são compartilhados com todos os líderes de inspeção e os inspetores?
Sempre – Geralmente – Algumas Vezes – Nunca
13. Há uma biblioteca de materiais de inspeção (formulários, checklists, regras), que seja bem organizados e conhecido, usado por todos os líderes de inspeção?
Sempre – Geralmente – Algumas Vezes – Nunca
14. Há um processo de reunião de brainstorming realizada para analisar as causas-raíz dos defeitos encontrados nos produtos de inspeção? Melhorias pequenas são implementadas imediatamente? Todas as sugestões de melhoria são formalmente registradas?
Sempre – Geralmente – Algumas Vezes – Nunca
15. Alguém ou algum grupo (geralmente o Time de Gerenciamento de Mudança de Processo) implementa melhorias no processo usando o banco de dados de inspeções?
Sempre – Geralmente – Algumas Vezes – Nunca
Agora, uma continha de padaria.
Sempre – 3 pontos
Geralmente – 2 pontos
Algumas Vezes – 1 ponto
Nunca – 0 ponto
E uma avaliação da sua pontuação:
45 (Perfeição)
Você não foi honesto com você mesmo!! :) Ninguém no mundo real alcança a perfeição! Volte e conte de novo a sua pontuação.
Entre 0 e 7
Não é exatamente considerado como nível. Definitivamente o que é feito não é uma inspeção. Fica a dica do livro ;)
Entre 8 e 15
Nível iniciante
Entre 16 e 23
Nível competente
Entre 24 e 31
Nível experiente
Entre 32 e 38
Nível estabelecido
Entre 39 e 45
Nível pioneiro
Claro que tem toda uma análise de perfil para essas pontuações. Mas a idéia do post era chamar atenção pro que se chama se inspeção por ai. Inspecionar não é revisar, passa o olho, etc. Consiste num processo estruturado que deve ser bem estudado antes de ser implementado. Fica a dica do livro que é A fonte para esse assunto.
Dúvidas sobre as perguntas e acusações de má tradução, podem colocar nos comentários para direito de defesa :D
Se você já leu Software Inspection de Gilb e Graham, talvez não tenha muita coisa interessante (ou melhor, nova) nesse post. Se não, eu o convido a refletir comigo sobre uma seção desse livro.
Na sua empresa, vocês inspecionam artefatos? Mesmo? Inspecionam ou 'revisam'? :)
Inspeção formal como estudamos vem da experiência de Michael E. Fagan na IBM, publicada como um artigo em 1974. Nesse livro, Tom Gilbs e Dorothy Graham explanam sobre esse trabalho, também com base em outros casos posteriores e complementares ao de Fagan, e com o suporte também de outras empresas que contribuíram para o livro.
No prefácio há um self-assessment para que você analise o seu processo de inspeção. Segue o mesmo abaixo com uma tradução livre :).
1. Você nega a entrada no processo de inspeção quando o produto a ser inspecionado não saiu de uma inspeção prévia? Se a resposta é não, você realiza primeiramente uma mini inspeção nesses artefatos ou pelo menos em uma amostra deles? Você proíbe a inspeção se os artefatos não estão com nível de qualidade adequado como resultado de uma mini inspeção ou similar?
Sempre – Geralmente – Algumas Vezes – Nunca
2. A reunião de abertura determina os objetivos da inspeção numericamente, e estabelece as estratégias correspondentes para alcançá-los?
Sempre – Geralmente – Algumas Vezes – Nunca
3. Os papéis são designados e definidos em checklists de papéis? Há uma biblioteca com esses checklists disponível para todos os líderes da inspeção?
Sempre – Geralmente – Algumas Vezes – Nunca
4. O líder da inspeção verifica que para cada desvio registrado houve alguma ação do editor?
Sempre – Geralmente – Algumas Vezes – Nunca
5. As taxas de revisão individual e em reunião são atualizadas e comparadas com as taxas ideais, e usadas para planejar a próxima inspeção?
Sempre – Geralmente – Algumas Vezes – Nunca
6. A razoabilidade das taxas é usada como critério de saída?
Sempre – Geralmente – Algumas Vezes – Nunca
7. O número de defeitos restantes após a edição é previsível? Se esse número é muito alto para o tipo de documento, o mesmo falha na inspeção? Em outras palavras, o número estimado de defeitos restantes é um critério de saída?
Sempre – Geralmente – Algumas Vezes – Nunca
8. A eficiência de detecção de defeitos é registrada? Esse dado é usado para estimar os defeitos restantes ao fim do ciclo de inspeção?
Sempre – Geralmente – Algumas Vezes – Nunca
9. A quantidade substancial de desvios encontrados no documento é registrada? (Ex. uma média de 10% a 25% dos desvios registrados resultaram em requisições de mudança (CR))
Sempre – Geralmente – Algumas Vezes – Nunca
10. Líderes de inspeção são formalmente certificados de acordo com um critério documentado? Há uma lista atualizada de líderes certificados? Líderes não certificados são proibidos de rodar uma inspeção de software (a não ser sobre devida supervisão)?
Sempre – Geralmente – Algumas Vezes – Nunca
11. Há melhorias nas regras, procedimentos e checklists regurlamente?
Sempre – Geralmente – Algumas Vezes – Nunca
12. Os resultados das melhorias nos padrões de inspeção são compartilhados com todos os líderes de inspeção e os inspetores?
Sempre – Geralmente – Algumas Vezes – Nunca
13. Há uma biblioteca de materiais de inspeção (formulários, checklists, regras), que seja bem organizados e conhecido, usado por todos os líderes de inspeção?
Sempre – Geralmente – Algumas Vezes – Nunca
14. Há um processo de reunião de brainstorming realizada para analisar as causas-raíz dos defeitos encontrados nos produtos de inspeção? Melhorias pequenas são implementadas imediatamente? Todas as sugestões de melhoria são formalmente registradas?
Sempre – Geralmente – Algumas Vezes – Nunca
15. Alguém ou algum grupo (geralmente o Time de Gerenciamento de Mudança de Processo) implementa melhorias no processo usando o banco de dados de inspeções?
Sempre – Geralmente – Algumas Vezes – Nunca
Agora, uma continha de padaria.
Sempre – 3 pontos
Geralmente – 2 pontos
Algumas Vezes – 1 ponto
Nunca – 0 ponto
E uma avaliação da sua pontuação:
45 (Perfeição)
Você não foi honesto com você mesmo!! :) Ninguém no mundo real alcança a perfeição! Volte e conte de novo a sua pontuação.
Entre 0 e 7
Não é exatamente considerado como nível. Definitivamente o que é feito não é uma inspeção. Fica a dica do livro ;)
Entre 8 e 15
Nível iniciante
Entre 16 e 23
Nível competente
Entre 24 e 31
Nível experiente
Entre 32 e 38
Nível estabelecido
Entre 39 e 45
Nível pioneiro
Claro que tem toda uma análise de perfil para essas pontuações. Mas a idéia do post era chamar atenção pro que se chama se inspeção por ai. Inspecionar não é revisar, passa o olho, etc. Consiste num processo estruturado que deve ser bem estudado antes de ser implementado. Fica a dica do livro que é A fonte para esse assunto.
Dúvidas sobre as perguntas e acusações de má tradução, podem colocar nos comentários para direito de defesa :D
terça-feira, 7 de julho de 2009
Vamos revisar o processo!
Recebi há pouco um e-mail muito legal da STP, com o artigo Is QA About People or Process?. Colei o artigo no final do post para quem tiver interesse.
Achei muito interessante o questionamento feito sobre controle de qualidade. Temos um bug em produção! Vamos rever o processo! :)
O processo de uma empresa deve ser algo vivo, ou seja, deve estar em constante aperfeiçoamento e sim, bugs e métricas relacionadas a esses bugs (bem como outras métricas e outros inputs) são utilizados como base para essas melhorias.
Falta ai uma consideração muito importante: pessoas!
São projetados procedimentos a serem seguidos, mas são pessoas que os vão seguir e onde temos pessoas, temos suscetibilidade a falhas. E nem todas as falhas devem necessariamente ser motivo de revisão no processo.
No artigo abaixo, Edward faz uma comparação interessante entre indústria de manufatura e de software e a aplicabilidade de modelos de qualidade nesses ambientes.
Is QA About People or Process?
By Edward J. Correia
Any time a defect gets through to production, companies have a tendency to reexamine their processes. “If we had tighter processes in place, this would not have happened,” is usually the thinking of management. If you deal with product quality, perhaps your reaction was something like, “Here we go again.”
But is quality control really about process? Can an air-tight process make up for sloppy, apathetic, or time-constrained people? Or, can a meticulous person assure quality despite controls that are less than perfect? Are people or processes most responsible for good quality?
Obviously, quality assurance involves a combination of the two. But according to V. Viswanathan, a quality analyst with international IT services company Virtusa, the answer might also depend on the industry. Having worked in manufacturing as well as software development, he believes that project-related endeavors like software development tend to be person-centric, whereas the manufacturing industry centers on process. “The amount of savings and benefits that occur in the software industry due to process improvement activities may not be really significant,” he says, whereas the Six Sigma process is a cornerstone of manufacturing.
“Six Sigma is mainly applicable to industries where operations or activities are identical,” he points out, hardly a characteristic of software development. “I don’t mean that Six Sigma is not applicable to software development. But by applying Six Sigma, drastic benefits may not be achieved as those that occur in the manufacturing industry."
Part of the Six Sigma strategy for business process improvement is to identify the root cause of a problem and then find and implement a solution. “In order for Six Sigma to be most effective, the operations have to be repeatable,” says Viswanathan. Hence, individual talent plays a far smaller role in manufacturing than in software development. Some of the differences include the following:
In manufacturing, each product is intended to be identical; in software development each product is customized (otherwise there would be nothing to develop).
Processes in manufacturing are the same for each operation; processes in software development vary in terms of content.
Most manufacturing workers perform at a similar level of effectiveness; software development workers’ abilities vary widely, as do their levels of skill and effectiveness.
As is true of many creative activities, the content involved with software projects can vary wildly, and operations related to application development will vary accordingly. “In software, the operations across projects might be similar, but are not identical. You may have the same set of phases…requirement analysis, design, coding, testing, and implementation… between projects. But the details of each are different,” he says.
Therefore, activities that you might have implemented to improve a process or solve a problem in one project may not be valid for another. “Also, the level of success might be different. Even if it is applicable, the consistency of success cannot be maintained across projects,” says Viswanathan. What’s more, errors are inevitable whenever human input is involved. And the places where errors turn up cannot be predicted. Such relative chaos is anathema to manufacturing, which relies on predictability and consistency for maximum output.
Each According to Ability
Perhaps the biggest difference between the software office and factory floor is the way in which each makes use of ability. A nimble factory worker might produce one percent more widgets and be less prone to injury than someone who is clumsy. But a skilled developer can become the basis of an entire industry (think Linus Torvalds).
The most effective software development team is one that combines skilled, competent and caring workers with solid, logical processes that work well and make sense to all involved. Because without buy-in from the team, your processes are not worth the paper they’re printed on.
Achei muito interessante o questionamento feito sobre controle de qualidade. Temos um bug em produção! Vamos rever o processo! :)
O processo de uma empresa deve ser algo vivo, ou seja, deve estar em constante aperfeiçoamento e sim, bugs e métricas relacionadas a esses bugs (bem como outras métricas e outros inputs) são utilizados como base para essas melhorias.
- Se minha empresa tem um processo maduro, então os softwares produzidos por ela serão sempre de excelente qualidade?
- Se minha empresa não tem um processo maduro, então os softwares produzidos por ela serão sempre de baixa qualidade?
Falta ai uma consideração muito importante: pessoas!
São projetados procedimentos a serem seguidos, mas são pessoas que os vão seguir e onde temos pessoas, temos suscetibilidade a falhas. E nem todas as falhas devem necessariamente ser motivo de revisão no processo.
No artigo abaixo, Edward faz uma comparação interessante entre indústria de manufatura e de software e a aplicabilidade de modelos de qualidade nesses ambientes.
Is QA About People or Process?
By Edward J. Correia
Any time a defect gets through to production, companies have a tendency to reexamine their processes. “If we had tighter processes in place, this would not have happened,” is usually the thinking of management. If you deal with product quality, perhaps your reaction was something like, “Here we go again.”
But is quality control really about process? Can an air-tight process make up for sloppy, apathetic, or time-constrained people? Or, can a meticulous person assure quality despite controls that are less than perfect? Are people or processes most responsible for good quality?
Obviously, quality assurance involves a combination of the two. But according to V. Viswanathan, a quality analyst with international IT services company Virtusa, the answer might also depend on the industry. Having worked in manufacturing as well as software development, he believes that project-related endeavors like software development tend to be person-centric, whereas the manufacturing industry centers on process. “The amount of savings and benefits that occur in the software industry due to process improvement activities may not be really significant,” he says, whereas the Six Sigma process is a cornerstone of manufacturing.
“Six Sigma is mainly applicable to industries where operations or activities are identical,” he points out, hardly a characteristic of software development. “I don’t mean that Six Sigma is not applicable to software development. But by applying Six Sigma, drastic benefits may not be achieved as those that occur in the manufacturing industry."
Part of the Six Sigma strategy for business process improvement is to identify the root cause of a problem and then find and implement a solution. “In order for Six Sigma to be most effective, the operations have to be repeatable,” says Viswanathan. Hence, individual talent plays a far smaller role in manufacturing than in software development. Some of the differences include the following:
In manufacturing, each product is intended to be identical; in software development each product is customized (otherwise there would be nothing to develop).
Processes in manufacturing are the same for each operation; processes in software development vary in terms of content.
Most manufacturing workers perform at a similar level of effectiveness; software development workers’ abilities vary widely, as do their levels of skill and effectiveness.
As is true of many creative activities, the content involved with software projects can vary wildly, and operations related to application development will vary accordingly. “In software, the operations across projects might be similar, but are not identical. You may have the same set of phases…requirement analysis, design, coding, testing, and implementation… between projects. But the details of each are different,” he says.
Therefore, activities that you might have implemented to improve a process or solve a problem in one project may not be valid for another. “Also, the level of success might be different. Even if it is applicable, the consistency of success cannot be maintained across projects,” says Viswanathan. What’s more, errors are inevitable whenever human input is involved. And the places where errors turn up cannot be predicted. Such relative chaos is anathema to manufacturing, which relies on predictability and consistency for maximum output.
Each According to Ability
Perhaps the biggest difference between the software office and factory floor is the way in which each makes use of ability. A nimble factory worker might produce one percent more widgets and be less prone to injury than someone who is clumsy. But a skilled developer can become the basis of an entire industry (think Linus Torvalds).
The most effective software development team is one that combines skilled, competent and caring workers with solid, logical processes that work well and make sense to all involved. Because without buy-in from the team, your processes are not worth the paper they’re printed on.
terça-feira, 16 de junho de 2009
Você não é simplesmente um profissional de TI
Chamativo o título? :)
Se você trabalha desenvolvendo software, você é um realizador de sonhos. Isso mesmo, bem filosófico, mas já parou para pensar o que REALMENTE você realiza? Esse projeto que você está exatamente agora serve pra que? Que serve pra que? Que serve pra que? (...) No fim, projetos são sonhos, ou partes de sonhos (sejam eles bons ou maus, não vou entrar nesse mérito).
O ponto que quero chegar é que deveríamos estar preocupados muito mais com o valor que estamos gerando a partir das nossas atividades do que somente (não que isso não seja essencial) realizá-las com perfeccionismo.
Um caso verídico :)
O cliente teve problemas com um fornecedor A e sondou seu outro fornecedor B ( \o/ )sobre uma possível re-análise do trabalho realizado por eles. Fui consultada nesse momento sobre a atividade e as minhas considerações.
A primeira resposta foi “Olha.. Se é simplesmente pra deixar o pessoal alocado, com atividades, é isso sim. Se for para deixar o cliente feliz, se for pra atender o que ele realmente quer, vai precisar de mais algumas outras coisas.” Ah! Isso é um problema muito sério, de tirar sono e dar muita dor de cabeça. É um verdadeiro trabalho de vidente (obviamente carregado de experiência) entregar pro cliente o que ele quer, especialmente porque num grande número de casos, nem ele sabe.
Ok, falando praticamente. O fornecedor fez um trabalho de especificação de negócio, geração de documento de padrões, casos de uso, e mais outros artefatos. Até ai parece perfeito. Exceto pela qualidade da documentação produzida que ficou deixando a desejar bastante, com requisitos que não aparecem nos casos de uso e outras atrocidades.
A pergunta era: podemos fazer uma reengenharia dos casos de uso e elaborar um documento de requisito de acordo com os nossos padrões?
Resposta de alguém focado em suas atividades, sem olho no cliente (por melhor técnico que seja): Sim.
Resposta dada: Que dá, dá. Mas pra que o cliente quer isso? Por mais que não esteja nos nossos padrões, eles têm uma especificação. A gente vai formatar dentro do template? Fazer trabalho de formatação e era isso? Porque não dá se basear só nos UCs, já que tem informação faltando neles. É melhor se basear no documento de especificação de negócio, ou seja, transcrevê-lo pro template. (Vulgo trabalho burro)
P.: Ok, e o que você sugere?
R.: Qual é o problema? Do que o cliente ta sentindo falta? Por que ele nos pediu pra fazer isso? Ele certamente não quer pagar nossas horas de consultores porque não gostou da cor do documento. Do que temos conversado em reunião e do que temos analisado com essa documentação, sabemos que o cliente não tem rastreabilidade alguma do que está sendo implementado e isso sim é um diferencial. Podemos catalogar decentemente os requisitos atribuindo IDs e outras propriedades, dentro do nosso template, mas mais que isso, podemos dar ao nosso cliente visibilidade, controle, conhecimento. Podemos dar a ele uma ferramenta de verificação se o que ele ta pedindo dos outros fornecedores está realmente sendo atendido.
Isso mesmo, uma matriz de rastreabilidade. Quem já fez isso na mão, ainda mais pra projeto grande deve estar tendo calafrios. É bem xarope mesmo. :) Feliz de quem tem ferramentas que geram isso automaticamente.
Pensem bem o valor que isso agrega! O diretor de TI do cliente XYZ tem que controlar vários fornecedores fazendo as atividades todas em separado. Um time gera especificação, outro codifica, outro gera analise de teste, outro testa e no fim o pobre do diretor não sabe se todo mundo ta usando todos os 647832483278947329 de documentos que deveriam para gerar tudo isso. O que sai no final? Só Deus sabe.
Agora imagina se ele pode ter uma ferramenta que diz pra ele: O requisito 123 está mapeado nos casos de uso A1, B2, C3 e D4. O caso de uso A1 é coberto pelos testes CTA1, CTA2, CTA3; e o B2 pelos CTB1, CTB2...
Há uma idéia bem mais concreta que o requisito realmente foi implementado. Consegue-se avaliar posteriormente o impacto de uma mudança, pode-se gerar vários indicadores como por exemplo o número de defeito por funcionalidade, avaliar a complexidade de uma funcionalidade, entre várias e várias outras coisas.
Virou um post sobre rastreabilidade :) Mas voltando ao título do post, fica um incentivo a não se limitar somente ao que lhe foi pedido para fazer. Questione, pense como fazer melhor, como gerar valor pra sua organização, pro seu cliente, pra você mesmo. Lembre-se que o que você produz vai em algum momento da cadeia estar realizando sonhos.
Assinar:
Postagens (Atom)