O melhor da semana 22/11 a 28/11

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ções, valem a pena?

“Certificações, valem a pena?” esse foi o tema da quarta Mesa Redonda DFTestes, que contou com 19 participantes: eu, Maria Meire, Vinicius Sabadoti, Edwagney Luz, Aline Barbieri, Renata Eliza, Felipe Silva, Sarah Pimentel, Rodrigo Ribeiro, Janaina Trilles, Ricardo Franco, Elias Nogueira, Aderson Bastos, Wagner Duarte, Marcelo Andrade, Vitor Machel, Denis Ferrari, Wesley Baldan e o Eduardo Gomes.

Certificações é um assunto que costuma gerar muita discussão em qualquer comunidade, e como puderam perceber não foi diferente dessa vez, tanto que tivemos a mesa redonda mais agitada (31 respostas). O pessoal mais uma vez deu um show!

Então, chega de blá-blá e vamos para o resumo da mesa redonda, desta vez foi mais difícil ainda resumir, e infelizmente muitos bons comentários tiveram que ficar de fora, então se quiser ler a discussão na íntegra, basta acessar o DFTestes.

Certificações, valem a pena?

Para o Vinicius Sabadoti a certificação pode ajudar na efetivação:

Na minha opinião uma certificação é válida e ela pode ser vista de forma diferente entre as empresas e como estou tentando uma efetivação, uma certificação no meu caso ajudaria sim e muito.

Já para o Edwagney, a questão não é tão simples, e depende de alguns fatores:

Depende de quem está contratando. Se quem está contratando não sabe o que quer, SIM certificação vale a pena. Se quem contrata sabe o que quer, NÃO, uma certificação não vale a pena. Explico o motivo da minha opinião. Creio que em tudo na vida prezamos pela experiência. Como diz o ditado, “mais vale um pássaro na mão do que dois voando”, mais vale uma pessoa experiente e que sabe o que está fazendo do que alguém que tem “n” certificações no currículo e não sabe colocá-las em prática. Sou uma pessoa que gosta e pratica o termo “liderança pelo exemplo”, então mais uma vez uso um exemplo do nosso cotidiano com a seguinte reflexão: Quando procuramos um médico, buscamos saber primeiro quais certificações ele tem ou informações a respeito de seu tempo de profissão e experiência em relação ao problema que queremos tratamento?  A resposta fala por si só.

A Renata Eliza lembrou que uma certificação é um investimento a médio e longo prazo:

Sim! Acredito que as certificações são super importantes.  Mas uma coisa é fato: não tire uma certificação pensando no retorno financeiro imediato. Você pode acabar se frustrando.  Tire pensando na bagagem de conhecimento que vai adquirir.  Porém, não basta apenas se certificar, tem que por em prática.

A nossa área só vai ser valorizada e ter o seu devido reconhecimento quando os profissionais se especializarem (comece com uma certificação!  Quem vai querer pagar “bem” alguém que não faz absolutamente nada de diferente?  A valorização do investimento virá com o tempo.

Para o Felipe Silva:

Depende, se você for ganhar um aumento por ela ou se for acrescentar conhecimento, então Sim. Já estudei materiais de várias certificações, meses de estudo, me acrescentou alguns conceitos, porém por desvio do destino não fiz as provas, conclusão: tenho o conhecimento, mas não o certificado, logo para mim só compensaria tirar a certificação se eu fosse ter um aumento mostrando meu certificado, ou se futuramente eu fosse trocar de empresa ai eu poderia colocar no currículo – como já foi dito, hoje existem muitos processos seletivos que contratam “currículos” e não pessoas.

A Sarah Pimentel citou o interessante post do Elias Nogueira sobre certificação e os do James Bach. E a seguir deu sua opinião sobre a pergunta:

Contra meus princípios, mas sim. Como eu disse, temos que dançar conforme a musica. Até você virar uma lenda, é o que você tem para se destacar.

Na minha opinião depende de uma coisa básica, qual o seu objetivo com a certificação. Se for adquirir conhecimento vale até certificação de corte e costura. Agora se for pra ficar se gabando por aí, e pensar que você é o cara e que depois de conquistar a certificação vai duplicar o salário, sinto muito, mas você irá se decepcionar, e sendo franco, você precisa antes aprender algumas coisinhas que nenhuma certificação te ensina, só a vida.

O Marcelo Andrade compartilhou uma visão interessante:

Certificações em tecnologia sempre valem a pena.
Certificações em produtos de uma dada empresa/organização, quase sempre NÃO valem a pena.

Para o Denis Ferrari:

Sim. Certificações podem ser utilizadas como direcionamento para os estudos. Existem áreas (desenvolvimento por ex.) onde a área de estudo é muito ampla, uma certificação fornece um roteiro que pode ser utilizado como orientação.  Infelizmente a forma principal de avaliar um fornecedor é por certificações (técnicas/qualidade), ou seja, o profissional que tiver uma certificação ajudará a empresa a ser competitiva no mercado.

O Eduardo Gomes acredita que certificações valem a pena sim:

Acredito que as certificações valem muito a pena. Na pior das hipóteses elas servem para que falemos a mesma “língua”.
Mas vejo muitas outras contribuições, por exemplo, para a obtenção de conhecimentos teóricos, para a ampliação da visão sobre testes e para a troca de experiências entre os profissionais da área.

E o Eduardo ainda lembrou que profissionais certificados podem ajudar as empresas em processos de licitações, por exemplo:

Concordo com muita coisa que já foi dita nessa discussão, sobre as certificações não substituírem a prática ou que exista uma exploração financeira por trás de muitas delas, mas vejo também que as certificações continuam representando um diferencial para o mercado.

Já participei de alguns processos de seleção e mesmo de licitações, onde as certificações eram consideradas nas análises. Isso é válido, mas deve ser utilizado como complemento a outros dados considerados. Não se deve dar preferência a trazer para o time um profissional certificado, sem considerar outras questões como experiência e atitude, por exemplo. O conjunto deve ser analisado e quanto mais completo, melhor.

Por que as certificações são hoje em dia tão criticadas?

De acordo com o ponto de vista do Edwagney:

No meu ponto de vista, creio que são criticadas pelo fato de algumas empresas valorizarem mais uma certificação do que a experiência do profissional. Vejo isso com a certificação do PMI. Conheci o PMI em 2000, quando fiz o curso introdutório de gerenciamento de projetos. A chamada para se tornar um GP era de conseguir ganhos bem acima da média de quem não era certificado. Recém-formados, e certamente sem nenhuma experiência, estudavam por alguns meses e conseguiam a certificação e já entravam na empresa achando que já sabiam gerenciar. Só que existe um fator HUMANO por trás da disciplina de gerenciamento que um simples curso preparatório não ensina. É necessário vivência. Nem todo mundo consegue ser gerente. Isso é fato.

Não sou contra certificações, apenas acho que um simples teste, em nenhuma hipótese valida se um profissional é realmente bom naquilo que se certificou ou não. Quem prova isso é o tempo de vivência profissional. O conceito de certificação, deveria ser para auxiliar no aprimoramento dos conhecimentos de um profissional e não certificar que ele entende de determinado assunto, como é vendido hoje.

A Sarah Pimentel citou 5 motivos:

  • Tem um monte de criança na Índia que são certificadas Microsoft (excetuando-se os geniozinhos, é só estudar e fazer uma prova, igual a OAB e por ai vai);
  • Tem bons profissionais que ficam nervosos em uma prova e não é pq não passaram que não sabem;
  • Tem PÉSSIMOS profissionais certificados;
  • Tem profissionais certificados que acham que sabem de tudo porque tem uma certificação e não precisam se desenvolver;
  • Porque às vezes uma certificação conta mais que a experiência.

Na minha opinião, porque foram superestimadas pelo mercado, e os profissionais entraram na onda, e muitos só com o intuito de poder tirar proveitos financeiros futuramente com a obtenção do título. Porém, não vejo muito o cenário acima citado na nossa área, pois são poucas as vagas que pedem profissionais certificados, os profissionais são mais conscientes em relação as certificações e para passar nos exames não é tão fácil assim.

Por que há tantas certificações na nossa área?

O Aderson Bastos foi bem claro, e acredita que isso é bom para a nossa área:

Porque há demanda. Que bom que temos tantas opções!

O Edwagney deu uma interessante resposta, respondendo com uma outra pergunta:

Será que posso afirmar que é pelo fato de ser extremamente rentável para as instituições?

Acredito que o Edwagney pode afirmar sim a sua frase. Certificações é algo muito rentável, e um exemplo clássico é mercado de SAP, se bem que nesse caso, costuma ser rentável para ambos os lados.

Um profissional de Teste de Software deve se restringir as certificações da sua área apenas?

Para o Elias Nogueira, se você tiver experiência em outra área, já é suficiente, você não precisa necessariamente também tirar uma certificação:

Ter conhecimentos em outras áreas conta, mas certificação para isso, na minha visão, não é mandatório. Venho de um perfil técnico, programava profissionalmente em Java. Eu preciso de uma certificação Java? Resposta: NÃO, minha experiência já responde a pergunta. E muitas empresas também tem esse contraponto: experiência x conhecimento (não prático). A certificação pode levar a esse conhecimento não prático.

Para o Edwagney, mais uma vez depende do foco da sua carreira:

Depende do foco que ele quer dar em sua carreira. Se quer uma carreira como técnico, sim, fica restrito. Se quer uma carreira gerencial, definitivamente não. Precisa buscar outros tipos de certificações e conhecimentos inerentes ao contexto em que se quer atingir.

Já para o Felipe Silva, é melhor você tirar uma certificação em outra área, do que tirar uma segunda na mesma área:

Não, mesmo se o foco for à carreira técnica uma certificação em programação na linguagem se você automatiza ou uma certificação em DB é boa, e em minha opinião é melhor ter essas 3 certificações (Testes + Programação + DB) do que 3 certificações de testes de instituições diferentes, pois o que acaba mudando no final é basicamente o nome da certificação, voto sempre pela agregação do conhecimento ao invés da agregação de um certificado (papel).

O Rodrigo Ribeiro é um bom exemplo, de que um profissional não deve focar apenas em certificações relacionadas a sua área:

Não! Mais uma vez: “a oportunidade faz o ladrão” (rs). Eu por exemplo pretendo tirar uma certificação voltada para programação Java daqui a alguns meses. Saber programação/metodologias ágeis/gerência/outros é primordial para formação de um profissional mais completo e com abrangência em mais áreas de estudo e/ou retorno de resultados no trabalho. Vejo pela lista que vários dos grandes nomes de Qualidade de Software tem abrangência/ buscam abrangência em outros “ramos”. Certificações Oracle, Java, Scrum, PMI e outras são exemplo. E claro que a experiência auxilia e muito nisso, fora estar ciente de que aquilo será benéfico no meio em que irá tirar proveito.

Não minha opinião você  não deve se restringi, porém lembre-se que para você saber algo não é necessário uma certificação, como costumo dizer, a certificação é um detalhe dos seus esforços, o mais importante é você aprender. Como o Felipe relatou, se você usar o material de uma certificação para estudar e aprender, você já conquistou o mais importante o conhecimento, a certificação é um mero papel, supervalorizado por alguns. E além disso, acredito que a certificação em outra área só é válido se o conteúdo estudado faz parte do seu trabalho, caso contrário, o melhor a ser fazer é estudar por conta própria, estudando o que vai agregar mais para o seu trabalho.

O Marcelo Andrade lembrou que o profissional da área de Teste de Software é por natureza um generalista:

O velho debate sobre profissionais generalistas versus especialistas.
Mas pela própria natureza multidisciplinar do teste de software, são inerentemente necessários vários conhecimentos para um BOM profissional de testes.

Qual a posição do mercado em relação aos profissionais certificados?

O Aderson Bastos compartilhou a sua visão como empresário:

Se eu estiver com dois candidatos igualmente competentes e somente uma vaga, contratarei aquele que tiver uma certificação que eu valorize.  Contratar ou aumentar o salário de alguém só porque esta pessoa possui uma certificação é algo extremamente arriscado e perigoso.  Os profissionais devem ser reconhecidos e valorizados pelo valor que agregam à organização e não pela quantidade de certificados que possuem. O conhecimento implícito em algumas certificações, ajuda os profissionais a agregarem valor.

O Edwagney compartilhou a seguinte opinião:

Vejo as organizações colocarem certificação como sendo um diferencial, porém outras colocam as certificações como sendo essenciais.

As que colocam como um diferencial, acredito que sejam organizações que sabem o que querem, que sabem o que estão procurando. Não exigem, porém usam como critério de seleção. Caso cheguem em uma situação onde dois profissionais possuem a mesma experiência, usam a certificação para escolher. Acho mais justo.  Já as outras organizações, que colocam como obrigação ter uma certificação, já intimidam pessoas que podem possuir larga experiência a se inscreverem no processo. Nesse caso a organização mostra claramente que não sabe nem de longe o que quer e nem onde quer chegar. Vincula a contratação confiando na pessoa que apresentar o maior número de certificações. E como eu já escrevi, nem sempre quem tem uma certificação ou certificações é melhor do que um profissional que não tem nenhuma.

A Renata Eliza, falou um pouco sobre a posição do mercado de Belo Horizonte:

Percebo, pelo menos aqui em Belo Horizonte, que as empresas não têm exigido certificações.

Elas são um “atributo a mais” para o candidato.

Ainda não pude vivenciar uma disputa por uma vaga com um profissional não certificado. Mas acho que tudo é relativo. Se a empresa quer um recém formado que só sabe fazer os testes “que até a minha mãe faria”, por que vai escolher um profissional certificado e consequentemente mais caro?

Agora, se ela quer um teste especializado e já tem algum conhecimento sobre a área… tende a exigir mais.

O Felipe Silva deu sua visão do mercado de Araraguara – Campinas:

Pelo menos na região que eu vivencio (Araraquara – Campinas), não significa muita coisa, e as empresas não usam certificações como fator obrigatório em contratações, em alguns casos nem dão aumento quando alguém se certifica.

O Rodrigo Ribeiro compartilhou a visão da empresa na qual ele trabalha (que por sinal é a mesma na qual eu trabalho rs):

Na empresa em que trabalho venera-se mais profissionais com experiência/retorno profissional/com potencial do que certificados (apenas). Acredito que essa seja a visão correta, mas na maioria das empresas não é assim. Se uma empresa tem em mãos um currículo de um profissional certificado e outro não (mas com larga experiência na área) pode haver algumas variações de escolha, seja para um lado ou outro. Não que seja errado escolher apenas o certificado, mas uma certificação é diferencial numa disputa para vaga de emprego, para mais (certificação + experiência) ou para menos (certificação e pouca experiência).

Aqui em São Paulo, poucas empresas exigem profissionais certificados, mas com certeza é vista com bons olhos, principalmente na entrevista com o responsável pela área. E acredito que o motivo das certificações ainda não serem pedidas pelas empresas, é que há carência de profissionais interessados em atuar na nossa área, então se elas forem exigir profissionais certificados será mais difícil ainda encontrar.

Agora um “certificado”, ou melhor, um conhecimento que pede-se muito aqui em São Paulo: inglês avançado.

O Marcelo Andrade, falou sobre o mercado de Belém:

Aqui em Belém, em que os nichos de TI são bem característicos, ainda pouco se conhece sobre teste de software. De um modo geral, empresas ainda estão em baixos níveis de maturidade. Não ha uma demanda explícita por profissionais especializados em teste de software, o que acaba sendo considerado um “plus”, um diferencial. Entretanto, os grupos de usuários locais são bem fortes e atuantes, desde diversas tecnologias e linguagens de programação, até gerência e práticas ágeis. Acredito que uma cultura esteja se aprimorando e que devemos ter frutos em um curto prazo ou médio prazo.

Uma nova pergunta surgiu durante a discussão (o que é sempre bom), vinda da Renata Eliza: Das certificações hoje no mercado, qual vale mais a pena?

Das certificações hoje no mercado, qual vale mais a pena?

Para o Elias Nogueira as certificações que mais valem a pena são as avançadas do QAI e do ISTQB:

A certificação que hoje mais vale a pena (não puxando a brasa pro meu lado) é a CSTE para os nível intermediário, pois além da experiência  na área como pré-requisito, tu realmente precisa conhecer de teste para responder as questões dissertativas. Tanto que o índice de aprovação é de 17% e temos hoje 61 certificados CSTE no Brasil.
A certificação CTAL (pós CTFL) também é muito interessante, possuindo três ramos distintos de especialização (gerencia, analista, engenheiro), sendo semelhante com a CSTE em vários pontos.

Eu concordo com o Elias. Para passar numa CSTE ou CTAL tem que ser fera. Lembrando que ambas são avançadas, e além de fazer os exames é preciso comprovar experiência.

Outro ponto interessante, que surgiu durante a mesa redonda, foi que é necessário que os processos seletivos sejam melhores preparados, para poderem conseguir extrair se aquele profissional que está sendo avaliado é realmente competente para a vaga em disputa. E para isso a participação de um profissional da área de Teste de Software é essencial. A Sarah, contou uma experiência interessante que passou:

O que eu vivi nesse sentido é que há pessoas que selecionam um profissional de TI sem entender quais conhecimentos o profissional deveria ter para ocupar aquele cargo. Às vezes elas vão pelo padrão: tem que ser pro ativo, autodidata (…). E não entendem que características um profissional deve ter para ser um automatizador, um analista, um testador, um gerente ou um líder técnico.
Uma atitude louvável dai, é pedir que membros técnicos da equipe ajudem a validar os conhecimentos técnicos. Mas esses técnicos, em sua maioria, não estão aptos a entrevistar alguém e identificar competências reais, avaliar reações de um candidato, etc.
Até agora o que achei a melhor opção é a entrevista técnica com a presença também de uma pessoa de RH, acompanhando o comportamental desse candidato durante a entrevista técnica e mais todas as perguntas normais de RH. Alguns técnicos te perguntam:
  • Conhece Mantis?
  • Conhece QTP?
  • Conhece Test Link?
  • Sim? Ok, passou.
Em uma empresa que trabalhei fiz seleção técnica de profissionais, mas antes disso, alem de ser acompanhada por uma pessoa de RH, tive um treinamento sobre competências, o que são, como se desenvolvem, como se expressam, que perguntas permitem que o candidato se venda melhor (e a gente quer que ele se venda mesmo), etc. Em contrapartida, eu e meu colega que fazíamos a seleção, preparamos um workshop pro RH entender quais eram as atividades pertinentes ao time de teste, como esses profissionais de encaixavam na ‘maquina’ da empresa, que características eram importantes, etc.
Bom, no fim o pecado era que o currículo e as certificações contavam igual pro cargo/salário da pessoa. Mas ao menos parte do processo estava no melhor caminho, na minha opinião

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

7º Encontro Mensal da ALATS-SP

Pessoal,

Para encerrar esse excelente ano, o ano em que mais tivemos eventos relacionados a nossa área no país. A ALATS-SP irá realizar, o já tradicional encontro mensal em São Paulo, no dia 2 de dezembro.

O encontro terá a palestra do Marco Aurélio Bassi, Diretor de Consultoria e Vendas do Grupo HDI, que irá palestrar sobreAlta Automação.

As inscrições podem ser feitas até o dia às 19:00h, no próprio site da ALATS-SP.

Segue abaixo, os detalhes do encontro, retirados do site da diretoria de São Paulo da ALATS:

Data: 2 de dezembro (quarta-feira)
Horário: 18:30 – 22:00
Local: Av. Paulista, 726 – Auditório – próximo a estação de metrô Brigadeiro

Objetivo:
Aumentar o contato entre profissionais da área de Teste de Software e Garantia da Qualidade, bem como estimular a troca de conhecimentos, experiências e práticas de sucesso.

Tema do Encontro:
Alta Automação

Conteúdo:
Veja as diferenças entre testes manuais, testes automatizados e testes em alta automação. Conheça uma revolucionária maneira de testar criada por brasileiros e exportada para diversos paises.

Agenda:
18:30 Credenciamento e networking entre os participantes
19:00 Início da palestra
20:00 Coffee break e networking
20:30 Continuação da palestra
21:30 Espaço aberto para discussão de temas da ALATS e da comunidade de Qualidade de Software em geral
22:00 Encerramento

Palestrante:
Marco Aurélio Bassi, graduado, pós-graduado e mestre em Engenharia. 30 anos de experiência em Tecnologia da Informação. 19 anos lecionando em cursos de graduação, pós-graduação e MBAs. 10 anos de atuação na área de Teste de Software. Um dos desenvolvedores do conceito de High Automation Testing. Diretor de Consultoria e Vendas do Grupo HDI.

Inscrições:

– Não Associados: R$ 30,00

– Associados ALATS 15% de desconto

A participação na palestra Vale 3 PDTS para a renovação da CBTS
Reserve pelo e-mail sp@alats.org.br

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

O melhor da semana 15/11 a 21/11

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.

Estimativa de Testes (APT)

O tema da Mesa Redonda DFTestes desta semana foi “Estimativa de Testes (APT)”. A discussão teve o total de 18 respostas e 8 participantes: eu, Felipe Silva, Robson Agapito, Renata Eliza, Carolina Baldisserotto, Sarah Pimentel, Eduardo Gomes e a Daiane Casagrande.

De início parecia que o tema não ia gerar muita discussão, pois poucas pessoas utilizam APT no Brasil, porém no decorrer da discussão o Robson Agapito levantou a pergunta sobre como o pessoal estima o tempo de testes na prática, que acabou gerando boas respostas.

Abaixo, faço um resumo da terceira Mesa Redonda DFTestes, lembrando mais uma vez, que se você se interessou pelo assunto, é altamente recomendável ler toda a discussão. 🙂

Antes de tudo, qual a real importância de estimar algo?

Para o Felipe Silva, a importância de estimar algo é a seguinte:

Poder prever recursos e custos necessários.

O Robson Agapito, afirmou que estimar é algo essencial:

Estimativa hoje é essencial para saber lidar com previsões e cronogramas. Hoje sem uma base histórica fica impossível de se avaliar e estimar em quanto tempo iremos trabalhar em um projeto.

Se não possuímos uma estimativa dificilmente saberemos o quanto já caminhamos no projeto, não saberemos o quanto estamos atrasados ou adiantados e nosso cronograma vai por água abaixo.

Na minha opinião, estimar:

  • É uma atividade que pode ajudar muito no planejamento, gerenciamento e controle dos projetos. Mas é bom ter consciência que estimar não é adivinhar o futuro;
  • Antes de estimar, precisamos saber porque estamos estimando algo, e o que iremos fazer com as informações obtidas, pois precisamos usá-las para melhorar o nosso processo e não como forma de cobrança de profissionais, ou porque todos mundo fala que estimar é importante.

Para a Renata Eliza, planejar sem estimar, é algo impraticável:

Uma coisa é fato, é impossível planejar sem estimar.

“Você não pode controlar o que não pode medir”, isso ainda é uma verdade na empresa de vocês?

O Felipe Silva, disse que:

Sim, mas aqui no final (nível gerencial) tudo acaba deixando de ser número e vira cor (verde, amarelo, vermelho).

Para a Renata Eliza, quando se medi, a probabilidade de falhar é menor:

Sem sombra de dúvidas. Quando se baseia no “achismo” a probabilidade de falhar é imensamente maior.

Na minha opinião, não acredito que não é possível controlar algo sem medir, ou melhor, não acredito que para controlar sempre precisamos medir. Como o próprio autor da frase (Tom DeMarco), disse recentemente: […] a idéia de que controle seja talvez o mais importante aspecto de um projeto de software. Mas não é. Muitos projetos foram realizados quase sem controle e produziram produtos maravilhosos, como o Google Earth ou o Wikipedia.” (tradução do José Papo). Medir é apenas uma das forma de controlar, adoramos números, tanto que há as mais variadas estatísticas hoje em dia. Porém, não é uma tarefa tão simples, e nem sempre a mais importante para uma determinada realidade.

Quais são as maiores dificuldades de implantar APT?

O Robson Agapito, compartilhou uma experiência vivida ao tentar adaptar a APT:

Sobre o APT alguns dos grandes nomes de testes de software falam que não é utopia e que é possível implantar o mesmo. Eu ainda não consegui, criei um mini APT focado para a empresa, e mesmo assim não consigo ainda medir a quantidade de tempo, pois como precisamos de uma maior agilidade tivemos que redirecionar a quantidade de horas pela complexidade do requisito a ser testado, onde o analista de teste verifica a estimativa de um histórico e realiza um ajuste se necessário.

Eu vejo as seguintes dificuldades:

  • Eu nunca usei APT, então não posso falar muito. Mas acho que as maiores dificuldades envolvem a empresa e as pessoas do projeto, todos precisam está alinhados, e cientes da importância da sua implantação;
  • Documentação é um problema em muitos projetos, e fazer uma estimação em cima de uma documentação desatualizada ou pouco consistente, é uma perda de tempo;
  • A expectativa, muitos acham que estimativas são verdades absolutas, quando na verdade não são, são apenas estimativas, e precisam está sempre sendo atualizadas;
  • Vivemos num mundo imediatista (tudo é pra ontem), e todos esperam que usando o APT os resultados apareçam logo, porém isso é muito difícil de acontecer, para não dizer impossível. Uma prática fundamental, quando se usa APT, é ajustar-la, e o ajuste só pode ser feito com o passar do tempo;
  • Estimar algo que envolve pessoas, é quase o mesmo que prever o tempo, ou querer saber quanto estará o dólar daqui há 4 meses. Portanto estimar por si só, é uma tarefa bem difícil.

Quais as vantagens de usar APT? O custo-benefício vale a pena?

O Felipe Silva prefere a estimativa com base em histórico:

Pessoalmente não gosto da APT, e acho que é mais um chute do que um cálculo real, prefiro análise com base em histórico, é mais calibrado e funcional.

Na minha opinião, deixando claro que nunca apliquei APT:

  • Mais uma vez, só posso responder com base de informações teóricas. No segundo encontro da ALATS-SP (slides), deu para perceber que na empresa da Cristiane eles levam a sério estimativas, e elas já são usadas há um bom tempo, e desta forma, conseguiram construir uma boa base histórica. Com certeza tal base é uma fonte que fornece um bom diferencial e aumenta a eficiência no gerenciamento, planejamento e controle dos processo/projeto de Teste de Software;
  • O maior benefício, é que paramos de usar o “achômetro” e passamos a usar informações do nosso histórico.

O que eu necessito para poder utilizar APT?

Segundo o livro Base de conhecimento em teste de software é necessário saber:

  • O tamanho do sistema em pontos de função (APF);
  • A complexidade do processo de teste;
  • O nível de qualidade que se pretende alcançar com os testes;
  • O grau de envolvimento dos usuários com os testes;
  • As interfaces que as funções testadas têm com os arquivos;
  • A qualidade do sistema testado (o ciclo de reincidência de defeitos);
  • O nível de cobertura esperado com os testes;
  • A experiência e a produtividade da equipe de teste (por meio de indicadores históricos);
  • O grau de automação dos testes;
  • A qualidade do ambiente de teste, até mesmo sua capacidade de simular o ambiente de produção;
  • A qualidade da documentação do sistema e, em especial, dos requisitos.

Quando usar e quando não usar APT?

Os seguintes momentos foram citados pelo Felipe Silva:

Quando usar: quando ainda não tiver nenhuma forma efetiva de medir, quando esta análise te gerar algum benefício, quando decisões realmente forem tomadas com base na APT (nível gerencial). Quando não usar: Oposto de tudo que eu disse no “quando usar”.

O Robson Agapito lembrou que muitos profissionais acreditam que a APT é só para projetos grandes:

A utilização do APT ou de qualquer outra estimativa é essencial, isto é fato, mas creio que para projetos fechados a utilização do APT é mais produtiva do que para projetos de manutenção de um software. Muitos dizem também que o APT é para projetos grandes, pois o PF inicial para se utilizar o APT é de 500 PF ( o que equivale para muitas empresas em mais de 2000 horas no projeto) e não é qualquer projeto que tem este tamanho.

Na minha opinião:

  • Sim
    • Quando você tiver a real necessidade, quando o custo-benefício realmente compensar;
    • Quando o seu ambiente permitir;
    • Quando a empresa tiver maturidade suficiente para entender e implantar-la.
  • Não
    • Tudo que disse para o “Sim” ao contrário.

Quais são as lições aprendidas que vocês tiveram sobre estimar testes?

O Felipe Silva compartilhou as seguintes lições aprendidas:

Não estimamos com APT. Ajuda na alocação de recursos entre as equipes (dentro do mesmo projeto), é possível saber o quanto se pode implementar para que nós consigamos testar à tempo (aqui é feito duas estimativas: de implementação e de testes, existe uma lista de negócios desejáveis à entrar na build, tudo que for possível de implementar e testar em tempo hábil entra na build), poderia ajudar estimar custo do projeto para o cliente.

As seguintes lições aprendidas eu tirei até o momento:

  • Estimar testes não é fácil 😦 (se fosse todo mundo faria) 🙂
  • Precisamos estimar com as ferramentas que o nosso ambiente nos dá;
  • Mais uma vez, adaptação é essencial;
  • Quando não temos uma base histórica, o melhor a ser fazer é entender bem sobre o sistema sob teste e Teste de Software, e aí gerar as estimativas das pessoas. Como por exemplo, usando planning poker;
  • O que não podemos fazer, é ficar usando técnicas derivadas do “achômetro”, como por exemplo: “estimativa do dedo”,  “veja bem”, “se” e famoso Cálculo Hipotético Universal Técnico Estimativo (vulgo C.H.U.T.E).

Como vocês estimam na prática o tempo de testes?

O Felipe Silva pratica da seguinte maneira:

Base histórica (conhecimento), e também faço um cálculo bem simples, quantidade de TCs * complexidade da funcionalidade sob teste.

Na empresa do Robson Agapito eles fazem o seguinte:

Aqui fazemos o seguinte, temos divididos os requisitos por tipo, e temos hoje 4 tipos. Como é um ERP possuímos vários sistemas.

Nesse caso criamos as categorias:

SISTEMA 1

TIPO 1

TIPO 2

TIPO 3

TIPO 4

SISTEMA 2

TIPO 1

TIPO 2

TIPO 3

TIPO 4

SISTEMA 3

TIPO 1

TIPO 2

TIPO 3

TIPO 4

Então pegamos o tempo histórico dos último 4 meses de um requisito de determinado Tipo e de um sistema específico e calculamos a média. Após isso há o ajuste do analista de teste, que pode opinar e trocar para mais ou para menos o tempo histórico através do seu conhecimento no Sistema/Tipo.

A Carolina Baldisserotto compartilhou algumas experiências vividas com estimativas:

Na empresa anterior eu trabalhava em um projeto de manutenção de software com ciclos pequenos, e em cada ciclo tínhamos alguns requisitos e não ia dar tempo para testar todos, por isso tínhamos que escolher quais iriam ser testados pela equipe de teste e quais apenas o desenvolvedor ia testar.
Então a gente fazia assim:
Duas pessoas de teste estimavam o tempo de cada requisito (cada pessoa fazia a sua estimativa), de acordo com sua experiência, daí a gente tirava a média dos tempos dos dois analistas. Se o tempo estivesse muito diferente, a gente sentava pra ver o porquê da diferença.
Depois a gente classificava os requisitos de acordo com a criticidade (pouco crítico, crítico e muito crítico), então analisávamos os requisitos de acordo com o tempo que o teste ia levar e a criticidade dele, daí então escolhíamos quais a equipes de teste ia testar e quais não.

E na empresa que trabalho hoje, a estimativa do tempo é feita de acordo com a experiência de cada um mesmo.

A Sarah Pimentel, lembrou do método Delphi, que é utilizado em várias áreas:

Nenhum projeto que trabalhei empregou o APT para fazer estimativas. Quando participei de projetos com estimativas formais usávamos Delphi, que não é uma técnica de chute 🙂 Existe uma organização de papeis e fases.

O Eduardo Gomes relatou a sua jornada em estimativas de teste:

Há mais ou menos 1 ano estamos buscando formas de estimar o esforço dos projetos de teste associados aos nossos projetos de desenvolvimento.

Definimos pela utilização em paralelo de algumas técnicas de estimativa, buscando trabalhar com valores médios entre elas para efeito de previsão de esforço de cada projeto, tentando minimizar os efeitos dos desvios de alguma delas.

Escolhemos a APT e também um modelo baseado no tamanho e complexidade dos casos de uso. Partimos do material da CBTS para início da pesquisa e procuramos adaptar os modelos à nossa realidade.

Além dessas estimativas, utilizamos também uma estimativa baseada na experiência dos profissionais. Chute??? Cabe aqui uma ressalva: o sucesso do “chute” depende muito de quem chuta, mas não devemos desconsiderá-lo, pois o mundo é repleto de subjetividade, e o ser humano tem uma capacidade única de análise e de intuição, que pode complementar, ou mesmo, em determinadas situações, ser mais importante que fórmulas complexas ou modelos elaborados.

O fato é que tudo isso não tem muito valor se não se constroem bases históricas. Só será possível comprovar a efetividade das estimativas quando tivermos bases históricas que contribuam para os ajustes necessários nos modelos e para a utilização com maior segurança dos resultados das estimativas. Antes disso, continua sendo chute. Mas talvez um chute “calibrado”; é um ponto de partida pelo qual temos que passar.

Os resultados já começam a aparecer, tanto no melhor gerenciamento dos projetos, através da construção de cronogramas mais precisos e melhor utilização dos recursos, como pelo fomento a uma mudança cultural dentro da organização. Fica cada vez mais claro para todos os níveis organizacionais, que o esforço de teste não é o que sobra; pelo contrário, é parte significativa do esforço total dos projetos e fundamental para o sucesso dos mesmos.

Conclusões

Desta vez, acredito que deixar de forma explícita as conclusões da Mesa Redonda, se faz necessário, portanto segue abaixo, as conclusões que tive ao ler a discussão:

  • Análise de Ponto de Teste (APT) é pouco usada no Brasil;
  • Na minha opinião, o fato acima não deve ser encarado como algo ruim (ex. “estamos sempre atrás do resto do mundo mesmo”). Não vejo a menor necessidade de usar algo, só porque lá fora é muito usado. Lá fora a realidade é diferente, portanto muitas vezes temos que utilizar técnicas diferentes. Não podemos nos achar inferiores ou menos competentes, por não conseguir implantar a APT, e sim procurar outras soluções, usar o que temos de melhor e diferencial, a nossa criatividade;
  • A base histórica é fundamental para qualquer técnica de estimativa, até para quem usa o Cálculo Hipotético Universal Técnico Estimativo, pois o CHUTE depende de quem está chutando, e o que diferencia o profissional do CHUTE de um amador, é que o primeiro tem uma base histórica, arquivada na memória, mais conhecida como experiência;
  • Não há desculpas para não construir uma base histórica, é a melhor forma de fazer isso é documentando, afinal estimar não é uma tarefa solo, e sim de todo o time. E mesmo nos casos em que as estimativas dependem exclusivamente de você, armazenar a sua experiência em um local não volátil, é muito melhor (essa foi bem nerd rs);
  • Estimar é necessário, ponto. Técnicas existem, é uma verdade. Não há fórmulas mágicas, não é possível fazer copy paste de uma técnica e querer que ela funcione perfeitamente na sua empresa, portanto adaptar uma técnica é fundamental, ou melhor, calibrar;
  • Se uma tarefa for muito grande, então quebre-a! Simples assim, pois estimar tarefas menores é muito mais fácil e os resultados muito mais precisos;
  • Estimar envolve pessoas, elas que devem ser o termômetro das nossas estimativas. E pensando nisso, técnicas utilizadas em times ágeis, como o planning poker e pomodoro, podem aumentar a precisão das estimativas, e tornar natural a tarefa de estimar e uma tarefa do time, não de um único indivíduo.

Bem é isso pessoal, a quarta Mesa Redonda vem aí, e para participar é muito simples é só se inscrever no DFTestes. 😉

E fiquem de olho na discussão, pois podem haver novas respostas, após a data desse resumo, como houve na discussão passada sobre Testes Ágeis, onde o Jorge Diz, fez importantes considerações e explicações.

Até mais!

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

P.S.: Esse post foi feito com 5 tomates, utilizando o focus booster para controlar o tempo. 😉

O melhor da semana 08/11 a 14/11

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.

Teste Ágil, como implementar?

A segunda Mesa Redonda DFTestes teve 10 participantes: eu, Wagner Duarte Júnior, Felipe Silva, Cibele, Elias Nogueira, Ralph Montelo, Marcelo Andrade, Aderson Bastos (um dos autores do livro Base de Conhecimento em Teste de Software), Robson Agapito e o José Correia.

Como puderam notar, grandes nomes da comunidade brasileira de Teste e Qualidade de Software participaram da Mesa Redonda, e todos com o mesmo objetivo, discutir sobre “Teste Ágil, como implementar?”. 😀

Vamos então para o resumo dessa discussão que teve 17 respostas.

A discussão teve um desafio a mais dessa vez, pois o tema é bem recente, tanto que há apenas um livro focado nele, o Agile Testing da Lisa Crispin e Janet Gregory. E o no Brasil há pouquíssimo material sobre o assunto. Então, acredito que o grande objetivo da discussão foi tentar desmitificar um pouco o que é Teste Ágil e como podemos implementá-lo na nossa empresa, não trazendo fórmulas mágicas ou receitas de bolo (até porque isso não existe em projetos de software), e sim experiências vivenciadas pela comunidade e conhecimentos adquiridos, que possam orientar como dar os primeiros para a agilidade no Teste de Software.

Afinal o que é Teste Ágil?

Como de praxe em uma discussão sobre agilidade, é bom apresentar os princípios ágeis do Manifesto Ágil, que também norteiam o Teste Ágil:

  • Indivíduos e interação entre eles mais que processos e ferramentas;
  • Software em funcionamento mais que documentação abrangente;
  • Colaboração com o cliente mais que negociação de contratos;
  • Responder a mudanças mais que seguir um plano.

Lembrando que os itens da esquerda são mais valorizados do que os da direita, mas isso não que dizer que os da direita sejam ignorados.

O Wagner apresentou de forma muito clara o que se espera quando dizemos que algo é ágil:

Sou um grande apreciador da qualidade. Por isso, acredito que tenhamos realmente que tornar o nosso trabalho cada vez mais ágil, porém, não podemos nos esquecer da qualidade, que é o forte da nossa área.  Vejo então, que devemos unir com sabedoria, essas duas vertentes. Um processo relativamente simples, que possa ser executado com grande facilidade e agilidade, cobrindo o maior número de riscos, com uma qualidade que seja apreciada e valorizada pelo usuário final. Um processo sem muitas “firulas” e com a qualidade esperada pelo cliente ou ainda, superando as expectativas do mesmo.

Na minha opinião, Teste Ágil é um conjunto de práticas que proporcionam a diminuição do tempo entre o erro e a sua descoberta, baseada no contexto ágil e nos princípios do manifesto ágil.

Para o Elias Nogueira Teste Ágil:

  • É uma abordagem de teste que está aderente ás práticas de agilidade descritas no manifesto ágil;
  • É a área de teste sendo mais pró-ativa do que reativa;
  • É integrar/relacionar os testes as metodologias de desenvolvimento ágil (TDD, XP, FDD, BDD, etc…).

O que muda do Teste Tradicional para o Teste Ágil?

As considerações feitas pelo Elias Nogueira deixaram claro que o Testador passa a ser um profissional muito mais dinâmico:

  • Testadores serão mais pró-ativos, tendo participação direta com o cliente;
  • Testadores terão um foco mais técnico, pois estarão trabalhando como par de desenvolvedores;
  • Testadores precisam saber automatizar, para poder manter o ciclo de entrega dos testes sempre no mesmo tempo/sprint.

Para mim as mudanças são as seguintes:

  • Acredito que a principal mudança é em como você exerce o seu papel, as técnicas a serem utilizadas para a criação dos testes e todas as outras teorias provenientes, podem te auxiliar a entender e exercer melhor as suas tarefas de uma forma mais ágil e efetiva;
  • O que vejo que muda muito, é que os desenvolvedores também testam, e testam pra valer, tanto que devem haver mais testes de unidade e integração do que testes de sistema e aceitação;
  • O Teste de Software se torna mais preventivo, práticas como o TDD e a Programação em Par, contribuem para melhorar a qualidade do software que está sendo desenvolvido, e evitar a inserção de erros;
  • O time de teste não precisará focar nos testes que validam se o sistema está sendo de acordo com o cliente solicitou, e não se preocupam em cobrir verificações básicas, como cobertura de desvios;
  • A automação é essencial para o Teste Ágil, é o ingrediente que fará o teste ser realmente ágil;
  • Os testes manuais existem, mas são mais para os tipos de testes que realmente não tem como automatizar, como por exemplo: usabilidade;
  • O time de teste passa a participar de forma mais efetiva e integrada com o time de desenvolvimento, não espaço para rivalidade, pois ambos trabalham focando o mesmo objetivo, entregar um produto com qualidade;
  • Os testes tornam-se rotina, não é mais uma tarefa feita só no final do desenvolvimento do software.

Como podemos implementar o Teste Ágil no nosso dia-a-dia?

O Aderson Bastos vez uma interessante consideração sobre Teste Ágil em metodologias não ágeis:

É possível testar de forma ágil com qualquer tipo de metodologia de desenvolvimento, obviamente algumas metodologias privilegiam este tipo de abordagem. RUP, XP, Scrum, FDD, etc, são ótimas referências para elaborarmos uma boa metodologia, mas nenhuma delas garantirá agilidade. Não somos ágeis porque utilizamos Scrum e/ou XP, por exemplo, – lembrem-se do manifesto ágil: “indivíduos e interações mais que processos e ferramentas”!!! – somos ágeis porque pensamos e agimos assim; porque quando somos eficazes no uso de todo o conhecimento (técnicas, boas práticas…) que temos.

A Cibele listou importantes fatores que nos ajudam a saber se a implementação de uma metodologia ágil será uma boa ou não:

  1. Onde será aplicada;
  2. Tipo da empresa;
  3. Maturidade de processos e dos profissionais;
  4. Cliente;
  5. Time;
  6. Tipo de sistema a ser desenvolvido e várias outras coisas.

E a Cibele ainda fez importantes considerações, sobre a implementação de metodologias ágeis e Teste Ágil, com base em experiências vivenciadas:

Não basta só implantar o processo ágil, é preciso checar se há ambiente propício para isso. E mais importante, começar devagar, pegar um projeto pequeno como piloto e ter pessoas na equipe que conheçam o processo muito bem. Fica mais fácil de analisar a evolução e corrigir erros.

Não há uma receita de bolo a seguir. É preciso conhecer o processo ágil muito bem, assim como a cultura da empresa e a maturidade dos seus colaboradores e em cima disso, montar uma estratégia de implantação do processo ágil. Pelo que presenciei nesta empresa, o teste ágil está dentro do processo ágil. Mas é possível adotar práticas ágeis em testes em qualquer tipo de processo ou metodologia.

O Elias Nogueira fez as seguintes sugestões para a implementação do Teste Ágil:

  • Trazendo o cliente para perto e fazendo com que ele entenda as atividades de teste e que ele entenda que ele mesmo é o principal fator de sucesso;
  • Alterar nossa Cultura Organizacional (todos devem ser ágeis, da tia do café ao presidente da empresa);
  • Manter a equipe atualiza e ter feedbacks constantes para todos os stakeholders;
  • Estudar e implantar mais testes caixa-branca junto aos desenvolvedores;
  • Prover formas automatizadas para a execução de testes em todos os níveis.

O Robson Agapito relatou como ele está começando a implantar Teste Ágil:

O primeiro passo que estamos trabalhando é treinar a equipe de desenvolvimento para estar aptos a realizar testes unitários, após isso implantado e assimilado por toda a equipe creio que será mais fácil de mudar a metodologia para alguns projetos.

Para o José Correia:

O ideal é convencer sua organização a fazer um piloto e a partir dessa experiência ir aperfeiçoando. A primeira vez não vai ser incrível. Não existem metodologias mágicas, é necessário aprender com erros e acertos, acreditar, medir, ajustar e comprovar progressivamente os ganhos.

Na minha opinião, precisamos implementá-lo de uma forma incremental, e de preferência iniciando com os testes no desenvolvimento do software:

  • Antes de tudo, é preciso estudar e entender o motivo pelo qual o Teste Ágil existe;
  • Implantar de forma gradativa;
  • Antes de criar um teste, pensar se ele pode ser automatizado, e se vale a pena automatizá-lo;
  • Lembre-se que o Teste Ágil, causa uma inversão na pirâmide dos testes, ou seja, ao invés de temos muitos testes de sistema e aceitação, teremos mais testes de unidade e integração. Então, e a responsabilidade da criação de tais testes é em primária instância do desenvolvedor;
  • Atue perto do cliente, afinal você deverá ter pleno conhecimento sobre o que ele está esperando do sistema;
  • Querer criar testes de unidade e integração para sistemas legados, é quase impraticável, porém para as novas funcionalidades e manutenções, por que não criar?

Quais são as maiores dificuldades para implementar-lo?

Segundo o José Correia o mercado ainda tem resistência em experimentar as metodologias ágeis:

Nos projetos  que acompanho, o uso de práticas ágeis é elegível apenas quando o número de horas totais do projeto é inferior a 1000 horas. Alguns clientes são mais conservadores e estabelecem um teto de 640 à 800 horas. Projetos acima são tocados dentro das práticas do RUP, modelos CMMI/MPS.br e os testes complementados com base no Syllabus/ISTQB, CBOK/QAI, normas ISO e IEEE.

Algumas empresas que antigamente diziam usar “metodologia própria” para disfarçar a falta de um forma de trabalho estruturada, agora passaram a dizer que são “Ágeis” o que é péssimo para as empresas que realmente utilizam as práticas e fazem um trabalho sério. Ou seja, muitas empresas de grande porte, como diversos Bancos têm grandes restrições por experiências ruins com alguns desses fornecedores.

Para o Elias Nogueira podemos enfrentar as seguintes dificuldades:

  • Cultura organizacional resistente;
  • Equipe não multidisciplinar;
  • Cliente não é ou não gosta de ser ágil;
  • Conhecer agilidade e os conceitos no Manifesto Ágil;
  • Participar reativamente como área de teste (esperar todos os documentos na mão).

Eu vejo que as maiores dificuldades, tem relação as pessoas, até porque Teste Ágil antes de tudo, é uma questão de atitude:

  • É uma mudança de cultura, então costuma haver uma grande resistência;
  • O time de teste é forçado cada vez mais a está pesquisando sobre novas ferramentas e saber programar, pois como disse antes, a automação é essencial;
  • A mudança também afeta o cliente, ele também deverá ser tornar mais participativo e comprometido com o sucesso do sistema, e passar para o time de desenvolvimento as suas reais necessidades e opiniões do sistema.

Quais as vantagens de sua implementação?

Podemos obter diversas melhorias com a implementação do Teste Ágil, não apenas no processo, mas como também na motivação das pessoas:

  • O número de bugs a ser encontrados pelo time de teste tende a ser bem menor, principalmente devido ao fato do grande foco na prevenção dos mesmos;
  • O desenvolvimento do software torna-se sustentável, se for necessário fazer alguma mudança, os desenvolvedores não terão receio, pois poderão executar uma bateria de testes unitários para verificar se a mudança não quebrou nada;
  • As entregas passam a ser mais rápidas;
  • A participação do cliente de forma mais efetiva, faz com que o software tenha aquilo que realmente o cliente deseja;
  • A automação torna a execução do testes mais rápida, ou seja, passar a ser mais econômica;
  • O retrabalho e manutenção será muito menor, fazendo com o que o custo e o tempo para o desenvolvimento seja menor.

O Elias Nogueira levantou as seguintes vantagens:

  • Maior velocidade na execução do projeto
  • Maior rapidez no conhecimento do projeto
  • Entregas mais focadas na necessidade do cliente
  • Cliente se sentirá feliz e realizado em ver como estão as atividades e saber realmente o que será entregue
  • Maior disseminação de conhecimento técnico e de negócio para a equipe

Durante a Mesa Redonda surgiu uma boa discussão, iniciada após o Ralph Montelo compartilhar as seguintes opiniões:

Sinceramente? “Teste Ágil” são duas palavras que (infelizmente!) não combinam. Mesma coisa que dizer “Inteligência Militar”. (!)

Métodos ágeis são ótimos quando o assunto é economia e agilidade na entrega. Quanto à qualidade, prefiro não comentar. Não consigo confiar 100% em uma metodologia que preza a “não-documentação”, pois continuo seguindo minha carreira utilizando a Regra 10 de Myers à risca. E não me arrependi em momento algum.

Em resposta o Wagner disse:

Vejo que o tempo tem se tornado cada vez mais curto, por isso põem-se interessante a idéia de agilidade com qualidade. Pois a partir do momento em que o foco se torna apenas a “agilidade”, não estamos mais falando de “Teste e Qualidade de Software”.

Temos que realmente unir o “útil (qualidade) ao necessário (agilidade)”.

E o Marcelo Andrade lembrou que ser ágil é buscar fazer direito na primeira vez e produzir documentação efetiva e útil:

Ágil combina menos com “pressa” e mais para fazer direito. (Da fábula da
lebre e a tartaruga, sem dúvida, o animal que melhor representa técnicas ágeis
é… a tartaruga). Se alguém acha que desenvolver de forma ágil é fazer com
pressa, com certeza não está fazendo ágil da forma correta.

É falso dizer que métodos ágeis prezam a “não-documentação”. O mito da
documentação é algo que incrivelmente as pessoas não entendem no manifesto
ágil. Ao contrário, se preza muito toda a documentação que seja efetiva e útil.
A propósito, artefatos de testes estão entre os melhores tipos de documentação
que existem. Sugiro a leitura deste artigo:

http://www.infoq.com/br/news/2009/08/agile-documentation

Pra fechar o resumo com chave de ouro, nada melhor, do que apresentar as 7 práticas para tornar o Teste de Software ágil, que nada mais são do que soluções de um profissional que buscou a melhoria contínua e agilidade, não porque está na moda, e sim porque tornaria o seu trabalho mais efetivo, todos os créditos ao Felipe Silva, que compartilhou as seguintes práticas:

  1. Planejar uma sequência de testes a serem executados de forma que em um único fluxo se consiga validar o máximo de cenários possíveis, chamamos isto de “Overlap”, pois unimos o que seria mais de um Test Case em apenas um Test Case contendo os steps de todos;
  2. Automatizar ou simplificar rotinas, por exemplo criando não apenas scripts para testes, mas também scripts, macros e programas que façam coisas que você faria manualmente;
  3. Ter Casos de Testes claros e diretos, se sua equipe de testes não é formada por “um monte de mães” (como na discussão passada) pode-se pensar em escrever Casos de Testes que vão direto ao ponto, o step de validação e nada mais,;
  4. Gerenciar manobras de riscos, para caso o test A pare, então o B já esteja na lista para ser executado, assim não tendo impacto no prazo do delivery e enquanto estiver testando B já estar providenciando a solução para que o A volte a ser testado;
  5. Trabalhar em equipe e tirar uns 20 a 30 minutos para discutir um requisito entre os envolvidos do testes economiza horas de pessoas que tem medo ou vergonha de se expor dizendo que não entenderam ou não sabem e assim sendo sem perceber atrasam a entrega e correm o risco de não fazer um teste com qualidade;
  6. Suporte do cliente é fundamental, na nossa equipe hoje temos uma pessoa alocada no cliente que faz o papel de gerente de testes e revisor de requisitos ao mesmo tempo, esta pessoa é a ponte inicial para todas as dúvidas e quase sempre tem todas as respostas que teriam que sair direto do cliente, é um profissional de testes (modelo indiano de gerencia);
  7. Tornar os profissionais especialistas em partes do projeto, de modo que todo mundo saiba um pouco do projeto como um todo e você sempre terá 1 especialista em qualquer assunto do projeto, tendo assim na soma dos profissionais uma equipe especialista, as vezes sabendo mais que o próprio cliente do assunto, entendimento rápido do negócio gera processos ágeis para o teste, seja na criação ou na execução dos testes.

Se interessou pelo assunto, então confira a discussão na íntegra, acessando o DFTestes. E se quiser participar das próximas Mesas Redondas, é só fazer a sua inscrição no grupo.

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