As principais atividades do gerenciamento de riscos são:
Identificação – identificar (ou as vezes imaginar) quais são/serão os riscos de projeto e de qualidade
Analise – classifica-los dentro de um nível, normalmente caracterizado por uma relação de impacto e probabilidade
Controle – abrange o conjunto de atividade de mitigação, contingência, transferência e aceitação de riscos
Um pouco mais de cada uma...:
IDENTIFICAÇÃO DE RISCOS
Como identificar riscos? Algumas sugestões:
-Entrevista com especialistas (na tecnologia e no negócio – pessoas diferentes, provavelmente)
-Checklists
-Analisar projetos similares já realizados
-Workshops, brainstorms
Pode ser interessante manter separadamente os riscos de projeto e os riscos de qualidade já que as pessoas que detém o conhecimento para elencá-los podem ser diferentes. O levantamento, entretanto pode ocorrer simultaneamente.
É possível detectar riscos estudando a documentação do projeto, nessa prática, essa revisão pode ajudar a encontrar erros na documentação.
As reuniões de identificação podem parar na detecção dos riscos, ou na própria reunião pode ser possível classificá-los ou mesmo detectar seu impacto. O acúmulo de atividades na reunião depende do andamento e produtividade dela.
ANÁLISE/AVALIAÇÃO DE RISCOS
Depois de identificá-los, deve ser feito um estudo emcima de cada risco categorizando-os e atribuindo-les um nível.
Sobre atribuir um nível, já foi mencionado que isso pode ser feito através da relação de impacto e probabilidade. Mas como definir isso? Probabilidade está normalmente relacionada a fatores técnicos e Impacto a fatores de negócio.
Exemplos de fatores técnicos:
-Complexidade da tecnologia
-Conhecimento do time
-Incompatibilidade de tecnologia legada com a aplicada
-Falta de quality assurance
-Ausência de testes em fases iniciais
E vários outros
Exemplos de fatores de negócio:
-Frequencia/Sazonalidade de uso de uma funcionalidade
-Possibilidade de sanções criminais
-Potenciais perdas de lucros
Entre outros
Pode-se atribuir o nível de risco quantitativamente ou qualitativamente. Quantitativamente pode-se considerar a probabilidade como um percentual e o impacto como um valor financeiro e assim teríamos exatamente o que representa o risco em números.
O mais comum é vermos essa atribuição qualitativamente, isso porque é difícil ter a base estatística necessária para pontuar quantitativamente. Qualitativamente os endereçaríamos como riscos de nível alto, médio ou baixo.
Sobre categoria, pode-se usar por exemplo as características descritas na ISO9126 (Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade, Portabilidade e suas sub caracteristicas). E pra que serve isso? No geral, para determinar os responsáveis (ou áreas responsáveis) pelos grupos de riscos. Isso, claro, se houver um motivo prático para categoriza-los.
MITIGAÇÃO/CONTROLE DE RISCOS
Os riscos podem ser controlados através das atividades de:
-Mitigação
-Contingência
-Transferência
-Aceitação
A mitigação consiste na definição de atividades que possam diminiur o impacto ou a probabilidade de um risco ocorrer.
A contigência é utilizada como uma ação caso o risco venha a ocorrer (quando um risco acontece, deixa de ser um risco, passa a ser um fato ou issue).
A tranferência consiste em transferir para outra parte o risco. E não interpretar isso como um jogo de culpas entre times. Nesse processo, no caso de uma empresa prestando serviço para um cliente, o risco pode ser assumido pelo cliente ao invés da empresa ou vice-versa, entre outras situações.
A abordagem analítica de teste baseado em riscos foca na criação de ações de mitigação, especialmente de riscos de qualidade, para o time de teste. O teste mitiga os riscos de qualidade durante todo o ciclo de desenvolvimento.
Alguns riscos de projeto também podem ser controlados, como:
Preparação adequada de ambiente de teste e ferramentas
Baixa qualidade de inputs para o teste
Falta de padrões, regras e tecnicas para o teste
Apesar de ser papel do gerente de controlar esses riscos, são riscos que afetam os analistas e estes devem controlá-los também.
Testes preventivos são parte da estratégica de testes baseados em riscos. A idéia é mitigar os riscos de qualidade antes mesmo da execução dos testes preparando bem o ambiente de testes, fazendo um pre teste antes de começar formalmente uma fase de testes, participando em reuniões e revisão/inspeção, monitorando o progresso e a qualidade do projeto, etc.
Oportunidades de aplicação de testes preventivos:
-Escolher a tecnica de testes adequada
-Realizar revisões e inspeções
-Revisar os projetos de teste
-Definir estratégias de testes de confirmação e regressão
Perceba que as atividades do teste preventivo não são as que comumente lembramos quando falamos de teste. Se os requisitos parecem não estar bem definidos, então o ideal é realizar revisões e inspeções, ao invés de postergar essas correções para a fase de testes.
Existem duas formas de priorizar os testes: depth-first ou breadth-first.
Depth-first: Todos os testes dos riscos mais altos são rodados primeiros e os riscos mais baixos por último.
Breadth-first: São selecionadas amostragens em todos os níveis de riscos, usando esses níveis para ponderar as seleções (são selecionados mais testes de níveis de risco mais alto, que de nivel mais baixo).
A melhor cobertura depende de uma análise do seu projeto.
E a famosa pergunta: quando parar de testar? Nessa abordagem a resposta é; Quando o risco residual for considerado aceitável.
Supondo que não tenhamos mais tempo para testar ou que o tempo foi reduzido e não será possível cumprir o planejamento inicial. Como realinhar a estratégia? Repriorizando os testes de acordo com os resultados obtidos. Mas exatamente o que olhar nesses resultados?
-Novos riscos de produtos
-Áreas muito modificadas
-Áreas instaveis descobertas durante os testes
-Riscos associados a defeitos
-Descoberta de bug clusters inesperados
-Descoberta de áreas críticas de negócio
Aproveite para atualizar o seu planejamento de riscos inicial.
segunda-feira, 30 de novembro de 2009
quinta-feira, 19 de novembro de 2009
IV EBTS
Já está aberto o prazo de submissão de artigos para o IV Encontro Brasileiro de Testes de Software em Recife/PE
Os interessados podem submeter seus trabalhos até o dia 29 de dezembro, em formato PDF, através do e-mail ebts@gotest.biz. Os artigos devem conter entre quatro e seis páginas e seguir o modelo da ACM SIG Proceedings, disponível gratuitamente no site www.acm.org/sigs/pubs/proceed/template.html.
Os artigos a serem submetidos ao IV EBTS devem oferecer um melhor entendimento sobre boas práticas de testes de software, além de se reportar a lições aprendidas, inovações e aplicações práticas. No dia 25 de janeiro, será divulgada a relação dos artigos aceitos. Os selecionados terão até o dia 15 de fevereiro para entregar a versão final e o material de apresentação a ser usado durante o evento.
O EBTS é um evento que visa promover o intercâmbio de idéias entre empresas e academia com o objetivo de estimular debates e discussões sobre testes de software, promovendo, assim, a troca de conhecimentos e a integração entre academia e o mercado.
O encontro acontecerá entre os dias 23 e 24 de abril e terá, em sua programação, palestras técnicas, mini-cursos, convidados renomados da área de testes, competições e premiações. A iniciativa é promovida pela GOTEST e conta com apoio do C.E.S.A.R e do Porto Digital.
Mais informações através do site http://www.gotest.biz/ebts2010/
Os interessados podem submeter seus trabalhos até o dia 29 de dezembro, em formato PDF, através do e-mail ebts@gotest.biz. Os artigos devem conter entre quatro e seis páginas e seguir o modelo da ACM SIG Proceedings, disponível gratuitamente no site www.acm.org/sigs/pubs/proceed/template.html.
Os artigos a serem submetidos ao IV EBTS devem oferecer um melhor entendimento sobre boas práticas de testes de software, além de se reportar a lições aprendidas, inovações e aplicações práticas. No dia 25 de janeiro, será divulgada a relação dos artigos aceitos. Os selecionados terão até o dia 15 de fevereiro para entregar a versão final e o material de apresentação a ser usado durante o evento.
O EBTS é um evento que visa promover o intercâmbio de idéias entre empresas e academia com o objetivo de estimular debates e discussões sobre testes de software, promovendo, assim, a troca de conhecimentos e a integração entre academia e o mercado.
O encontro acontecerá entre os dias 23 e 24 de abril e terá, em sua programação, palestras técnicas, mini-cursos, convidados renomados da área de testes, competições e premiações. A iniciativa é promovida pela GOTEST e conta com apoio do C.E.S.A.R e do Porto Digital.
Mais informações através do site http://www.gotest.biz/ebts2010/
quinta-feira, 22 de outubro de 2009
Testes basedos em riscos
Uma introdução a testes baseados em riscos...
Risco é a possibilidade de um evento negativo ou indesejável ocorrer. Um risco específico é qualquer problema que possa afetar negativamente a experiência do usuário ou o sucesso do projeto.
Em testes há dois tipos de riscos com os quais nos preocupamos. Riscos de produtos são potencias problemas que podem afetar a qualidade do produto e Riscos de projeto (ou riscos de planejamento) são riscos que podem afetar o sucesso do projeto em termos de operações.
Exemplos:
Risco de produto: um defeito que possa causar pane no sistema
Risco de projeto: diminuição dos membros de projeto (staffing shortage)
Cada risco possui um nível de importância que é classificado de acordo com a sua probabilidade e seu impacto.
A probabilidade pode ser medida por exmeplo pela linguagem utilizada, pela banda de transmissão de dados, pelo espaço em disco, etc. O impacto é medido de acordo com considerações do negócio como perda financeira, número de usuários impactados, etc.
É interessante no início do projeto ter alinhado esses conceitos que tendem a ser muito subjetivos. Numerando os níveis de probabilidade e impacto, é indicado que todos tenham um entendimento ao menos bastante parecido do que eh nível 1, 2, etc. Simplesmente dizer que 1 é maior que 5 ou que 5 é maior que 1 nao é muito parâmetro. É indicado que essa explicação seja feita através de exemplos.
Em uma abordagem de testes baseadas em riscos, a listagem de riscos levantadas é o ponto mais importante do processo e também ponto de partida para o planejamento.
O risco pode guiar todas as atividades de teste. É possível alocar esforços por nível de risco, selecionar tecnicas de teste, direcionar ordem de execução e inclusive guiar a priorização de correção de testes baseado na classificação dos riscos levantados. Também os reports de execução podem ser direcionados a riscos informando que riscos foram cobertos, quais não foram, qual a incidência de erro neles, etc.
Os riscos precisam ter planos de mitigação e/ou contingência e quanto maior sua importãncia (probabilidade x impacto), mais de perto ele deve ser acompanhado. A reunião de levantamento/acompanhamento de riscos deve ser uma constante no projeto e não acontecer apenas uma vez no início. É importante saber se mudou a importância do risco, qual o resultado das ações de mitigação e inclusive se o risco continua sendo um risco ou se, devido a aplicação de ações de mitigação ou mesmo mudanças de cenário no decorrer do projeto, deixou de ser um risco. També novos riscos podem ser indentificados. Esse acompanhamento resulta em novas avaliações de prioridades no projeto e talvez em realocação de esforços de teste.
Risco é a possibilidade de um evento negativo ou indesejável ocorrer. Um risco específico é qualquer problema que possa afetar negativamente a experiência do usuário ou o sucesso do projeto.
Em testes há dois tipos de riscos com os quais nos preocupamos. Riscos de produtos são potencias problemas que podem afetar a qualidade do produto e Riscos de projeto (ou riscos de planejamento) são riscos que podem afetar o sucesso do projeto em termos de operações.
Exemplos:
Risco de produto: um defeito que possa causar pane no sistema
Risco de projeto: diminuição dos membros de projeto (staffing shortage)
Cada risco possui um nível de importância que é classificado de acordo com a sua probabilidade e seu impacto.
A probabilidade pode ser medida por exmeplo pela linguagem utilizada, pela banda de transmissão de dados, pelo espaço em disco, etc. O impacto é medido de acordo com considerações do negócio como perda financeira, número de usuários impactados, etc.
É interessante no início do projeto ter alinhado esses conceitos que tendem a ser muito subjetivos. Numerando os níveis de probabilidade e impacto, é indicado que todos tenham um entendimento ao menos bastante parecido do que eh nível 1, 2, etc. Simplesmente dizer que 1 é maior que 5 ou que 5 é maior que 1 nao é muito parâmetro. É indicado que essa explicação seja feita através de exemplos.
Em uma abordagem de testes baseadas em riscos, a listagem de riscos levantadas é o ponto mais importante do processo e também ponto de partida para o planejamento.
O risco pode guiar todas as atividades de teste. É possível alocar esforços por nível de risco, selecionar tecnicas de teste, direcionar ordem de execução e inclusive guiar a priorização de correção de testes baseado na classificação dos riscos levantados. Também os reports de execução podem ser direcionados a riscos informando que riscos foram cobertos, quais não foram, qual a incidência de erro neles, etc.
Os riscos precisam ter planos de mitigação e/ou contingência e quanto maior sua importãncia (probabilidade x impacto), mais de perto ele deve ser acompanhado. A reunião de levantamento/acompanhamento de riscos deve ser uma constante no projeto e não acontecer apenas uma vez no início. É importante saber se mudou a importância do risco, qual o resultado das ações de mitigação e inclusive se o risco continua sendo um risco ou se, devido a aplicação de ações de mitigação ou mesmo mudanças de cenário no decorrer do projeto, deixou de ser um risco. També novos riscos podem ser indentificados. Esse acompanhamento resulta em novas avaliações de prioridades no projeto e talvez em realocação de esforços de teste.
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 :)
quinta-feira, 27 de agosto de 2009
Processo de Teste: Implementação e Execução II
Continuando post Processo de Teste: Implementação e Execução, agora com foco maior em Execução.
Iniciando a execução dos testes
Para iniciar os testes, espera-se que os critérios de entrada para essa fase tenham sido atendidos e que esses critérios cubram o que foi discutido no post anterior.
Nessa fase, espera-se que todas as condições de teste e riscos de qualidade tenham sido cobertos e que todos os passos do procedimento de teste tenham sido executados. (...) E por que não seriam?
Como não cobrir as condições de teste e riscos de qualidade? Com testes em alto nível que dependem da interpretação do testador ou que exigem do testador maior conhecimento na aplicação.
Como não executar todos os passos? Alguns passos podem corresponder à configuração de dados, realização de pré condições, retorno do sistema ao estado inicial antes do teste, etc. Em algumas situações esses passos podem ser pulados resultando na execução parcial do teste.
Nos testes manuais pode-se adicionar um certo grau de testes exploratórios deixando o procedimento um pouco mais vago ou na orientação dos testadores explicando que o teste pode servir como um mapa, um guia do que tem que ser testado e que eles podem explorar essa área e investigar os pedaços que eles considerem mais interessantes.
Zoom: Executando um procedimento de teste
Ao executar um procedimento de teste o testador vai comparar o resultado obtido com o resultado esperado no teste e esse é o momento que realmente agrega valor. Tudo o que foi realizado até agora foi para chegar a esse momento, portanto o registro dessas anomalias é a parte mais importante de todo o processo. E falando em anomalia, vamos lá ao dilema das definições.
SEGUNDO O ISTQB: Um resultado obtido diferente de um resultado esperado é uma anomalia e ao a observarmos, temos um incidente. Até ai tudo bem? :) Alguns incidentes são falhas. Uma falha ocorre quando o sistema não se comporta adequadamente devido a um ou mais defeitos. Nesse caso podemos coletar dados e situações para ajudar os desenvolvedores a solucionar o defeito. Alguns incidentes podem não ser falhas mas falso positivos, ou seja, o resultado obtido foi diferente do esperado por má especificação dos testes, dados inválidos, ambiente mal configurado, etc.
Reportando resultados de testes
Maiores detalhes Reportando Defeitos
Não é possível usar o valor que você ganhou na realização dos testes se você não registrá-lo. Em estratégias de teste reativas, é possível usar os defeitos registrados para fazer um script ou mesmo como base de conhecimento da aplicação. No post acima eu listo alguns dados a serem incluídos nessa reportagem de defeitos.
É importante para o controle e gerenciamento do projeto reportar qualquer problema que atrase, interrompa ou bloqueie os testes. Por exemplo: Se na hora de começar os testes descobre-se que o ambiente está fora, está correndo o tempo de execução de testes e é impossível executá-los, é possível abrir um defeito de ambiente e o tempo de correção deve ser indicado com uma das justificativas de atraso (se houver) na execução.
Padrões
IEEE 829 test procedure specification. Esse documento especifica como rodar um ou mais testes e inclui as seguintes seções:
- identificador da test procedure
- objetivo (que testes serão rodados)
- requisitos especiais (permissões, habilidades, ambiente...)
- passos do procedimento (logar, configurar, executar os passos, medir os resultados, finalizar, recomeçar, parar, etc)
IEEE 829 também sugere o que colocar em um log de teste:
- identificador do test log
- descrição do teste (itens de tetse, ambiente, versões, etc)
- atividades e eventos de entrada
Outros padrões que sugiro que dêem uma lida: BS 7925/2 e DO-178B(ou ED-12B).
Iniciando a execução dos testes
Para iniciar os testes, espera-se que os critérios de entrada para essa fase tenham sido atendidos e que esses critérios cubram o que foi discutido no post anterior.
Nessa fase, espera-se que todas as condições de teste e riscos de qualidade tenham sido cobertos e que todos os passos do procedimento de teste tenham sido executados. (...) E por que não seriam?
Como não cobrir as condições de teste e riscos de qualidade? Com testes em alto nível que dependem da interpretação do testador ou que exigem do testador maior conhecimento na aplicação.
Como não executar todos os passos? Alguns passos podem corresponder à configuração de dados, realização de pré condições, retorno do sistema ao estado inicial antes do teste, etc. Em algumas situações esses passos podem ser pulados resultando na execução parcial do teste.
Nos testes manuais pode-se adicionar um certo grau de testes exploratórios deixando o procedimento um pouco mais vago ou na orientação dos testadores explicando que o teste pode servir como um mapa, um guia do que tem que ser testado e que eles podem explorar essa área e investigar os pedaços que eles considerem mais interessantes.
Zoom: Executando um procedimento de teste
Ao executar um procedimento de teste o testador vai comparar o resultado obtido com o resultado esperado no teste e esse é o momento que realmente agrega valor. Tudo o que foi realizado até agora foi para chegar a esse momento, portanto o registro dessas anomalias é a parte mais importante de todo o processo. E falando em anomalia, vamos lá ao dilema das definições.
SEGUNDO O ISTQB: Um resultado obtido diferente de um resultado esperado é uma anomalia e ao a observarmos, temos um incidente. Até ai tudo bem? :) Alguns incidentes são falhas. Uma falha ocorre quando o sistema não se comporta adequadamente devido a um ou mais defeitos. Nesse caso podemos coletar dados e situações para ajudar os desenvolvedores a solucionar o defeito. Alguns incidentes podem não ser falhas mas falso positivos, ou seja, o resultado obtido foi diferente do esperado por má especificação dos testes, dados inválidos, ambiente mal configurado, etc.
Reportando resultados de testes
Maiores detalhes Reportando Defeitos
Não é possível usar o valor que você ganhou na realização dos testes se você não registrá-lo. Em estratégias de teste reativas, é possível usar os defeitos registrados para fazer um script ou mesmo como base de conhecimento da aplicação. No post acima eu listo alguns dados a serem incluídos nessa reportagem de defeitos.
É importante para o controle e gerenciamento do projeto reportar qualquer problema que atrase, interrompa ou bloqueie os testes. Por exemplo: Se na hora de começar os testes descobre-se que o ambiente está fora, está correndo o tempo de execução de testes e é impossível executá-los, é possível abrir um defeito de ambiente e o tempo de correção deve ser indicado com uma das justificativas de atraso (se houver) na execução.
Padrões
IEEE 829 test procedure specification. Esse documento especifica como rodar um ou mais testes e inclui as seguintes seções:
- identificador da test procedure
- objetivo (que testes serão rodados)
- requisitos especiais (permissões, habilidades, ambiente...)
- passos do procedimento (logar, configurar, executar os passos, medir os resultados, finalizar, recomeçar, parar, etc)
IEEE 829 também sugere o que colocar em um log de teste:
- identificador do test log
- descrição do teste (itens de tetse, ambiente, versões, etc)
- atividades e eventos de entrada
Outros padrões que sugiro que dêem uma lida: BS 7925/2 e DO-178B(ou ED-12B).
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.
Assinar:
Postagens (Atom)