Arquivo mensal: março 2010

Terceirização de Testes – Qual a realidade do mercado?

A 17ª Mesa Redonda DFTestes foi sobre “Terceirização de Testes – Qual a realidade do mercado?”, contando com 7 respostas e 6 participantes, sendo eles: eu, Keite Moraes e Sousa, Eduardo Gomes, Shmuel Gershon, Aderson Bastos e Elias Nogueira.

A seguir, faço um resumo da discussão, lembrando quem quiser conferir na íntegra é só acessar esse link (necessita cadastro).

Terceirização

O Elias Nogueira fez um boa explicação sobre terceirização, e até colocou no Sem Bugs, dizendo:

Hoje as empresas estão num ritmo cada vez mas acelerado em conta da crescente exigência de seus clientes. Quando um novo produto é lançado, ele precisa ser entregue rapidamente em casos de softwares COTS para ter uma vantagem competitiva. Ou se o próprio sistema é de uso interno, o ritmo também precisa ser acelerado dado muitas vezes pelos cronogramas apertados.

Muitas empresas não tem a equipe necessária para fazer estas atividades. Em Teste de Software essa realidade se faz presente nas empresas, pois empresas, dado o seu negócio, não necessariamente necessitam ter profissionais contratados para isso.

Pela demanda de software, os profissionais podem crescer ou diminuir rapidamente, onde a empresa nestes dois cenários precisa controlar suas metas de qualidade e restrições de orçamento.

Para atender a essa demanda um novo (mas velho conhecido) tipo de contratação se faz necessário: a Terceirização

Como podemos ver pela explicação do Elias, a terceirização se apresenta como um bom caminho de conseguir realizar um bom serviço, sem ser especialista nele. Ou seja, uma empresa de desenvolvimento de software por exemplo, pode realizar ótimos testes e assim garantir a qualidade do software que está sendo produzido, com o auxílio de uma equipe terceira, que é especialista em Teste de Software.

Terceirização de Testes

O Elias Nogueira listou os seguintes tipos de terceirização de testes:

  • Terceirização Total COM Interface Técnica
    • Neste tipo, a empresa contratante possui profissionais de teste, mas contrata um empresa para ter um atendimento imediato a sua demanda. Como todos os requisitos serão validados por profissionais da contratante, o risco é muito pequeno pois eles já tem o conhecimento de negócio.
    • O lado negativo é que todo o “know-how” fica por parte da contratada, fazendo toda a organização do Projeto de Teste.
  • Terceirização SEM interface técnica
    • Nesse modelo a contratante tem alguns benefícios muito visíveis, como: A não preocupação com a formação da equipe e demandas de teste; Impacto referente a demanda é minimizado; Sem custos com uma equipe interna.
    • O grande problema desse tipo é o entendimento de negócio do cliente, onde o cliente pode não ter todas as regras de negócio bem definidas e a exposição dos processos de negócio para as contratadas
  • Terceirização Parcial – Execução de Testes
    • Nesse tipo todo o conhecimento de negócio fica com a contratante, que também elabora os Casos de Teste não existindo a perda de maturidade de teste quando a contratada for trocada. A contratada só entra com a execução dos testes da contratante. O problema desse tipo é que, com uma demanda interna, a equipe de testes da contratante pode não criar todos os possíveis cenários para testes e não suportar a demanda.
  • Terceirização Parcial – Arquitetura de Teste
    • Nesse tipo os Arquitetos de Teste da contratante passam a parte mais complexa dos testes para os Arquitetos de Teste da contratada.
    • A execução de testes fica na contratante, o que eleva os riscos de negócio e o custo em contratação. Se não for muito bem gerenciado, pode haver gastos desnecessários com profissionais alocados para cada atividade.
  • Terceirização Parcial – Automação de Teste
    • Nesse tipo os automatizadores ficam focados diretamente na automação do sistema, mas se o sistema não estiver maduro o suficiente para a automação, o trabalho não terá tanto ganho quanto o esperado. Scripts mal projetados para o cliente também vai dificultar na manutenção, elevado também os custos.

O Elias ainda lembrou que:

  • Para todos os tipos de Terceirização dos serviços de Teste se faz necessário criar SLA’s (Acordo de Nível de Serviço) entre a contratante e contratada, além de o acompanhamento constante das atividades para que o projeto não saia do controle e esteja no rumo certo, além é claro de cumprir os prazos estabelecidos.
  • Na contração dos serviços de testes como terceirização, podemos ter duas formas de contração: equipe interna ou equipe externa (birôs de teste)

Por fim o Elias compartilhou três experiências que teve com terceirização de testes, duas com testes manuais e outra com testes automatizados:

Empresa X

Ambiente organizacional muito bem definido e político. Serviço parte dentro da contratada e parte na contratante. Entramos na Empresa X sem o cliente (nível mais baixo do sistema) saber que estávamos ali para ajudar e testar suas aplicações. Resultado: não colaboração do cliente.

Isso dificultava muito o trabalho, pois tínhamos que sair atrás de tudo quando era coisa pra poder prestar um serviço razoável. O sucesso do projeto era diretamente proporcional a senioridade dos profissionais de Teste.

Empresa Y

Ambiente organizacional muito bem definido e político. Serviço parte dentro da contratada e parte na contratante. O cliente era um grande colaborador e tínhamos mais uma empresa prestando serviços de teste (uma grande empresa azul). No início eu fiquei me perguntando o porquê de duas empresas de teste, mas após alguns dias eu vi que a outra empresa possuía muito conhecimento de negócio, mas que não tinha um lado técnico muito forte. O trabalho em conjunto foi ótimo. O próprio cliente cobrava das duas contratadas a qualidade do serviço e “corria atrás” de qualquer empecilho político, deixando as duas empresas livres para executar suas atividades.

Empresa Z

Ambiente organizacional tradicional. Projeto de Automação. Serviço na contratante. Este cliente preza pela qualidade dos seus produtos e vê a qualidade como um principal para o seu sucesso. Inicialmente queria automatizar tudo o que era possível, mas depois enxergou o que realmente agregava valor.

Um ponto muito interessante é que em automação, tu precisas de pequenos ajustes na aplicação (não mandatário) para que seja possível contornar ou solucionar alguns problemas em automatizar um funcionalidade.

Essa empresa analisava o pedido de alteração e executava, sem empecilhos nenhum, claro que com uma análise bem focada.

O Aderson Bastos disse o seguinte:

A melhor “dica” é estabelecer uma parceria entre contratante e contratada, com metas e expectativas realistas. Geralmente o que se vê é a contratante exigir tudo o que sempre quis e nunca conseguiu fazer, e a contratada aceitar mesmo sabendo que não conseguirá cumprir (não com os prazo e custo contratados), pois se ela não aceitar outra empresa aceitará – óbvio que há exceções.
Uma pergunta importante que toda contratante deve se fazer é: por que terceirizar? Nesta simples pergunta estão várias outras implícitas, que se não forem identificadas e devidamente respondidas, impactarão o sucesso do processo. Trata-se de um modelo de negócio e de uma decisão estratégica, conforme a ótica do observador.
De qualquer forma, é um mercado extremamente promissor, principalmente em sua modalidade Offshore. Mas, nós brasileiros, de uma forma geral, ainda somos imaturos neste segmento, mas já temos casos de sucesso – sinal que estamos acordando!
Quem tiver interesse em aprofundar seus conhecimentos neste assunto e trocar experiências com uma grande referência, não poderão perder o tutorial do Martin Pol no BRATESTE 2010 – www.alats.org.br.
Concordo com o Aderson quando ele diz que precisamos saber o porquê da terceirização, muitas vezes podemos ter uma equipe interna para fazer os testes X e uma equipe terceirizada para fazer os testes Y. A empresa contratante precisa saber o que ela quer.

Desafios e Panorama da Terceirização de Testes

A Keite Moraes disse o seguinte sobre o assunto:

Considero que um dos grandes desafios para a terceirização de testes é administrar os fatores positivos e os negativos para ambos os lados.

Seria interessante existir um equilíbrio para a contratante e a contratada; de forma que ambas sejam protegidas dos riscos, que possam acontecer. Considero que a  terceirização parcial de serviços de testes, é uma forma equilibrada de agir.

Fatores positivos:
-> A criação de casos de testes fica centralizada na contratante, com isso qualquer risco decorrente da saída da empresa contratada, torna-se amenizada;
-> Os processos de negócio da empresa contratada fica menos expostos.

Fatores negativos:
-> Quando a contratada esta envolvida na execução dos testes, seu custo pode crescer;
-> Se as demandas de testes começar a oscilarem, na contratada, pode gerar testadores ociosos.

O Eduardo Gomes compartilhou a sua opinião, dizendo:

A impressão que tenho sobre a terceirização de testes no Brasil é de que existe ainda pouca maturidade sobre esse assunto.

Poucas empresas possuem experiências de sucesso comprovado nesse tipo de terceirização. A grande maioria dos fornecedores não são especializados em testes, mas fornecem também outros serviços, principalmente desenvolvimento de software. Talvez por essa razão, não invistam o suficiente na especialização de seus profissionais de teste e na construção e melhoria de processos mais robustos.

Por outro lado, os contratantes também não possuem maturidade para contratar com segurança. Os critérios utilizados para seleção de fornecedores não são suficientes para garantir uma contratação adequada e o processo de homologação normalmente é falho. Para que se tenha mais sucesso na terceirização, é preciso saber pedir e saber cobrar os resultados.

Apesar dessa imaturidade do mercado, acredito que a terceirização de testes é uma tendência irreversível, mas que ainda encontra-se no seu início. Portanto, trás muitas oportunidades para empresas e profissionais que estejam preparados para atender com qualidade as necessidades do mercado.

O Elias Nogueira comentou o seguinte:

É muito importante que todo o escopo de trabalho esteja fechado e também uma coisa muito importante: o “poder” da contratada em testes de poder navegar no ambiente organizacional e bloquear qualquer liberação falha.

O que vejo um pouco são empresas “vendendo pessoas” sem que exista um escopo de trabalho bem definido. Quando vamos prestar serviço para uma contratante, percebemos que existem diversas falhar no processo como um todo, mas nem sempre é possível melhorar algo devido a demanda e devido a própria burocracia do cliente.

O mercado Brasileiro ainda tem muito a amadurecer internamente para depois pensar em exportar este tipo de serviço. Existe muitas empresas sérias fazendo esse trabalho, mas também muitas empresas que querem entrar de qualquer forma em um cliente sem ter uma estrutura adequada para a terceirização dos seus serviços.

Eu também acho que um dos maiores desafios é estabelecer as responsabilidades de cada lado e elaborar um contrato que seja interessante para ambos os lados, principalmente quando ocorre uma terceirização total dos testes.

A falta de maturidade, como o Eduardo disse, é um grande desafio, embora no Brasil já existam empresas que prestam serviços de testes, algumas até há mais de 10 anos, e são bem maduras. Porém, a maturidade é necessária também para a empresa que está contratando.

A respeito das diferenças para os profissionais, elas existem sim, só que mais a respeito da dinâmica de trabalho, já que, geralmente, o profissional fica alocado no cliente.

Sem dúvidas a terceirização é uma tendência, lá fora mesmo há empresas que prestam serviços bem específicos em testes, como por exemplo: testes de performance e usabilidade.

Agora a terceirização completa dos testes eu já acho estranha, a não ser que quem for contratado atue dentro da empresa contratante (embora existam boas ferramentas para trabalhar remoto) e desde do começo do projeto. Terceirização de testes no modelo cascata, costuma gerar boas dores de cabeça e pode representar uma fria.

O Shmuel fez as seguintes perguntas sobre terceirização de testes: “Mas aí a responsabilidade sobre os testes é de quem? Que acontece se faltam casos de testes em uma área? E como o plano evolui durante os testes?”

Eu acredito que depende de como foi acordada a prestação de serviço. No CInTeQ houve uma palestra da Neli, que trabalha na IBM, que contou como foi um projeto, no qual 4 empresas participavam. Ela contou que os pessoal da IBM elabora os cenários de testes, e repassava eles para uma outra equipe que criava os casos de testes, executava e reportava as falhas encontradas. Depois o pessoal da IBM “filtrava” as falhas reportadas, verificando se não eram falsos-positivos, e assim passavam para o pessoal de desenvolvimento.

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

Fique por dentro das novidades, assine o feed do QualidadeBR.

O melhor da semana 21/03 a 27/03

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. 🙂

Abraços! E tenham uma ótima semana!

Fique por dentro das novidades, assine o feed do QualidadeBR.

Cobertura CInTeQ 2010 – Conclusão

Após relatar como foram as 13 palestras do CInTeQ 2010, um dos principais eventos de Teste e Qualidade de Software, patrocinado nesta edição por Microsoft, RSI, Iterasys, IBM, Governo do Brasil e Caixa Econômica Federal e com o apoio do BSTQB, chegou a hora de compartilhar as minhas conclusões sobre o evento.

Abaixo, listo o que achei de bom e ruim no evento:

  • Bom
    • Organização do evento – nem parecia que o CInTeQ estava na sua primeira edição. O pessoal da organização fez um trabalho impecável ao meu ver;
    • Local do evento – embora para eu chegar até o Hotel Caesar Business São Paulo Faria Lima, não seja a coisa mais fácil do mundo, o mesmo fica bem acessível para outras pessoas e principalmente, para aqueles que vieram de outros estados e desembarcaram em Congonhas (6 quilômetros até o hotel);
    • Infraestrutura – excelente a infraestrutura do hotel, todos os participantes ficavam sentados em mesas, o que facilitava a locomoção das pessoas (sabe quando alguém que sair e incomodar todo mundo da fileira de cadeiras rs) e oferecia mais conforto para aqueles que levaram notebooks/netbooks;
    • Palestrantes – sem dúvidas o ponto mais positivo de todos era o nível dos palestrantes, a maioria eram palestrantes de altíssimo nível, como por exemplo Rex Black, Dorothy Graham e Erik van Veenendaal e os nacionais também eram muito bons;
    • Palestras – na minha opinião, de nada adianta bons palestrantes se a temática da palestra for fraca, e isso não ocorreu no CInTeQ. Acredito que a grade de palestras foi o segundo fator que mais motivou a vinda das pessoas (o primeiro foram a vinda do Rex Black, Dorothy Graham e Erik van Veenendall), a maioria das palestras eram sobre temas bem pertinentes e atuais da nossa área;
    • Tutoriais – mesmo não participando de nenhum dos tutoriais, vi que todos são excelentes também, o Elias fez o sobre Automação de Testes, ministrado pela Dorothy e achou muito bom;
    • Continuação do CInTeQ – fiquei muito feliz ao saber que o CInTeQ passará a ser anual, ocorrendo sempre na última segunda e terça-feira do mês de março. Isso é excelente para a nossa área e possibilita as pessoas que não puderam participar nesta edição, a participar das próximas;
    • Apresentador – por último, mas não por isso menos importante, o apresentador do CInTeQ fez um excelente trabalho, o Felipe Mello disse muitas coisas importantes e pertinentes a nossa área, mesmo não sendo dela (rs), uma delas que acho que não falei ainda, é a relação entre Teste de Software com a humildade, pois testar é ser humilde, é aceitar que você pode ter errado, que o trabalho feito pode não está tão bom. Além disso, as intervenções feitas pelo Felipe Mello eram sempre com muito bom humor, o que garantiu momentos de boa descontração.
  • Ruim
    • Preço – bem esse é um ponto que depende muito da pessoa, pois o caro varia de pessoa para pessoa. Eu particularmente, achei o preço do evento bem caro, e por causa disso nem iria participar dele (só participei graças a um convite do José Correia). E conversando com outras pessoas da área, elas também reclamavam do preço da inscrição. Lógico que para fazer um evento do porte do CInTeQ, trazendo grandes palestrantes e num excelente local, o preço costuma sair salgado mesmo. Mas no fim, o preço do evento não acabou sendo um grande problema, uma vez que o auditório estava lotado (no primeiro dia não tanto, mas no segundo estava sim), mais de 250 pessoas participaram (dados não oficiais).
    • Divulgação – não sei se isso aconteceu com todos, mas eu recebia quase todo dia o folder de divulgação do evento, já estava quase criando um filtro (rs). Além do mais, um evento tão bom quanto o CInTeQ poderia ser divulgado em outros canais, como por exemplo em revistas como a Info (eu deixei essa sugestão para eles);
    • Almoço – calma, não é que o almoço era ruim, muito pelo contrário, foi muito bom, o ruim foi ter almoçado de pé, ou sentado em um sofá. O almoço ocorria no foyer do Hotel, onde não haviam mesas, apenas alguns sofás e aquelas mesas altas de café.

Sem dúvidas valeu muito a pena ter ido no CInTeQ 2010, além de ouvir palestras excelentes, pude conhecer novas pessoas e conversar com algumas que só conversava pelas listas e pelo MSN (rs).E além disso, o evento trouxe um mar de informações (eu ainda estou processando elas rs), que ampliaram a minha visão sobre a nossa área.

Parabéns ao BSTQB pela organização e a Microsoft, RSI, Iterasys, IBM, Governo do Brasil e Caixa Econômica Federal por terem patrocinado o evento, e que juntos tornaram possível a realização desse excelente evento!

E nos vemos em 2011! 😀

Fique por dentro das novidades, assine o feed do QualidadeBR.

Cobertura CInTeQ 2010 – Dia 2 (parte 2)

Chegamos as últimas palestras do segundo dia do CInTeQ 2010, um dos principais eventos de Teste e Qualidade de Software, patrocinado nesta edição por Microsoft, RSI, Iterasys, IBM, Governo do Brasil e Caixa Econômica Federal e com o apoio do BSTQB.

Quem quiser saber como foram as outras palestras, é só acessar os links abaixo:

Novamente, antes de começar a falar sobre as palestras, tenho que registrar as ações de um sr. que invadiu o evento, durante a intervenção.

O indivíduo trajava um jaleco branco e um nariz vermelho, e se auto denominava, Dr. Raviolli Bem-te-vi e apresentou uma palestra sobre o CInTeCC-Congresso Intergaláctico em Testes de Coisas Clowns. Durante a apresentação ele também falou sobre o PQP (Programa de Qualidade da Palhaçada) e agitou a plateia com novas neuróbicas.

Brincadeiras a parte, tenho que dizer que o Felipe Mello, que dentre as várias facetas, é o Dr. Raviolli Bem-te-vi, fez um excelente trabalho no CInTeQ, tanto nas introduções das palestras quanto nas introduções. Aliás, essas intervenções realmente funcionaram, ninguém depois do almoço estava com aquela famosa sonolência.

Naysawn Naderi – Dia-a-dia do testador usando a solução de testes Microsoft

A Naysawn Naderi foi focada na apresentação do Visual Studio Test Professional 2010 (VSTP), que será lançado mundialmente em 12 de abril, mas antes de falar sobre o ele fez alguns comentários sobre falhas que ocorram no F-22 e Toyota Prius.

Depois foi apresentado um vídeo bem engraçado da Microsoft, onde foi desenvolvida uma cadeira de tortura, que era acionada pelo cliente sempre que ele encontrava alguma falha no sistema, e desta maneira o desenvolvedor sofria algum “ataque” da cadeira (teve um que foi “ejetado” para fora do escritório rs). Sorte que era apenas um vídeo de brincadeira, pois se a ideia fosse colocada em prática muitos desenvolvedores estariam no hospital ou a sete palmos do chão.

Depois o Marcos Mion, que dizer, o Naysawn Naderi falou que há desafios que fazem com que o desenvolvimento de um produto com qualidade não seja fácil, citando:

  • Desenvolvedores e testadores trabalhando em locais diferentes;
  • A dificuldade em entender o status do projeto;
  • A complexidade da aplicação tem aumentado.

Começando a falar sobre o VSTP, o Naysawn disse que Microsoft fez muitas pesquisas, e notou que sempre há novas ferramentas, menos os testadores. Alguns dados levantadores pela Microsoft foram:

  • Houve poucas inovações no mercado de ferramentas para o Teste de Software;
  • O Excel ainda é o software mais usado pelos testadores;
  • 70% dos testes que ocorrem ainda são feitos de forma manual.

Percebendo que o mercado de ferramentas para Teste de Software, ainda precisava ser melhor explorado, a Microsoft criou o Visual Studio Test Professional 2010, que oferece um conjunto de ferramentas de teste que integra um completo fluxo de trabalho de planejamento-teste-análise. Além de armazenar bugs com diagnósticos e informações detalhadas do ambiente para os desenvolvedores (informações retiradas do folder da Microsoft, recebido no evento).

O Naysawn fez demonstrações ao vivo do VSTP, criando casos de testes para uma calculadora e reportando falhas.

Algumas características do VSTP:

  • Gerencia casos de testes;
  • Permite gravações de testes (record-play);
  • Gerenciamento de configuração dos ambientes;
  • Não tem suporte para aplicações Java e SAP;
  • Não suporta o IE6;
  • Integração com o Team Foundation Server, que é um “hub” de colaboração, melhorando assim a comunicação da equipe.

Impressões da palestra

O Naysawn é um bom palestrante, conseguiu passar bem as informações da palestra. O único problema foi ao responder alguns perguntas sobre a estratégia de negócio da Microsoft com o VSTP, já que ele é desenvolvedor e tinha informações sobre isso.

A respeito do VSTP em si, eu achei ele bem legal, ele é bem completo para testes funcionais, ou seja, atende a maioria das equipes de Teste de Software.

Antonio Coutinho – Gestão de Conhecimento de Teste

O Antonio Coutinho, Superintende da área de Processos e Gestão de Mudanças – Certificação de Implantações do Grupo Santander Brasil, palestrou sobre “Gestão de Conhecimento de Teste”. Iniciou falando sobre o Grupo Santander e depois apresentou o modelo de atuação em testes funcionais adotado por eles.

Esse modelo é full outsourcing, e busca eficiência e produtividade. A sua implantação já obteve resultados como por exemplo, a diminuição dos custos em infra-estrutura e aumento da qualidade.

Durante os projetos percebeu-se que o conhecimento estava dentro das cabeças das pessoas, ou seja, se determinada pessoa sair do projeto, o conhecimento também irá embora com ela. Então o grande desafio era torna esse conhecimento explícito.

E para enfrentar esse desafio a gestão de conhecimento se fez necessária.

A estratégia foi transforma bens intelectuais da organização, informações registradas e o talento dos seus membros em maior produtividade, novos valores e aumento de competitividade.

O Antonio também falou sobre algumas características do processo utilizado no Santander e mudanças ocorridas:

  • Eles possuem uma metodologia padrão de desenvolvimento de software no mundo todo: desenho funcional -> desenho técnico -> codificação -> testes unitários -> certificação -> implantação;
  • Mudança do modelo de cascata para o modelo V;
  • Começam fazendo um smoke test;
  • Nos ciclos de certificação eles executam 100% dos testes acordados;
  • Depois reportam os resultados finais e geram o book de evidências;
  • Há a reunião Go-No-Go, onde todos os envolvidos se reúnem para definir se a versão irá ou não para a produção;
  • Mesmo com os testes incidentes em produção ocorrem;
  • Os valores eram acertados de acordo com a quantidade de casos de testes executados;
  • Todo script passa por um crivo de aprovação;
  • Há três papéis principais: processo de gestão de mudanças, modelador dos casos de teste, executores dos casos de testes e ainda há uma quarto tipo, que são células de teste que são especialistas em sistemas específicos;
  • Com iniciativas de gestão de conhecimento a dependência por profissionais chaves diminuiu.

Depois saindo um pouco do processo, o Antonio falou sobre as ferramentas que auxiliam esse processo. Mostrando algumas telas e explicando algumas atividades realizadas com o apoio dessas ferramentas, principalmente em atividades de monitoração.

Por fim o Antonio sobre iniciativas de desenvolvimento e integração das pessoas, pois ele acredita que não basta ferramentas e processos é preciso investir em pessoas. E essas iniciativas se concentravam em duas frentes, para que o turnover seja menor e os objetivos das pessoas estejam de acordo com os da empresa:

  • Desenvolvimento de carreira;
  • Inspiração das pessoas.

Impressões da palestra

O Antonio passou informações sobre o Grupo Santander, que não estavam relacionadas com o tema da apresentação. Foi interessante ver a visão de uma empresa que consome serviços de outsourcing de testes, neste cenário sem dúvidas a gestão do conhecimento tem uma papel muito importante para ambos os lados, aliás, a gestão de conhecimento é muito importante para qualquer empresa de TI, afinal a informação é o maior capital que essas empresas podem ter.

Uma gestão de conhecimento efetiva só foi possível, com a alteração do processo e armazenamento do testware em um local de fácil acesso e seguro.

Dorothy Graham – Cognitive Illusions in Development and Testing

Antes de falar sobre a palestra, um parênteses sobre o tempo de Teste de Software que a Dorothy Graham tem.

Quando fui ver informações sobre ela na página do CInTeQ, me impressionei com o seguinte trecho “Dorothy Graham trabalha em teste de software há mais de 30 anos”, isso mesmo mais de 30 anos! Aí fui ver no LinkedIn, e comprovei que ela trabalha desde 1979 com Teste de Software, ou seja, a experiência dela com Teste de Software é igual ao “surgimento” da nossa área, que por muitos é considerado com o lançamento do livro “The Art of Software Testing” de Glenford Myers em 1979.

A Dorothy falou que a apresentação não seria técnica e começou apresentando algumas ilusões de óticas, para mostra como os nossos olhos podem nos enganar.

Falando sobre o subconsciente e o consciente a Dorothy lembrou que o subconsciente ajuda o consciente e é no consciente que você sente a dor. Além disso, você não percebe tudo sempre, portanto a percepção é muito importante e precisamos saber que o subconsciente é a interface que te faz sentir o mundo a sua volta.

A Dorothy explicou a diferença entre revisão e inspeção, onde a revisão costuma ser algo mais “insano”, pois estamos preocupados em revisar o todo, e no começo tudo bem, mas depois ficamos cansados e a qualidade da revisão cai, justamente porque a nossa percepção diminui.

Agora quando você faz uma inspeção você seleciona os principais documentos e os pontos mais importantes de cada documento. Desta maneira você, geralmente, acha menos defeitos, porém é capaz de encontrar mais problemas críticos, e quando você soluciona um problema crítico, é capaz de solucionar outros problemas que estavam associados a eles ou de lembrar deles e consertar depois.

E ao encontra os defeitos, você vai criando um checklist, e assim você alcança melhoria no processo, pois na próxima vez que for feita uma inspeção, poderemos usar o checklist criado.

Após falar sobre revisão X inspeção, a palestrante iniciou o tema complexidade, dizendo que a simplicidade é vista algumas vezes como alguma coisa ruim (se isso é tão simples, provavelmente não é bom). Porém, manter a simplicidade é algo complexo de se fazer. 🙂

A Dorothy ainda contou a boa história sobre a caneta de “1 bilhão” criada pela NASA e o lápis usado pelos russos, na verdade ela descobriu depois que o lápis dos russos não era qualquer lápis, ele era quase igual a um giz de cera, pois o grafite poderia danificar alguns equipamentos.

Outra boa história contada foi sobre a importância de ter um histórico de falhas (mas não só armazenar), onde a Dorothy disse que ela foi em uma empresa que tinha feito todas revisões pós-projeto e lições aprendidas, ela achou isso incrível, porém lendo as lições aprendidas, ela percebeu que elas se repetiram, ou seja, não eram lições aprendidas e sim lições listadas!

A Dorothy também falou um pouco sobre métricas, dizendo que 80% das métricas falham e muitas organizações não usam muitas métricas. Mas como disse Tom DeMarco “você não pode controlar o que não pode medir”, mas como questionou a Dorothy, se você não medir, ninguém vai te culpar?

E falando em culpa a Dorothy disse que culpar faz parte da natureza humana, adoramos pega rum consultor e jogar todas as culpas nele (rs).

Mas é errado cometer um erro?

Na verdade, se você não permite as pessoas errarem elas não serão tão boas, e irão esconder os erros.

É importante expor os erros, pois assim todos aprendem. Lembre-se que o oposto da culpa é uma cultura do aprendizado.

Mais uma história interessante contada pela Dorothy foi sobre um diretor que disse que se após 6 meses da contratação, o funcionário não cometer nenhum erro, ele demite ele.

Encerrando sobre o tema “culpa” a Dorothy disse que errar é humano, perdoar é divino, mas culpar é muito mais fácil que perdoar.

Ainda foram citadas algumas outras ilusões do nosso dia-a-dia, que mostra como interpretamos errado a realidade e às vezes fazemos questão de não encarar os problemas:

  • Riscos: pensar em risco não faz ele acontecer, e sim torna você mais preparado para a ocorrência dele;
  • Automação de testes: apenas comprar a “ferramenta certa”, que podemos demitir os testers;
  • Agile: não precisamos de modelagem, processo, teste, documentação, se é ágil não pode falhar de maneira alguma.

Precisamos analisar as causas e efeitos das ilusões cognitivas, pois somos capazes de nos decepcionar, se não enfrentamos os fatos.

Eu e a Dorothy Graham (Foto tirada pelo Mário Pravato Junior)

Por que nós mesmos nos enganamos?

A ansiedade é a causa para muitos fatores:

  • Medo, preocupação, insegurança, incerteza
  • Percepção é seletiva;
  • Pressão de grupo (ex.: nós conseguimos chegar no deadline, se alguém fala que não, essa pessoa não é vista com bons olhos).

A Dorothy falou sobre as preocupações que podemos ter no nosso trabalho:

  • Desenvolvedores
    • Fiz um bom trabalho?
    • Vou para outro projeto?
  • Gerentes
    • Alcançaremos o prazo.
  • Testadores
    • Encontramos muitos bugs?

Os testadores são responsáveis por levantar a ansiedade dos desenvolvedores e gerentes, uma vez que ao encontrar falhar, o prazo pode ser impacto e o trabalho do desenvolvedor é colocado em  “cheque”.

Há vários fatores que podem causar ansiedade nos testadores, como por exemplo:

  • Vamos encontrar todos os bugs?
  • Quanto tempo de testes é necessário? (a resposta: depende)
  • Será que testamos tudo? (não!)
  • Não temos temos para fazer um trabalho melhor;
  • Porque eu preciso lutar com os desenvolvedores?
  • Será que vou ter um bom reconhecimento?
  • Eu me sinto cupado pelos bugs que não foram encontrados.

Alguns pontos interessantes e até engraçados levantadores pela Dorothy:

  • Queremos ser amigos dos desenvolvedores;
  • Nunca é o bastante (a gente nunca termina os nossos testes);
  • Se o sistema é bom os desenvolvedores ganham os créditos;
  • Se há muitos bugs a culpa é dos testadores;
  • Se você não encontrar defeitos você não está fazendo um bom trabalho;
  • Se você acha muitos defeitos você irá atrasar o projeto;
  • Se você atrasar o projeto você não está fazendo um bom trabalho;
  • Então se você faz um bom trabalho, você não está fazendo um bom trabalho :s (tá vendo como a nossa vida é fácil! rsrs)

E o resultado disso tudo é que há pessoas que incentivam os testadores a não reportarem os bugs.

A Dorothy ainda disse que temos habilidade de nos decepcionar, e é importante reconhecer e entender as razões por trás disso. O que podemo fazer a respeito das outras pessoas? Podemos tentar conversar com ela, mas sempre com cautela.

Por fim a Dorothy resumiu em cinco palavras o que era queria passar com a palestra: Don’t believe everything you think! (não acredite em tudo que você pensa)

Impressões da palestra

Sensacional a palestra da Dorothy!

Ela conseguiu fazer a gente refletir sobre assuntos a partir de outras perpectivas, às vezes, somos tão técnicos que acabamos agindo mais como um robô, do que como um ser humano, e o pior, entendemos mais sobre máquinas, do que sobre pessoas.

As lições e visões trazidas pela Dorothy, sem dúvidas fez o público abrir mais a mente para problemas e situações que são comuns no nosso dia-a-dia, e que encaramos com insanidade (Albert Einstein: “Insanidade: fazer a mesma coisa repetidamente e esperar resultados diferentes”).

Após a palestra da Dorothy ainda teve o sorteio de um notebook Sony Vaio (que eu não ganhei…), por um dos patrocinadores do CInTeQ a Microsoft.

Bem é isso pessoal, sobre as palestras encerro aqui. Ainda vou fazer um post de conclusão do CInTeQ, mais um balanço do que ocorreu de bom e ruim no CInTeQ. Até lá! E nós vemos no CInTeQ 2011!!! (será nos dias 28 e 29 de março de 2011!)

Saiba mais

O Luiz Gustavo do TESTAVO[1] e o Mário Pravato do Zarro Boogs found[2] também escreveram sobre o CInTeQ, abaixo segue os links para o blog de cada um (recomendo!):

[1] http://testavo.blogspot.com/

[2] http://zarroboogsfound.blogspot.com/

Fique por dentro das novidades, assine o feed do QualidadeBR.


Fonte Imagem

Pintura 3D na rua

http://img167.imageshack.us/img167/2441/61536460po5.jpg

Cobertura CInTeQ 2010 – Dia 2 (parte 1)

Agora irei falar sobre como foram as palestras da parte da manhã, que ocorreram no segundo e último dia do CInTeQ 2010, um dos principais eventos de Teste e Qualidade de Software, patrocinado nesta edição por Microsoft, RSI, Iterasys, IBM, Governo do Brasil e Caixa Econômica Federal e com o apoio do BSTQB. Se você quiser saber como foram as palestras do primeiro dia, pode acessar esse post e esse.

Mauro Spínola – Qualidade e Produtividade em Sistemas e Software: Um Desafio Brasileiro

No segundo dia também cheguei um pouco atrasado, e perdi o início da palestra do Mauro, quando cheguei ele estava falando sobre produtividade.

O Mauro Spínola é Doutor e Livre-docente em engenharia pela Poli-USP e atua como consultor na área de TI e Qualidade de Software, ele também realiza treinamentos e assessoria através da Fundação Vanzolin.

A palestra teve como foco apresentar e discutir as exigências que as empresas enfrentam atualmente, assim como falar sobre a potencial contribuição que os modelos e normas podem ter nelas, quando as mesmas buscam a qualidade de sistemas e software.

Ao falar sobre produtividade o Mauro levantou a questão sobre o que é produtividade, que seria a relação entre o que a gente produz, com o quanto que a gente gasta para produzir.

Medir produtividade não é fácil, e medir produtividade em software é bem mais difícil, por isso precisamos saber qual tipo de produtividade nos interessa. Mas antes, precisamos ter a coragem de medir a produtividade.

Como obter maior produtividade?

O Mauro disse que as técnicas não são muito diferentes das usadas para obter qualidade, sendo elas:

  • Arquitetura definida;
  • Processo definido;
  • Padrões;
  • Ferramentas, automação;
  • Reuso/componentização.

Logo após, o palestrante falou um pouco sobre qualidade, primeiro a de produto e depois de processo, citando as características que podemos avaliar no software (Norma NBR 13596):

Do ponto de vista de produto podemos avaliar o seguinte (Norma NBR 13596 [que hoje é a NBR ISO/IEC 9126]):

  • Funcionalidade;
  • Confiabilidade;
  • Usabilidade;
  • Eficiência;
  • Manutenibilidade;
  • Portabilidade.

Agora para falar sobre qualidade de processo o Mauro, citou vários modelos e normas que ajudam a obter um bom padrão, sendo alguns deles:

  • ISO9000-2000/ISO90003;
  • ISO12207;
  • ISO15288;
  • ISO1550;
  • CMMI;
  • MPT.BR.

Sobre CMMI e MPS.BR o Mauro citou alguns números interessantes:

  • CMMI
    • Já foram feitas quase 5000 avaliações, boa parte das avaliações são feitas fora dos EUA, muitas empresas passaram para o nível gerenciado e definido;
    • O Brasil se encontra 117 avaliações no Brasil e 9 são de nível 5.
  • MPS.BR
    • 205 avaliações MPS.BR foram realizadas até agora.

Alguns pontos interessantes levantados pelo Mauro foram:

  • Uma empresa que não tem um padrão, dificilmente irá obter bons resultados mesmo com gênios;
  • Só consegue avaliar a qualidade tendo claro as características que definem um bom software;
  • Testes e codificação são atividades de menor cognição, quando comparadas com atividades de requisitos por exemplo.

O Mauro falou sobre pessoas, fazendo uma analogia onde disse, que uma alfaiataria é diferente de uma fábrica de ternos, e nas faculdades estamos formando bons alfaiates, que não estão preparados para atuar numa fábrica de ternos. Ele ainda enfatizou a necessidade de uma boa formação, para que o profissional possa lidar com as mudanças, afinal na área de tecnologia, mudanças ocorrem de forma constante, sempre precisamos nos manter atualizados.

Ainda foram citados alguns desafios que as empresas enfrentam:

  • Manterem-se atualizadas;
  • Investir em seus funcionários;
  • Desenvolver processos maduros.

Por fim, o Mauro falou que as fábricas de software tendem a industrialização do software, e a “modularização” das atividades é necessária, pois não há sentido em continuar no desenvolvimento vertical.

Impressões da palestra

O Mauro falou sobre um assunto que realmente é um desafio, e na minha opinião a qualidade será cada vez mais um diferencial entre as empresas. E a necessidade da produtividade é inerente ao panorama atual, no qual o que é desenvolvido hoje, passa a ser ultrapassado, cada vez mais cedo.

Não concordo com alguns pontos levantados pelo Mauro, principalmente sobre testes e codificação serem atividades menos cognitivas do que atividades de requisitos, isso me remete a visão de um gerente fora da realidade, que pensa que codificar é igual montar peças de Lego e que testar é só inserir dados num formulário. Além disso, não acredito na tendência da industrialização do software, pelo menos não da maneira que deu a entender, onde o desenvolvimento de software estaria cada vez mais próximo de uma montadora de automóveis. Ainda sou da opinião de que desenvolver software é um processo muito mais artesanal do que industrial.

Neli E.Duarte – Test Mirror: a test strategy using Scrum in an outsourcing project

A Neli, Engenheira de Software na IBM, iniciou a sua palestra falando sobre as características do projeto, no qual eles usavam Scrum, FDD (Feature Driven Development) e outsourcing.

Como no FDD o desenvolvimento é dirigido a features (funcionalidades), havia o feature leader, que era o responsável pelo desenvolvimento da feature do começo ao fim.

E neste contexto, surgiu a necessidade de criar um papel para fazer interface com o feature leader, e aí “nasceu” o test mirror, que é justamente um  espelho do feature leader, só que voltado para os testes.

A Neli detalhou como era o relacionamento entre o feature leader e o test mirror:

  • Na Sprint Planning a interação entre o test mirror e o feature leader ocorria o tempo todo;
  • O feature leader precisava manter o test mirrors ciente de todas modificações feitas na features. Com essas informações o test mirror modelava os testes;
  • Os desenvolvedores davam todo o feedback do que ocorreu, inclusive dando dicas de onde seria necessário fazer testes, e entre eles (feature leaders) também haviam troca de informações
  • Na Sprint Review quem atua é o test leader, baseado nos reports levantados pelo test mirror, ele criando um relatório de qualidade (era o output do processo de teste) e o feature leader apresentava as funcionalidades. Ou seja, o test mirror agia apenas como um suporte ao test leader, durante a Sprint Review.

Também foram citadas alguns características do processo:

  • O output da Sprint Planning era o plano geral dos testes;
  • A primeira tarefa do tet mirror era a modelagem dos testes;
  • Tudo era de acordo com a feature, então no mesmo sprint poderiam ocorrer várias fases em paralelo;
  • Haviam reuniões semanais, onde participam o time Scrum e os core members das outras equipes, onde todos davam um panorama de como estavam as atividades da sprint;
  • Haviam builds semanais;
  • Os test mirrors eram os responsáveis por executar o teste de sanidade que ocorria no mesmo dia da liberação do build;
  • Uma das funções do teste de sanidade era dá informações para o planejamento dos testes (ex.: se o teste de sms não funcionou, não tem como fazer o teste de envio
  • do sms concatenado).

Depois ela falou sobre a interação com o outsourcing (4 empresas trabalhando no mesmo produto 3 de desenvolvimento e 1 de teste[não que uma só fazia testes e a outra as outras só desenvolviam]):

  • Uma equipe entregava o cenário e a outra equipe criava os outros testes;
  • Haviam troca de informações entre as equipes;
  • O test mirror solicitava a execução dos testes, feitas pelo recurso externo, e esse enviava o report da execução dos testes;
  • O test mirror validava todos os bugs reportados pela equipe da outra empresa, fazendo assim um filtro dos bugs;
  • O test mirror era capaz de fazer a filtragem de bugs, pois tinha ciência da funcionalidade, já que estava sempre interagindo com o feature leader.

Por fim, a Neli mostrou os resultados obtidos utilizando essa dinâmica:

  • A comunicação melhorou muito (esse  é geralmente um dos primeiros sintomas, quando iniciamos o Scrum);
  • Melhorou a rastreabilidade dos incidentes;
  • Pacotes entregáveis mensalmente;
  • Aplicação foi entrega no tempo e sem bugs críticos;
  • Uma dinâmica muito intensa durante a sprint, um planejamento bem feito, sendo realizado duas vezes – o planejamento em si e o refinamento;
  • Testes mais esperto!

Impressões da palestra

Sabe aquela palestra que você balança com a cabeça todo o tempo, afirmando o que foi dito? Foi esse o comportamento que tive durante a palestra da Neli.

Até comentei no twitter, que a melhor palestra “coadjuvante” do CInTeQ  foi a da Neli. E essa impressão deve-se aos seguintes fatores:

  • Foi a palestra que mais se aproximou da minha realidade;
  • A Neli apresentou um conceito novo, o Test Mirror;
  • Mesmo com pouco tempo (meia hora de palestra apenas) a Neli conseguiu passar muito bem o conteúdo da apresentação.

Além disso, a palestra da Neli, na qual ela contou uma experiência de um projeto, mostrou que é possível aplicar práticas ágeis até mesmo na IBM (essa foi para os “ateus” em metodologias ágeis rs). 🙂

Adalberto Nobiato Crespo – Teste de Software no Contexto do Software Público Brasileiro

A palestra do Adalberto, Doutor em Engenharia Elétrica e membro da equipe técnica do CTI –  Centro de Tecnologia da Informação Renato Archer – Campinas, foi mais a título informativo sobre o Portal do Software Público Brasileiro, falando mais sobre o 5CQualiBr.

Ele começou falando sobre o que o a atuação do CTI e depois explicou sobre i que é o Software Público Brasileiro, que é um conjunto de soluções de tecnologia da informação e comunicação (TIC), disponibilizado para uso público, por meio de um portal Web.

Dentro desse ambiente existe um outro portal, chamado 5CQualiBR, no qual é tratado a qualidade do Software Público Brasileiro, que possui 6 vetores:

  • Ecossistema;
  • Qualidade de produto;
  • Desenvolvedores de software;
  • Prestadores de serviços;
  • Interoperabilidade;
  • Teste de Software.

O propósito é construir e disponibilizar no Portal do SPB uma Estrutura Tecnológica de Teste de Software, para os diversos usuários do SPB, além de tentar diminuir a distância que hoje existe entre a teoria e a prática.

Durante a sua apresentação o Adalberto enfatizou bastante o desenvolvimento junto com a comunidade do portal, pois quem faz ele é justamente as pessoas que tem experiência na área de Teste de Software.

Impressões da palestra

A palestra cumpriu a sua proposta de divulgação do SPB e do portal 5CQualiBr, eu já tinha visto ambos antes, e tinha achado interessante a ideia. Sem dúvidas o SPB e seus portais são excelentes fontes de conhecimentos, agora se ele realmente se tornará um portal da comunidade, só o tempo dirá.

Erik van Veenendaal – Test Maturity Model

Erik Van Veenendaal, uma das maiores referências da nossa área, apresentou sobre o TMMi (Test Maturity Model integration), que como a própria sigla já deixa claro, é um modelo de maturidade voltado para a área de Teste de Software.

O Erik começou falando que existimos para prevenir que defeitos vão para o mercado e estamos sempre enfrentando desafios e eles estão sempre crescendo, alguns números a respeito disso:

  • O número de software dobram a cada 2 anos na Philips, temos mais softwares para testar;
  • O número de requisitos para celulares dobram a cada 6 meses, segundo a Nokia;
  • Defeitos dificilmente reduzem.

E tendo ciência desses desafios fica claro a necessidade de fazer testes de forma mais eficaz e profissional. Ou seja, precisamos de testadores de classe A, e visando essa necessidade foi criado o TMMi.

Mas antes de falar sobre o TMMi, o Erik disse que há três direções que podemos falar sobre teste:

  • Pessoas;
  • Infra-estrutura;
  • O processo de teste.

Um dos comentários mais legais que feitos pelo Erik foi quando ele disse que para melhorar os testes é necessário buscar uma melhoria nesses três pilares, não adianta apenas focar em um dos pilares. Ou seja, ele mesmo assumi que o TMMi em si, não é a solução definitiva, o que demostra o profissionalismo e preocupação com a qualidade do Erik, e ainda complementa dizendo que melhoria não é apenas processo é também pessoas e infra-estrutura.

A respeito de pessoas, há pelo menos quatro área de habilidades necessárias para um testador:

  • Conhecimento em Teste de Software;
  • Conhecimento em TI (estamos nos aproximando dos desenvolvedores);
  • Conhecimento sobre domínio;
  • Habilidades não técnicas: comunicação, pensamento crítico e apresentação.

Já sobre infra-estrutura, o Erik citou algumas práticas fundamentais:

  • Requisitos bem documentados e gerenciados;
  • Existência de um planejamento do projetos;
  • Gerenciamento de configuração.

Alguns pontos interessantes levantados pelo Erik:

  • Você precisa de um orçamento para fazer a melhoria do processo;
  • O gerenciamento precisa de suporte de bons testes, lembre-se que qualidade é fundamental;
  • É preciso compreender o porquê que você está fazendo a melhoria;
  • Testar é dar informações sobre riscos.

TMMi

O Erik começou a sua explicação sobre TMMi Foundation, dizendo que ela é uma organização sem fins lucrativos. O TMMi é baseado no CMM e considera toda as práticas já existentes, suas origens são: CMMI, ISTQB, TMM, IEEE e TPI.

Assim como o CMMI, o TMMi é dividido em 5 níveis, lembrando que o primeiro é onde todas empresas estão no nível 1 (Inicial).

Os Cincos Níveis do TMMi (fonte)

O Erik acredita que o nível 2 é bom para todas organizações e necessário para lidar com os projetos atuais, sendo que para chegar nele, geralmente leva 2 anos, pois é o nível que provoca mais mudanças. Já para ir para o nível 3, costuma levar 1 ano.

Para se certificar é necessário pedir uma avaliação formal. No processo de implementação e avaliação temos dois papéis principais, o Lead Assessor e o Assessor, sendo que dentro dos conhecimentos para ser um Lead Assessor e um Assessor estão:

  • Lead Assessor
    • 5 anos de experiência e ISTQB avançada;
  • Assessor
    • 3 anos de experiência e ISTQB fundamental.

Na sequência o Erik falou mais especificamente do nível 2 e nível 3.

O TMMi nível 2 leva a redução de tempo e atingi mais a parte funcional. Estando no nível 2 você está de acordo com o que pedido pelo CMMI nas áreas de Verificação e Validação.

Já o nível 3 atingi mais a parte organizacional, e significa um envolvimento mais cedo dos testes no desenvolvimento do software.

As seguintes melhorias no testes, na perspectiva e engenharia, foram citadas:

  • Teste mais profissional;
  • Responsabilidades claras;
  • Planejamento de testes;
  • Teste baseado em riscos;
  • Testes parte do ciclo de vida do desenvolvimento;
  • Envolvimento cedo;
  • Uso de técnicas de modelagem de testes;
  • Controle sobre o processo de Teste de Software.

Alguns dos resultados que podem ser reportados pela área de teste são:

  • Detecção dos defeitos;
  • Tempo do lançamentos das versões;
  • Desvio entre o tempo do gasto X planejado;
  • Satisfação do funcionários.

Depois o palestrante falou sobre como podemos começar a implantação do TMMi, dizendo que:

  1. Defina uma política de testes e obtenha aprovação da gerência.
  2. Tenha ciência que melhoria é um projeto e calcule a porcentagem de recursos e esforço;
  3. Implante a maturidade do desenvolvimento na organização.

Algumas dicas dadas pelo Erik sobre como ter implantar o TMMi:

  • Faça pequenos ciclos;
  • Você não vai mudar só pela mudança;
  • Não responsabilidade as tarefas de melhoria para um consultor, pois ele irá embora, deixe isso para alguém da sua organização, a sua organização deve ser o impulso não a consultoria;
  • “Institualize” as melhorias;
  • Tudo tem haver com mudar a gerência;
  • Revise os objetivos (política), de forma contínua;
  • A sua melhoria tem que ser visando o negócio.

O Erik também apresentou o Manifesto da melhoria do testes:

  • Flexibilidade, sob detalhados processos;
  • Melhores práticas, sob templates;
  • Orientado ao deployment, sob orientado a processo;
  • Revisões, sob departamentos de QA;
  • Guiado pelo negócio, acima do guiado pelo modelo;
  • O melhor não é o melhor do mundo é o melhor no seu contexto;
  • Definir processo é fácil, difícil é instituir esse processo para as pessoas.

Por fim o Erik finalizou dizendo que o TMMi é ótimo quando feito da forma certa, sempre dirigido ao negócio.

Impressões da palestra

O Erik é uma palestrante muito bom, conseguiu passar bem as informações, descontrair a plateia com algumas brincadeiras e atingir a proposta da sua palestra. Eu já tinha uma noção do TMMi, mas com a palestra ficou muito mais claro a sua proposta, seus níveis e os resultados que podem ser obtidos com a sua aplicação. Uma pena que ainda não existem Lead Assessors e Assessors no Brasil, o que dificulta a popularização dele no Brasil (enquanto isso podemos acessar o material disponibilizado no site do TMMi).

Encerro aqui a primeira parte do segundo dia do CInTeQ, até a segunda parte, onde estarei terminando a cobertura das palestras do CInTeQ.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Cobertura CInTeQ 2010 – Dia 1 (parte 2)

Continuando a cobertura do CInTeQ (Congresso Internacional em Testes e Qualidade de Software), um dos principais eventos de Teste e Qualidade de Software, patrocinado nesta edição por Microsoft, RSI, Iterasys, IBM, Governo do Brasil e Caixa Econômica Federal e com o apoio do BSTQB. Irei fazer o relato de como foram  as palestras que ocorreram após o almoço do primeiro dia do evento (se você que saber como foram as primeiras palestras, pode acessar esse link).

Mas antes de falar das palestras que ocorreram após o almoço, eu preciso comentar sobre a in-ter-ven-ção. Isso mesmo intervenção, eu também estava curiosa para saber o que seria essa tal de intervenção, e foi uma surpresa muito boa.

Para explicar melhor, havia um apresentador/animador/show-man (ele fazia vários desses papéis rs [infelizmente não lembro do nome dele), que fazia a introdução de cada palestra e intervia  nas paradas para o coffee-break e almoço. Esse “rapaz” foi o responsável por causa a maior bagunça (no bom sentido é claro) para mandar embora aquela conhecida sonolência que ocorre após o almoço, utilizando uma tal de Neuróbica, onde foi passado dois exercícios de complexidade extrema: contar de 1 a 3 em dupla e cantar uma “musiquinha” (Toque Patoque).

Update 25/03

O Mário lembrou do nome do apresentador (nos comentários), é o Felipe Mello, ele é Ator, Palhaço, Comunicador social, Radialista e Fundador dos Doutores Cidadãos.

Foi passado ainda dois vídeos bem interessantes, além do apresentador ter feito várias citações de frases de reflexão, como por exemplo: “O modo de ser depende das decisões e não das condições.”

Um último comentário antes de irmos para as três últimas palestras do primeiro dia, você ficou interessado(a) na palestra do Rex Black? Quer saber mais sobre o assunto? Se a sua resposta é sim, então baixe agora mesmo a primeira edição da revista Agile Record, nela há um artigo do Rex Black com o seguinte título “How Agile Methodologies Challenge Testing”, o conteúdo do artigo é o mesmo da palestra que foi dada no CInTeQ.

Mieke Gevers  – How the Performance testing results can fool you! All You Need to Know to Get Control of the Evaluation Process

A belga Mieke Gevers, especialista em teste de performance e monitoramento, iniciou a sua palestra dando uma breve visão geral sobre teste de performance/desempenho. Explicou também um pouco sobre teste de escalabilidade, usando uma analogia com o deslocamento das pessoas para uma partida de futebol.

Logo após a palestrante começou a falar sobre a coleta de dados, que podem ser divididos em três tipos:

  • Dados do projeto (ex. quando será feito o teste);
  • Dados do testes (ex. massa de dados necessária);
  • Dados do resultado (ex. quais métricas serão usadas).

Na sequência a Mieke falou sobre como coletar estes dados:

  • Há ferramentas, que pode te dar ótimos resultados;
  • Exploração;
  • Recursos do sistema (ex.: gerenciamento de tarefa).

Depois a palestrante falou sobre o que podemos avaliar:

  • Arquitetura do sistema
  • Topologia de deployment;
  • Componentes de terceiros;
  • Capacidade do firewall;
  • Balanceamento de carga;
  • Conectividade;
  • Rede;
  • Gerenciamento da sessão;
  • Todas consultas;
  • Modelos de cache.

É preciso aplicar métricas, mas é mais preciso ainda, saber interpretá-las, comparar os resultados e buscar as origens dos gargalos.

Também precisamos lembrar, que assim como os testes funcionais, é importante participar o mais cedo possível, testar performance no final não é uma boa idéia (eu diria que pode ser uma péssima idéia, uma vez que dependendo da aplicação é mais importante a performance do que a funcionalidade, lembre-se disso).

Há também alguns “agentes” que podem influenciar o teste de performance:

  • As metodologias de teste e desenvolvimento;
  • A fase de testes;
  • O ambiente de teste;
  • E é claro as pessoas.

O que podemos procurar quando fazemos testes de performance?

  • Simular usuários;
  • Tempo de respostas;
  • Bytes por segundos;
  • Conexões.

Após apresentar vários gráficos comentando sobre a importância de saber interpretar os dados a Mieke finalizou a sua apresentação falando sobre o futuro, onde levantou uma pergunta interessante e fez algumas considerações finais:

  • Será que as técnicas que usamos hoje serão suficientes?
  • A melhor forma de prever o futuro é inventar;
  • Os testes são sempre algo envolvente, sempre precisamos trabalhar com dados, eles são a chave, sempre é necessário coletar dados.

Impressões da palestra

A apresentação da Mieke foi “estranha” para mim, acho que por eu ter lido a descrição da palestra no site do CInTeQ antes e ter um pouco de experiência com teste de performance, fizeram a minha expectativa ser muito alta para essa palestra.

Na minha opinião a Mieke não conseguiu ligar muito bem os assuntos abordados na palestra, o que fez com que no final eu tivesse a impressão de ter sido bombardeado por várias informações e gráficos que não conseguiram me mostrar uma conclusão, a não ser a que já se subentende, pelo próprio título da palestra: teste de performance não é apenas sobre coletar dados, e sim principalmente, sobre como interpretar esses dados (só pensar na analogia com a bolsa de valores).

Emílio Silva de Castro – A Importância da Especialização dos Papéis em uma Fábrica de Testes

O Emílio, gerente de projetos da RSI, iniciou a sua palestra falando dos objetivos da palestra, na qual seriam comentados os desafios para estruturar uma equipe de teste e como estruturar tal equipe.

Quando Testar?

  • Testar desde do início;
  • Definir o escopo de atuação dentro do desenvolvimento do software;
  • Definir os objetivos do nosso testes.

Todos esses são fatores que podem influenciar a composição da nossa equipe

O Emílio fez uma importante consideração sobre qualidade, dizendo que ela depende da perspectiva, ou seja, quem desenvolve tem uma perspectiva X, já quem usa o software tem uma Y e o testador precisar ter uma mistura entre X e Y.

Outro fator que pode influenciar a composição da nossa equipe são os níveis de testes (unitário, integração, sistema e aceitação), que a sua fábrica se propõe a atuar. Afinal para os testes de cada nível são necessários conhecimentos diferentes, por exemplo: para testes de unidade um conhecimento técnico é fundamental, já para os testes de aceitação o mais importante é ter um bom conhecimento do negócio.

Precisamos também pensar nas técnicas de teste que irão compor a nossa estratégia:

  • Testes estáticos: análise estática e revisão;
  • Testes dinâmicos: caixa-branca, caixa-preta (funcional e não-funcional).

Depois o palestrante falou sobre os papéis que existem na RSI e quais conhecimentos são necessários:

  • Gerente de Testes: precisa de conhecimentos sobre gerenciamento de projetos, engenharia de software e conhecer de forma avançada Teste de Software;
  • Executor de Testes: precisa ter fundamentos de teste, negócio e ortografia e gramática. Esse profissional irá executar os testes elaborados pelo Engenheiro de Testes;
  • Automatizador: lógica de programação, melhores práticas de codificação, ou seja, precisa ter um perfil bem programador;
  • Engenheiro de Testes: fundamentos de teste (uma CTFL), conheça o processo de desenvolvimento, negócio (financeiro, telecomunicações, agronegócio e jurídico);
  • Revisor: tem um perfil de análise estática, precisa conhecer requisitos, análise e design (UML), codificação, ortografia e gramática;
  • Técnico: necessita conhecer o ambiente que será utilizado durante os testes: plataforma, SOs, redes, segurança, banco de dados, servidor da aplicação.

Outros pontos interessantes falados pelo Emílio foram:

  • Não adianta ter um vasto conhecimento e demorar ou fazer algo com baixa qualidade;
  • O aspecto motivacional é muito importante;
  • Quem dá o “ok” final é quem detém o poder do negócio, os profissionais de Teste de Software podem ajuda a tomada de decisão, mas nunca tomar a decisão;
  • Quando falamos em métricas precisamos saber a eficácia no encontro de defeitos e a existência de defeitos durante o ciclo de desenvolvimento (quantos bugs foram encontrados em cada fase).

Por fim o palestrante encerrou a sua apresentação falando sobre os fatores críticos de sucesso, que são:

  1. Pessoas: o maior ativo que uma empresa pode ter;
  2. Ver o teste como oportunidade de melhoria.

Impressões da palestra

A apresentação do Emílio foi a mais “leve” de todas, e por ser de nível básico, não trouxe nenhuma surpresa ou novidade ao público. Mas não por isso, a palestra foi ruim, muito pelo contrário, eu achei ela muito boa, pois o Emílio conseguiu falar sobre vários temas de Teste de Software, para apoiar o seu tema principal, que era mostrar a importância e os desafios da especialização dos papéis no contexto de fábrica de testes. Ou seja, foi uma apresentação muito bem estruturada e o conteúdo foi passado de uma forma muito clara e didática.

Patricia McQuaid – Software Disasters: What Have We Learned?

A Patricia, presidente e co-fundadora do American Software Testing Qualifications Board (ASTQB) e professora de Sistemas de Informação em uma universidade da Califórnia, falou durante a sua apresentação sobre diversos desastres que ocorreram devido a falhas no software.

Muitos das falhas ocorridas geram prejuízos na ordem de milhões de dólares e em alguns casos houve até mortes. E algumas dessas falhas eram até bem grotescas, como no caso do Mars Climate Orbiter, onde o uso de medidas inglesas, quando o software foi programado para realizar apenas cálculos no sistema métrico, provocou a destruição da nave ao entrar na atmosfera  de Marte.

Outro case bem interessante foi o do Aeroporto Internacional de Denver, onde uma falha geral no sistema automático de transporte de bagagem, causou um prejuízo de “apenas” 360 milhões de dólares e ainda outros 86 milhões foram gastos para manutenção do sistema, isso sem falar nos 6 meses de atraso na abertura do aeroporto. E o gerente do projeto ainda pensava que o sistema de bagagem não seria tão complexo (#epicfail).

A Patricia ainda fez uma análise do que levou a esses problemas, citando:

  • Pobres práticas de codificação;
  • Testes grosseiramente inadequados;
  • Análise dos dados funcionais pré-aprovadas;
  • Um único programador criou o software;
  • Falta de documentação;
  • Apresentação de erros que não eram de fácil compreensão;
  • Assumir que o  reuso do software é algo seguro;
  • Reporte de incidentes eram mal feitos.

Ou seja, muitos dos problemas ocorridos foram uma junção de vários fatores, que envolviam tanto o processo quanto as pessoas.

Patricia, eu e a Mieke (Foto tirada pelo Mário Pravato Junior)

Impressões da palestra

Eu achei que a Patricia falou sobre muitos desastres, o que fez com aquela tivesse que correr um pouco na explicação de alguns. Mas mesmo assim, ela conseguiu atingir o objetivo da palestra, que era mostra que falhas podem custar muito caro, e pior do que milhões de dólares em prejuízo e a perda de vidas por causa de falhas, como ocorreu por exemplo no THERAC 25.  Além disso a palestrante deixou uma mensagem muito importante, a de que precisamos aprender com o nosso passado, para evitar que as mesmas falhas ocorram novamente, e uma dessas lições aprendidas é de que testes são fundamentais! 🙂

No término das palestras do primeiro dia, ainda houve o sorteio de um curso preparatório da CTFL, por um dos patrocinadores do CInTeQ, a Iterasys.

Aqui encerro a cobertura do primeiro dia, até a primeira parte do segundo dia! 😉

Fique por dentro das novidades, assine o feed do QualidadeBR.

Impressões da palestra

a

Cobertura CInTeQ 2010 – Dia 1 (parte 1)

Nesta segunda-feira teve início o CInTeQ (Congresso Internacional em Testes e Qualidade de Software), um dos principais eventos de Teste e Qualidade de Software, patrocinado nesta edição por Microsoft, RSI, Iterasys, IBM, Governo do Brasil e Caixa Econômica Federal e com o apoio do BSTQB.

A seguir, relato como foram  as primeiras palestras do primeiro dia do evento.

Abertura do evento – Osmar Higashi – Atuação do BSTQB e Panorama Atual dos Testes no Brasil

O paguá que vos escreve chegou atrasado… chegando só no fim da palestra de abertura do evento, que foi ministrada pelo diretor executivo da RSI Informática e BSTQB (Brazilian Software Testing Qualifications Board), Osmar Higashi.

O palestrante falou sobre a atuação do BSTQB no Brasil, as certificações avançadas, números de certificados e uma notícia bem importante: a aplicação da prova avançada para a área de gerência de testes (CTAL-TM: Advanced Level Test Manager) aqui no Brasil, que ocorrerá ainda nesse ano (atualização[24/03]: o César Chaves disse nos comentários que já houve a primeira prova CTAL-TM: Advanced Level Test Manager no Brasil, ela ocorreu em fevereiro/2010).

Além disso, o palestrante disse que os Syllabus das outras certificações avançadas já estão sendo traduzidos (alguns já estão até completamente traduzidos) e que o BSTQB está trabalhando para aplicar os outros exames avançados no Brasil.

Resumindo, parece que o BSTQB está querendo atuar mais fortemente no Brasil, prova disso é a própria realização do CInTeQ, o que é muito bom para o nosso mercado e para os profissionais.

Eduardo Habib – Teste de Segurança em Aplicações Web

O Eduardo é Gerente de Testes no SYNERGIA e mestre em Ciência da Computação pela UFMG. Sua apresentação foi sobre uma tema ainda não muito comentado na comunidade de Teste de Software Brasileira, testes de segurança.

A palestra do Eduardo teve como foco apresentar as falhas de segurança mais comuns em aplicações Web, alguns exemplos de como testá-las e ferramentas open source que auxiliam nesse tipo de teste.

O palestrante começou falando que antigamente a segurança não era uma preocupação no desenvolvimento de aplicações Web, pois o conteúdo era todo estático e não haviam informações confidenciais nos sites.

Porém, hoje em dia os sites possuem informações confidenciais de seus usuários, desde login e senha até o saldo da conta corrente. Portanto, a segurança passou a ser uma característica fundamental em vários sites, e são precisos testes para averiguar se a aplicação é realmente segura.

Algumas informações importantes passadas pelo Eduardo durante a palestra:

  • Muitas pessoas não se importam com a segurança de determinada aplicação, porém esquecem que essa aplicação pode ser a porta de entrada para as aplicações que ele se preocupa;
  • O uso de SSL – Secure Sockets Layer não impossibilita ataques, e  os ataques que mais ocorrem não são evitados com SSL. Porém, isso não que dizer que você não deva utilizar SSL, pois caso você faça isso, você abrirá outras “brechas” para os crackers;
  • Há um aumento considerável no número de incidentes relacionados a segurança (figura abaixo), e esses números não estão dando sinais que vão diminuir. Por isso cada vez mais se faz necessário realizar testes de segurança;
  • Houve um aumento de incidentes de 61% de 2008 para 2009;
  • De 1999 até 2009 o aumento de incidentes foi de 11530%;
  • 75% dos sites de bancos possuem falha grave, segundo a Universidade de Michigan (pesquisa não contemplava bancos brasileiros);
  • 64% de 1364 sites corporativos possuem falhas graves de segurança, segundo o WhiteHat Security.

Total de Incidentes Reportados ao CERT.br por Ano (Fonte CERT.br)

A origens principais desses incidentes são devido aos seguintes problemas:

  • O usuário pode enviar QUALQUER dado;
  • É necessário assumir que toda entrada pode ser maliciosa;
  • Requisições podem ser feitas em qualquer sequência;
  • Usuários não irão usar apenas um navegador para acessar a aplicação;
  • Muitas aplicações não fazem verificação a cada requisição, ou seja, após o usuário estar logado, as requisições não são mais autenticadas.

O Eduardo ainda falou sobre as falhas que mais ocorrem, sendo elas:

  • Falhas de injeção (ex. SQL injection);
  • Cross Site Scripting (XSS);
  • Falhas de autenticação e de gerenciamento de sessão;
  • Referência insegura a objetos;
  • Problemas de configuração;
  • Falha ao restringir o acesso a alguma URL;
  • Redirecionamento inválido;
  • Problemas no armazenamento de informações confidenciais;
  • Proteção na camada de transporte insuficiente;
    • Sem criptografia;
    • Certificados inválidos.

Mas então como podemos testar a segurança de uma aplicação Web?

Segundo o Eduardo a primeira coisa a ser feita quando for testar um software é pensar como que um cracker irá obter a informação, e para isso é preciso fazer um bom mapeamento, cuja melhor forma é a automática. Existem ferramentas open source que fazem esse mapeamento, e essas são chamadas de web spider.

Um ponto bem interessante da palestra foi a apresentação da ferramenta WebGoat, que já possui várias falhas de segurança e foi criada, justamente para ensinar as pessoas a como encontrar essas falhas e como funcionam as técnicas utilizadas pelos crackers, ou seja, é uma ferramenta obrigatória para quem quer começar a fazer testes de segurança.

O palestrante também mostrou uma lista de addons do Firefox e ferramentas que podem auxiliar durante os testes de segurança:

Por fim, o Eduardo concluiu que:

  • Todo sistema/aplicação é passível de invasão;
  • Os usuários são potenciais invasores;
  • É necessário otimização e cautela durante a programação,
  • A análise de riscos pode ajudar no início da elaboração dos testes de segurança, fazendo você focar nas áreas chaves;
  • Novas tecnologia irão criar novas “brechas”;
  • Não há ferramentas open source tão boas, quanto as pagas.

Impressões da palestra

Eu achei a palestra do Eduardo bem interessante, talvez por não conhecer muito bem a área de Segurança de Informação e por nunca ainda ter feito testes de segurança.

O Eduardo atingiu com sucesso a proposta da palestra. Sem dúvidas quem participou da palestra saiu dela com uma visão muito melhor e já sabe por onde começar a fazes os testes de segurança, que cada vez são mais necessários e que cujas falhas costumam gerar um prejuízo muito grande para as organizações.

Rex Black – Dealing with the Testing Challenges of Agile Methodologies

A expectativa para essa palestra era muito alta, afinal o palestrante era nada mais nada menos, do que a lenda, o mito, o “monstro”, o “dinossauro”, o “megaboga”, o gigante … Rex Black, presidente da RBCS e autor de excelentes artigos e livros, que fazem juz aos adjetivos colocados, e o tema da sua apresentação “Lidando com os Desafios do Teste para as Metodologias Ágeis”, o mais interessante da agenda dos dois dias de evento, pelo menos para mim, que estou lidando com esses desafios ultimamente.

Bem, agora vamos ao que interessa, a palestra.

O Rex Black (RB) iniciou a sua apresentação dizendo que os desafios que serão comentados são inerentes a forma ágil de desenvolvimento de software, e basicamente esses desafios possuem duas origens:

  • Do próprio agile;
  • Interpretações das pessoas.

Após esse breve e importante esclarecimento, o RB perguntou para a platéia quem utiliza metodologias ágeis, e um bom número de profissionais levantaram a mão. E isso mostra como é verdadeira a afirmação feita na sequência, de que ciclos de vida ágeis estão se tornando comum.

Alguns pontos importantes levantados pelo Rex foi:

  • Todas metodologias afetam o teste de software (isso parece até óbvio, mas muitas pessoas não percebem isso ou percebem da pior maneira);
  • No contexto ágil é necessário saber quais estratégias de teste funcionam bem. O RB citou três que funcionam bem:
    • Teste baseado em riscos (na minha opinião, teste baseado em riscos sempre funciona bem! [quando bem aplicado é claro]);
    • Automação de teste, incluindo teste de regressão funcional;
    • Teste reativo, cujos principais representantes são os famosos testes exploratórios.

E mesmo utilizando essas estratégias, elas não irão aliviar todos os desafios de teste com projetos ágeis. Por isso é muito importante entender os desafios, identificar os caminhos e saber como lidar com eles.

Volume e velocidade da mudança

No mundo ágil mudanças ocorrem toda hora, e elas não são encaradas como problemas e sim como oportunidades, por isso deve-se dar as boas-vindas a elas.

Bonito isso!  Mas como nós, profissionais de teste, podemos lidar com essas mudanças, uma vez que geralmente, elas costumam gerar grande retrabalho para nós:

  • Utilizando testes baseado em riscos, pois eles podem acomodar as mudanças;
  • Testes automatizados também ajudam a acomodar as mudanças: testes unitários e até de GUI (mesmo o último sendo mais “quebrável”);
  • O testadores devem ser manter atualizados para evitar ter falsos positivos.

Nos projetos agéis o tempo é muito curto

Em projetos agéis você não terá muito tempo para manter os testes, o tempo é muito limitado. Então ao automatizar você precisa saber que testes no banco de dados, são mais estáveis que testes na GUI. Além disso, o teste baseado em risco vai mais uma vez te ajudar, pois irá fazer você ser mais focado no que é mais importante. Lembre-se, no mundo ágil é preciso ter foco!

Testes unitários inadequados e inconsistentes

Uma das coisas em agile que o Rex Black mais gosta são os testes unitários, mas como o Fred Brooks disse “não existe a bala de prata” (isso em 1987, eu nem era nascido rs).

Mas antes de comentar sobre testes unitários o RB fez uma interessante analogia para explicar dois tipos de complexidades:

  • Complexidade acidental: tentar colocar o sapato do pé direito no pé esquerdo;
  • Complexidade essencial: você está no avião retira os seus sapatos para ficar mais à vontade, depois quando o voo já está chegando no seu destino, você vai colocar os sapatos, mas tem dificuldade, pois os pés estão inchados.

Ou seja, há uma complexidade causada por nós mesmos e outra causada por uma série de fatores do nosso contexto.

E assim sendo, os testes unitários precisam ser consistentes com a nossa aplicação, que por sua vez precisa ser adequada para que seja possível realizar testes unitários (ex.: problemas de testabilidade).

Mas testes unitários possuem dois problemas:

  • Eles têm um limite de “alcance” de bugs, de 25% a 30%, enquanto bons testes de sistemas tem média de 85%;
  • Nem todos os programadores fazem testes unitários.

O Rex Black frisou que os testes de unidade precisam acontecer, mas você precisa de ciência das suas limitações, pois não vamos fingir que agora tendo testes unitários não será preciso fazer mais outros testes.

Alguns outros pontos interessantes levantados pelo RB:

  • “Em agile não é preciso escrever nenhuma documentação”, essa é uma interpretação errada do manifesto;
  • Relatórios inválidos de bugs (com falso positivos) são um desperdiço de tempo, por isso é necessário os testadores estarem em constante interação com os desenvolvedores;
  • Todas equipes precisam encontrar o equilíbrio entre documentação e reuniões;
  • É preciso tomar cuidado para não espremer os testes, por exemplo: o projeto tem sprint de quatro semanas, e sempre há novos commits, os testes acabam sendo espremidos na última semana de todo sprint, ou seja, acabamos fazendo “cascatinhas”;
  • Os clientes da RBCS adotam agile utilizando equipes independentes de teste;
  • Não é necessário equipes totalmente independentes do time e nem totalmente dentro dos sprints, e sim um meio termo;
  • Sprint para o teste e outro para desenvolvimento não funciona;
  • Em agile tudo que você faz é um conjunto de coisas que você não faz (profunda essa frase rsrs);

O que aconteceu com a nossa base!?

Uma das respostas clássicas quando se pergunta qual é o objetivo do Teste de Software, é dizer que é garantir que a aplicação tenha sido implementada de acordo com os requisitos. E assim, os requisitos acabam sendo a principal fonte de informação e torna-se a base para os nossos testes.

Mas segundo o Rex Black, isso é um problema no contexto ágil, pois os requisitos podem mudar e então, os testes baseados em requisitos podem ser não efetivos, afinal estaremos atirando em alvos que estão sempre em movimento.

Ou seja, basear os seus testes em requisitos é muito difícil, quase impossível a longo prazo, caso você siga só essa estratégia.

O Rex Black ainda falou sobre as vantagens e desvantagens do testador atuar dentro da sprint:

  • Vantagens:
    • Foca nas tarefas relacionadas com aquela sprint;
    • Aloca e realoca o tempo baseado nos objetivos da sprint.
  • Desvantagens:
    • Perde a liberdade, ele passa a ser “liderado” pelo Scrum Master e não pelo Gerente Teste;
    • Tem uma visão reduzida do sistema.

Foi comentado durante a apresentação que há expectativas muito altas para o agile, principalmente por parte da gerência, e isso é um grande risco na implantação de agile, pois agile vai trazer benefícios no longo prazo e haverão muitos desafios.

Na conclusão da sua palestra o Rex Black fez as seguintes considerações:

  • É preciso ser muito cuidadoso na escolha das estratégias de testes;
  • É necessário manter os testes automatizados e realizar os teste de regressão baseados em riscos;
  • Testes reativos permitem os testadores explorar áreas que os testes baseados em risco e os automatizados não cobriram;
  • Tente ficar a frente dos desafios, espere por eles, seja pró-ativo ao lidar com os desafios, além disso seja realista perante a essa nova metodologia e o tempo que levará para ser tornar ágil, isso se você se tornar ágil;
  • Sempre teremos trabalho a fazer, nada virá pronto.

Ainda houve perguntas bem legais para o Rex Black, que abordaram a resistência de analisar os riscos, teste de performance durante as sprints e tempo da implantação do agile, gerando as seguintes respostas:

  • A Engenharia de Software é uma das principais atividades do ser humano. Se as pontes, prédios, escritórios quebrassem tanto quanto software seria inaceitável. Desta forma o primeiro passo para analisar os riscos é reconhecer a existência deles;
  • Problemas de desempenho geralmente são de design, e tem custos caros, portanto não espere até o fim, dessa forma, faça uma boa análise estática e teste em nível de unidade. E durante a sprint o software tem que  continuar funcionando (integração contínua);
  • Nem todo mundo precisa ser ágil e algumas pessoas levam mais tempo, isso até mesmo dentro de uma mesma organização. A implantação precisa ser democrática.

Impressões da palestra

A palestra do Rex Black foi excelente! Conseguiu falar com propriedade sobre uma temática recente, isso graças as experiências e vasto conhecimento em Teste de Software que ele possui. Um único ponto negativo, foi o excesso de texto nos slides (aliás, pelo que eu me lembre, quase todos os palestrantes colocaram muito texto nos slides).

No mais, foi muito interessante ouvir a experiência e opiniões do Rex Black sobre testes ágeis, realmente são uma série de desafios que enfrentamos quando iniciamos a implantação de práticas ágeis, e é muito difícil você encontrar literatura ou pessoas que falam sobre o assunto.

A conclusão que tirei da palestra foi que o Teste de Software pode sim ser ágil, e ele precisa ser ágil, logicamente que não é fácil, mas utilizando estratégias adequadas e pessoas preparadas podemos enfrentar de forma mais efetiva os desafios. E por fim, a realização de testes baseados em risco é fundamental, pois o tempo é bem curto, e não é possível fazer todos os testes, por isso precisamos estar sempre priorizando quais testes precisam ser feitos e os que não precisam, em suma: é preciso ter foco!

Bem pessoal, aqui encerro a primeira parte da cobertura do primeiro dia do CInTeQ 2010, até a segunda parte! 😀

Cobertura CInTeQ 2010 – Dia 1 (parte 2)

Fique por dentro das novidades, assine o feed do QualidadeBR.

Qual a melhor ou mais conhecida metodologia para avaliar a produtividade dos testadores?

A 16ª Mesa Redonda DFTestes teve  como tema “Qual a melhor ou mais conhecida metodologia para avaliar a produtividade dos testadores?”. A discussão teve 12 respostas e 6 participantes, sendo eles: eu, Elias Nogueira, Marcelo Andrade, Sarah Pimentel, Felipe Silva e o Rodrigo Almeida de Oliveira.

A seguir faço um “resumo” do que foi discutido na mesa redonda, quem quiser conferir a discussão na íntegra pode acessar esse link (é necessário cadastro).

Qual a melhor ou mais conhecida metodologia para avaliar a produtividade dos testadores?

O Elias Nogueira deu a sua resposta dizendo:

Olha, esse é um tema bem amplo e geralmente o terror de muitos testadores…
Já ví muitos “chefes” querendo medir a produtividade de um Analista de Teste pela quantidade de Casos de Teste criados, e isso é totalmente errôneo no meu ponto de vista.

A medição de produtividade, também ao meu ver, deve ser feita através de bases históricas, relacionando o tempo que um Analista de Teste levou para criar o Caso de Teste e quanto tempo um Testador levou para testar ou retestar. Só que precisamos dessas métricas, logo para ter uma estimativa aceitável para que eu possa chegar num Analista ou Testador e dizer que ele não está produzindo eu preciso de algo que me diga prove isso.

O normal que eu vejo é utilizar o bom senso em equipes que não possuem um base para estimativa e definir metas diárias ou semanais de execução e acompanhar o andamento, não em termos de cobrança mas para resolver os problemas que possam ocorrer e que geram uma parada nestas atividades.

O Elias ainda resumiu a sua opinião dizendo:

-> Só se pode medir produtividade se sabemos realmente quanto tempo é gasto na atividade (necessidade de base histórica);
-> Muitos problemas ocorrem durante essa fase (design e execução de teste) que influenciam, como requisitos mal escritos ou a falta dele, e até o não entendimento dos requisitos pela equipe;
-> Medir produtividade por quantidade de Casos de Teste criados não é legal!

A Sarah Pimentel fez a seguinte explanação sobre a questão:

Se determinada métrica é sentida pelo time como um objeto de pressão, talvez algo precise ser readequado, a métrica ou até mesmo a sua interpretação. O mais importante ai é que números são apenas números e sem explicações, sem o background de um cenário, eles não dizem muita coisa e o que dizem ainda pode estar errado.

Primeiro, pra que você quer medir a produtividade do seu time?

Crie uma resposta humana para essa pergunta e atenha-se a ela quando quiser medir a produtividade.

Medir a quantidade de casos de teste produzidos por dia (e agora sem considerar por analista) pode me ajudar a ver o percentual consumido do meu schedule até então e me ajudar a replanejá-lo, se for o caso,  para que as atividades sejam finalizadas.

Medir a quantidade de casos de teste produzidos por analista em um dia pode me ajudar a identificar problemas/dificuldades que não me foram diretamente sinalizadas por um membro da minha equipe quando sua média estiver muito aquém da margem dos seus colegas.  Ou se estiver muito além pode sinalizar um problema na elaboração dos casos (alguém já viu gente que cria um caso de teste de um step e dá ele como finalizado?).

Lembrando que existe uma média de produção diária, existem ocorrências que aceleram ou retardam essa produção, e existe a capacidade de produção de cada um que é diferente. Uns demoram mais, outros menos, e isso deve ser perfeitamente natural e aceitável em qualquer atividade.

Como medir produtividade de um time? Com alguém que entenda além de números e métodos estatísticos, de pessoas!

O Felipe Silva respondeu a questão dizendo:

Eu não conheço uma boa. A principal que conheço quantidades de TCs criados ou executados por determinado tempo. Sou totalmente contra este tipo de avaliação, pois desconsidera quase todos os fatores influenciadores, o primeiro desconsiderado nesta métrica é a qualidade, é fato que um teste feito com qualidade leva mais tempo que um teste feito de qualquer jeito (o que é facilmente descoberto quando os bugs que deveria ter sido pegos aparecem), ou fator desconsiderado é a complexidade da funcionalidade sob teste, testar 50PF (isso quando existe um tipo de métrica como PF) não é o mesmo que testar 5PF e também não é o mesmo que testar 5 funcionalidades de 10PF, e o terceiro fator desconsiderado que penso de primeira instancia é a qualidade inicial do código, pois testar uma funcionalidade que “funciona” é mais rápido do que testar uma que não funciona (tempo para relatar defeito, lerdeza da funcionalidade, fluxos que não funcionam e etc)

Não me perguntem uma forma de avaliar individualmente cada testador, pois não conheço um jeito justo e fácil (que não leve muito tempo para coletar), se for para avaliar “A equipe”, ai sim daria para calcular uma produtividade média.

O Rodrigo Almeida compartilhou como ele avalia a produtividade da sua equipe:

Aqui eu meço a produtividade da equipe baseado nas atividades entregues, tempo por atividade (gravação de caso de teste, execução dos testes manual/automatizado). E também avalio alguns itens subjetivos como postura profissional, trabalho em equipe, relacionamento, etc.

A Sarah ainda fez algumas sugestões de métricas que podem ser usadas:

Percentual de consumo de schedule :
-> para elaboração de casos de teste
->para execução de casos de teste no ciclos
Esse percentual pode ser medido levando em consideração:
-> quantidades (quantos casos de teste tenho a elaborar, quantos casos de teste tenho a executar, …), que não é muito real, mas ajuda;
-> tamanho (em relação ao tamanho total do software quanto você já cobriu considerando a representatividade do requisito coberto em UCPs ou FPs)
-> risco (utilizando o fator de risco de cada requisito)
Na minha opinião a “melhor ou mais conhecida metodologia para avaliar a produtividade dos testadores” é a que traga bons resultados e incentive a melhoria contínua na sua equipe. 😀
Pode ser tanto usando métricas, quanto pelo feeling. Uma junção dos dois pode ser interessante.

Com tanta coisa para fazer, por que eu ainda vou querer medir a produtividade dos testadores? Para fazer uma plaquinha de melhor testador do mês?

Segundo o Elias pode até ser feito bom uso da “plaquinha de melhor testador do mês”:

No termo da “plaquinha de funcionário do mês” dá pra fazer algumas coisas sim, e acho isso muito bom.

Um exemplo é ter a métrica de falsos-positivos por testador, que é, por exemplo, os bugs que são abertos que não são bugs ou mesmo a execução do Caso de Teste sem a devida atenção.

Outro é medir o tempo de reteste de um bug, onde tu vê se o testador está levando quase o mesmo tempo de execução do Caso de Teste.

Segue abaixo a minha resposta para a pergunta realizada.

Por que você é um gerente ausente?

Explicando melhor o motivo da minha pergunta.

Por que você é um gerente ausente?

Essa pergunta vale para quando essa necessidade de medir a produtividade vem do gerente/líder/coordenador da equipe.

A minha visão e opinião sobre uma pessoa que exerce um dos papéis citados acima, é que ela tem que interagir bastante com a equipe e conhecer bem ela.

Nos projetos que participei na empresa, que não é uma mega corporação, nunca tivemos a necessidade de medir a produtividade dos testadores, ou de qualquer outro membro da equipe. E isso deve ao fato de todos trabalharem juntos, fazerem reuniões periódicas sobre o andamento das tarefas, etc. Ou seja, todos atuando como um verdadeiro time.

E neste cenário os gerentes/líderes tem conhecimento de como estavam a produtividade de cada membro da equipe, e até os próprios membros da equipe tem essa informação, se eles se atentarem a ela.

Uma analogia que pode ajudar a entender melhor o que quero dizer:

Temos dois torcedores brasileiros: um vai assistir o jogo no estádio e o segundo vai ver pela TV.

No final do jogo quem terá uma melhor avaliação do desempenho da seleção brasileira?

O que viu no estádio, pois ele tem uma visão de todo o jogo e do comportamento dos jogadores quando estão sem a bola também. Na televisão a câmera foca onde está a bola, e assim o telespectador tem uma visão limitada do jogo.

Agora se a demanda por essa informação vem de outros e esses outros adoram métricas, o que é muito comum em nível gerencial, acredito que uma boa forma de informar essas métricas é através de resultados concretos obtidos pelos testadores, alguns exemplos:

  • Quantidade de casos de testes executados;
  • Número de bugs encontrados;
  • Quantidade de novos cenários de teste encontrados;
  • Quantidade de melhoria sugeridas.

Algo muito importante ao fazer um relatório sobre a produtividade do time é saber avaliar as métricas, pois números por si só são só números, nem sempre o testador que encontra mais bugs é o melhor ou mais produtivo.

E como disse antes, tentar medir trabalho cognitivo não é fácil e muitas vezes não é nem necessário utilizar métricas para isso, mas infelizmente muitas pessoas seguem o caminho da tirinha do Nerdson, compartilhada pelo Marcelo, que como um amigo meu diria, é uma verdadeira “PALHA-ASSADA”.

O Marcelo Andrade fez uma questão bem pertinente a discussão, sobre a definição de produtividade.

Afinal de contas, o que é “produtividade”?

A Sarah Pimentel respondeu a pergunta trazendo a definição da Wikipédia:

“A produtividade é basicamente definida como a relação entre a produção e os factores de produção utilizados. A produção é definida como os bens produzidos (quantidade de produtos produzidos). Os factores de produção são definidos como sejam pessoas, máquinas, materiais e outros. Quanto maior for a relação entre a quantidade produzida por factores utilizados maior é a produtividade.”

Sendo assim, a quantidade de casos de teste criados por um analista em um dia é sim uma métrica de produtividade. Se ela deve ser utilizada ou como ela deve ser utilizada é outro ponto.

Eu vejo que produtividade é: tempo de trabalho – tempo trabalhado  X resultados

Exemplo: o Zé trabalhou 8 horas, mas só durante 6 horas 100% focado no trabalho (1 de almoço e mais 1 de procrastinação) e nesta 6 horas ele conseguiu:

  • Preparar o ambiente de teste.
  • Executar os casos de testes da funcionalidade X e Y;
  • Reportar 6 bugs.

Mas e aí, o Zé foi produtivo ou não? Para saber é necessário ter uma base histórica, analisar as características das atividades (ex.: o ambiente de teste era Windows/Linux, quais softwares teve que instalar, etc). Ou seja, as métricas em si não são o fim, e sim o início para avaliar a produtividade do testador.

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

Fique por dentro das novidades, assine o feed do QualidadeBR.

O melhor da semana 14/03 a 20/03

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. 🙂

Abraços! E tenham uma ótima semana!

Fique por dentro das novidades, assine o feed do QualidadeBR.

Certificação IREB pela primeira vez no Brasil

Estava dando uma lida na página de palestrantes do CInTeQ 2010 e encontrei essa informação sobre a aplicação de uma das certificações do IREB (International Requirements Engineering Board) aqui no Brasil, a Certified Professional for Requirements Engineering – Foundation Level.

A aplicação do exame será dada somente para quem participar do treinamento ministrado pelo Arjan Brands, durante os dias 24, 25, 26 de março. O exame será aplicado logo após o curso, no dia 27 de março.

O treinamento tem o custo de R$1.500,00 e é prepatório para a certificação Certificate CPRE FL – Foundation Level e o candidato deverá comprovar no exame total domínio sobre os conhecimentos abordados no Syllabus CPRE-FL.

Maiores informações podem ser obtidas na seguinte página do CInTeQ:

http://www.cinteq.org.br/?q=node/44

Fique por dentro das novidades, assine o feed do QualidadeBR.