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.

O melhor da semana 01/11 a 07/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.

Testar é tão fácil, que até a minha mãe testaria!

Na semana passada começou a primeira Mesa Redonda DFTestes, com o tema “Testar é tão fácil, que até a minha mãe testaria!”. A discussão teve o total de 19 participantes, que fizeram bonito dando as suas opiniões e compartilhando experiências,  gerando 26 respostas e tornando a discussão bem produtiva.

Os participantes foram: Robson Agapito, Simon Rodrigues, Sarah Pimentel, Ronaldo Cruz, Renata Eliza, Ricardo Franco, Felipe Silva, Ricardo Franco Custodio, Camilo Ribeiro, Maria Meire Gomes, Rita Lima, Michel Mendoza, Carolina Baldisserotto, Emerson Gomes da Silva, Ueslei Aquino da Silva, Edwagney Luz, Andrea Cruz, Rodrigo Almeida de Oliveira e eu também. 🙂

O intuito desse post é fazer uma compilação da discussão, espero que gostem.

A discussão teve como tema “Testar é tão fácil, que até a minha mãe testaria!”, e foi feita em torno das seguintes perguntas:

  • Esse é um mito ou verdade?
  • Como surgiu esse mito?
  • Por que ainda hoje, há muitas pessoas que tem essa opinião?
  • O que podemos fazer para acabar com esse mito?
  • A área de Teste de Software sofre preconceitos?

Para o Robson Agapito um dos motivos é a pouca disseminação do conhecimento sobre Teste de Software, principalmente devido a inexistência dessa matéria na maioria das faculdades do Brasil:

[…] este mito ocorre principalmente por falta de conhecimento de muitas pessoas da área de TI. Então se começarmos a divulgar mais sobre testes de software pode ajudar muito a não terem esta visão.

Uma situação que era extremamente importante para ter um reconhecimento grande durante os próximos anos seria a inserção inicial de uma matéria sobre testes de software nas universidades, e quem sabe um curso na graduação sobre testes de software.

A Renata Eliza lembrou que podemos ajudar a conscientizar os nossos colegas de trabalho, sobre o que de fato é testar:

É um trabalho árduo, mas que não é impossível.  A falta de conhecimento faz com que as pessoas de um modo geral pensem dessa maneira extremamente equivocada.  Se conseguirmos conscientizar a empresa onde estamos hoje e os colegas da área de TI (extra-empresa) que nos cercam, já vai ser um ganho incrível.

Para mim, há ainda muitas pessoas que acreditam que Teste de Software, só tem uma fase, a da execução, e que só fazem testes exploratórios de forma manual. E isso é fruto da ignorância dessas pessoas em relação ao Teste de Software.

A respeito da aparente facilidade de testar um software, tivemos diversas opiniões, complementares:

Para o Simon:

(Testar) Não é tão fácil assim, o profissional de teste de software tem uma visão diferente das demais pessoas da organização, sendo especializado em testar o software através de algumas técnicas.

Já para a Sarah Pimentel:

Se pensarmos que um caso de teste manual deve estar tão bem descrito que qualquer pessoa possa executá-lo, para o TESTADOR, na minha opinião, isso se torna verdade. Mas não é sempre assim, muitas vezes exige um certo conhecimento da parte do testador. E além disso, para chegar nesse resultado de escrever o caso de teste correto e dessa maneira, há várias outras implicações.

E a Sarah ainda concluiu que:

  • Considerando os baixos critérios de admissão das empresas, e a facilidade em chamar “qualquer coisa” de testes: Sim, testar é tão fácil que até a minha mãe testaria (e melhor que muita gente por ai).
  • Considerando um mundo ao menos próximo do ideal: Não! Testar exige conhecimento, preparo e experiência.

O Ronaldo Cruz alertou que tal afirmação é perigosa:

Dizer que “testar é tão fácil que minha mãe testaria” é algo perigoso de se dizer, porque exige um mínimo de conhecimento de negócio ou do ambiente em que se testa, caso contrário, você vai apenas mascarar a atividade, sendo que nem o básico realmente é validado, e o risco de se ter a imagem da empresa arranhada por entregar produtos mal feitos e sem qualidade pode ser irreparável.

O Ricardo Franco, fez uma boa analogia, mostrando que há pessoas que falam que testar é fácil, mas nem se quer sabem o que é testar:

Pra mim, isso aí é igual àquela estória da beterraba:
– Você gosta de beterraba?
– Não.
– Você já comeu beterraba?
– Não.
– Então porque você diz que não gosta se não sabe nem o sabor?
– Porque as pessoas dizem que é ruim.

O Felipe Silva apresentou o cenário da área de Teste de Software na IBM, para ilustrar o quanto é errôneo pensar que testar é uma simples tarefa e que qualquer um pode executar:

Só a título de curiosidade a empresa mundialmente conhecida IBM conta com um departamento chamado GTO (Global Test Organization), departamento este que hoje emprega mais de 7000 funcionários só no Brasil e movimenta a maior parte do faturamento da empresa no Brasil.

Quem pensa que teste não leva à nada ou é gerente e pensa que teste é apenas custo… acho que deveria rever seus conceitos.

Na minha opinião, a dificuldade de testar depende do sistema sob teste, só que o mesmo também baliza a dificuldade das outras atividades do desenvolvimento de software (ex. arquitetura, análise, programação, etc). E de acordo com a complexidade e tecnologias utilizadas no desenvolvimento de um sistema, o Teste de Software pode se tornar extremamente difícil.

Outro motivo citado na discussão, que ajudou a fortalecer esse mito, é a respeito da competência e preparo de alguns profissionais que atuam na área.

A Sarah, apresentou a seguinte realidade:

O que ocorre é que há muitas pessoas sem preparo no mercado. Nada contra iniciantes, eu obviamente um dia fui uma, mas há pessoas que iniciam na área de testes na seguinte sequência: Faz vestibular pra um monte de coisa, não passa, arruma uma faculdade genérica qualquer pra fazer um curso qualquer (leia-se informática) – isso quando faz uma faculdade-, não gosta de programar, não se dá bem com processo, com arquitetura, com redes, etc, resolve que vai ‘fazer testes’. Não se aprimora, não busca conhecimento, e continua por ai sendo um profissional no mercado.

Culpa também das empresas que muitas vezes preferem os mais baratos em detrimento dos que estão melhor preparados.
O Camilo Ribeiro, compartilhou a sua opinião de que há:

Profissionais que realizam testes “exploratórios” e nada mais não são testadores. Esses testes “exploratórios” são o que nos enfraquecem, fazem nosso trabalho parecer simples e como disse nosso amigo Fabrício, o teste passa a ter uma única fase, a execução “porca”.

Muita gente acha que só fazemos esses testes “meia boca”, e isso em grande parte por culpa dos que se dizem analistas de teste e na verdade acabam por mostrarem-se amadores ou pessoas sem capacidade técnica e organizacional para medir a eficiência do próprio trabalho.

O Emerson Gomes compartilhou algumas experiências vivenciadas:

Creio que também a existência de maus profissionais, tanto fora quanto dentro da área de testes pode trazer tal impressão.

[…] um profissional que está na área, mais com muito pouco conhecimento técnico…como eu também já presenciei…como um testador que não tinha quaisquer conhecimentos de SQL, sequer para executar uma consulta…. A presença dele na equipe, fazia outras pessoas utilizarem essa velha máxima de que “Até minha mãe testaria”, pois a pessoa citada tinha poucos conhecimentos técnicos, e apenas fazia testes funcionais, baseando-se nas regras de negócio, mais sem o poder de conseguir verificar casos como uma transação que leva dados a um software legado, ou se um simples cadastro está sendo feito da maneira correta na sua base de dados.

Sobre o que podemos fazer para acabar com esse mito, houveram boas sugestões, como a do Ronaldo Cruz:

O que podemos fazer para mudar essa mentalidade é justamente fazer os envolvidos terem conhecimento das nossa atividades, como ela funciona, a importância da mesma, cases de projetos com e sem qualidade, o valor agregado. No meu caso, o pessoal começou a dar valor e exigir o meu trabalho dentro da equipe depois que eles conheceram as minhas atividades, o quão complexo elas são e o quanto os produtos entregues começaram a ter um menor grau de reclamação e defeitos encontrados pelo cliente

A Renata Eliza sugeriu 7 atitudes que os profissionais da área de Teste de Software precisam ter:

  1. O 1º passo é ter uma afeição pela área área;
  2. Pensar que: você não precisa provar nada pra ninguém (sem essa de achar que eles vão pensar que você era um péssimo desenvolvedor, ou que não achou nada de mais interessante na área…);
  3. Aprender. A busca do conhecimento é fundamental;
  4. Empreender no dia a dia de trabalho;
  5. Aplicar técnicas.. Cada uma em seu tempo. E mostrar os resultados alcançados com cada uma delas;
  6. Dar nome ao que está sendo feito.  Por exemplo: por que falar que vai repetir todos os testes? Diga: Vou realizar um teste de regressão. Pode parecer idiota, mas é uma maneira simples de mostrar que não nos limitamos a fazer testes exploratórios, e que existe técnica no que estamos fazendo;
  7. Não se desvalorizar.

Já para o Camilo Ribeiro, o testador não pode ser limitar apenas as suas tarefas, e disse:

A forma que temos de reverter isso começa em nós mesmos. Como disse Tolstoi (se não me engano) “Todos querem mudar o mundo, mas ninguém quer mudar a si mesmo”.

Ao mudamos nosso ambiente de trabalho aplicando técnicas, definindo um processo, criando indicadores, gerenciando nossas atividades e demonstrando o valor dos processos de teste dentro da organização que nós trabalhamos nós mudamos nossa imagem e conseqüentemente a imagem da nossa profissão.

Outra coisa fundamental na minha opinião é ser técnico. Saber programar, orientação a objetos, SQL, design patterns, conhecer ferramentas, usar frameworks, elaborar e revisar requisitos, escrever processos, gerencia de configuração e etc não nos torna menos testadores, muito pelo contrário, conhecer de tudo é saber identificar defeitos em tudo.

O Ueslei Silva fez um relato de uma experiência que passou, na qual a realização de treinamentos gerou bons resultados:

Após alguns treinamentos internos para os profissionais do setor de testes e algumas explanações internas sobre o que realmente é teste de software, depois de muita luta, finalmente entenderem que não é tão fácil como parece, principalmente quando o que temos para testar é um legado sem documentação…rs

Passos para um novo horizonte para realização dos testes começaram a se dar na empresa, mesmo que com algumas resistências, pois o custo é alto e profissionais precisam ser qualificados, cultura precisa ser mudada, etc…

O Edwagney contou uma interessante maneira de explicar e convencer as pessoas sobre a importância do Teste de Software, na qual precisamos:

Começar a mudar a percepção dos desenvolvedores, arquitetos e PRINCIPALMENTE dos clientes.

Certa vez estava dando um treinamento para uma das empresas em que trabalhei, sobre a recém-criada área de teste. Os treinandos eram compostos por desenvolvedores e arquitetos. A primeira pergunta que fiz a eles foi uma que vocês já devem conhecer: Se o software que vocês projetam e desenvolvem fosse para o controle de uma aeronave, vocês voariam nessa aeronave? (dá pra imaginar a resposta, não é verdade?) 🙂

Isso também deve ser levado ao cliente… Tente perguntar ao seu cliente se ele confiaria em voar em um avião que não foi passado por uma bateria de testes antes? Será que ele entraria lá dentro?

Coloque pra ele o valor que foi gasto para se construir e quanto será o gasto de cada defeito, senão for testado corretamente? Tente apresentar a ele o risco que a empresa dele corre, caso um defeito ocorra e este paralise o negócio dele?

A respeito se existem preconceitos de outras áreas para a área de Teste de Software, a Andrea Cruz apresentou uma maneira bem madura de se lidar com eles:

Preconceitos existem. A melhor forma é primeiro aceitar. Não adianta reclamar. É preciso admitir que existe um preconceito oriundo de uma grande falta de conhecimento nesta área e que por ignorância alguns discriminam. Algumas pessoas do  desenvolvimento se sente ameaçadas. Só você pode conscientizar as pessoas, esclarecê-las. Lutar pela qualidade é lutar por um padrão que só traz benefícios. É ser amigo do desenvolvedor e do cliente.

Para o Rodrigo Cruz, o preconceito é fruto da falta de informação:

Sofremos preconceito daqueles que não conhecem o nosso trabalho e nem se preocupam de perguntar o que fazemos, porque a partir do momento que isso ocorrer, com certeza eles vão deixar de pensar dessa forma.

Para quem ficou interessado no assunto, recomendo fortemente a leitura de toda a discussão, pois esse foi apenas um resumo, para ter idéia eu nem citei sobre a discussão levantada pelo Robson, sobre se seria interessante os analistas de negócios/requisitos/sistemas verificarem os casos de testes criados pela equipe de teste.

Participem das mesas redondas, entrando no DFTestes! 😉

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

P.S.: Desculpa pelo resumo ter ficado muito grande, mas acredito que é melhor informação a mais do que o contrário. 😉

O Caso Abu Dhabi – Usuário Negligenciado

Bem amigos do blog QualidadeBR!

No último domingo, tivemos o encerramento da eletrizante temporada 2009 da F1. E o desfecho do campeonato ocorreu no mais novo circuito da temporada o Yas Marina, localizado no maior emirado dos Emirados Árabes Unidos, Abu Dhabi.

O intuito do post é fazer um breve estudo de caso, de algo que ocorreu na construção do circuito e que também ocorre em projetos de software.

Para começar o estudo de caso do circuito de Abu Dhabi, é preciso antes falar sobre o seu projeto, que custou a bagatela de 1,322 bilhões de dólares (segundo a Wikipedia).

A construção do circuito teve início em fevereiro de 2007, com o “modesto” desafio de construir um dos mais modernos circuitos da F1 no meio do deserto. Alguns números da “singela” construção:

  • Uma força de trabalho de 14.000 homens;
  • 35 milhões de hora-homem investidos;
  • 1,6 milhão de metros cúbicos de terra foram deslocados;
  • 720 mil metros quadrados de asfalto;
  • 25 quilômetros de cabeamento elétrico;
  • 5 mil árvores plantadas;
  • 430 mil metros quadrados de terreno foram ajardinados;
  • 40 quilômetros de blocos instalados;
  • Um hótel 5 estrelas foi construído no meio do circuito.

Ou seja, um construção daquelas que costumamos ver no programa Mega Construções do Discovery Channel.

E como todo projeto, há objetivos a serem alcançados ao término:

  • Construir um circuito moderno e de acordo com as novas premissas estabelecidas pela FIA;
  • Suportar um grande público e oferecer conforto ao mesmo;
  • Uma boa iluminação que permita a realização de corridas noturnas;
  • Encerrar o projeto em 2009, antes das inspeções da FIA para o grande prêmio de Abu Dhabi de F1.

Bem, esses são alguns objetivos que eu acredito que poderiam medir o nível de sucesso do projeto do circuito de Yas Marine. Abaixo, segue uma galeria de fotos, que mostra o circuito desde o início da construção até o término.

E além daqueles objetivos que citei, em uma reportagem divulgada no site PlanetF1, Richard Cregan, o administrador do circuito, revelou que os stakeholders do projeto esperavam algo incrível.

Portanto, de acordo com os objetivos citados e a expectativa dos stakeholders o projeto foi um sucesso, afinal o circuito ficou pronto no tempo e com certeza impressionou os stakeholders, dentre eles a FIA.

Eu mesmo comentei no twitter, após assistir os melhores momentos da classificação, que o circuito é fabuloso, nos faz perceber o quanto evoluímos em termos de construções, fazer um circuito daquele em pouco mais de 2 anos é um feito muito impressionante mesmo.

Porém…

Acho que faltou a opinião de alguém na história, não faltou?

Faltou “só” a opinião dos pilotos e dos espectadores.

Pelo que li pela internet e ouvi na narração da corrida, todos os pilotos ficaram impressionados com o circuito, porém poucos ficaram impressionados com o desafio que o circuito proporciona, tanto que o Rubinho disse que o ponto mais perigoso da pista é o túnel da saída do pit-stops, ou seja, pelo visto não é um circuito muito desafiador, até porque, se o piloto escapar em alguma curva, ele terá uma boa área de escape asfaltada para retornar a pista, o que vai causar apenas uma perda de tempo.

Como espectador, achei a pista bem sem graça, quase não há pontos de ultrapassagens, o que resultou numa corrida bem monótona.

Acredito que os stakeholders se esqueceram de dois ingredientes essenciais para uma corrida de F1: o desafio e ultrapassagens. Afinal, a ultrapassagem está para a F1, assim, como o gol está para o futebol.

E na lista de stakeholders da construção do circuito, acho que não foram incluídos os pilotos. (fail)

O ponto que quero chegar

O que ocorreu no projeto do circuito Yas Marina é algo que também ocorre em projetos de TI: a negligência em relação aos usuários.

Os projetos nascem e morrem de acordo com os interesses dos envolvidos, até aí tudo bem. O grande problema é quando esses interesses não incluem os interesses dos reais usuários do fruto daquele projeto. Quem participa do mundo da gerência de projetos ou já teve algum contato, sabe que nem sempre, o cliente será o usuário daquele determinado produto a ser desenvolvido, portanto o cliente tem um papel primordial de representar os usuários. Porém, nem sempre o cliente tem pleno conhecimento sobre o que os usuários esperam daquela determinada solução.

Algo que ocorre com uma certa frequência incômoda em projetos de software, é que eles não são centrados no usuário,  muitas vezes os usuários só terão contato com o sistema após o término do mesmo. E isso deve-se há vários motivos, dentre os quais um muito estranho é o medo do pessoal de TI de se envolver com os usuários, pois eles tem em mente que se forem conversar com os usuários eles irão pedir mais uma “trocentas” mudanças, e mudanças para esses profissionais é algo muito ruim. Afinal das contas, os interesses deles, às vezes se limitam em apenas obter o melhor ROI, e que se dane que a solução desenvolvida não solucione nada, seja difícil de utilizar, e que ainda tenha vários bugs. Para esses “profissionais” isso é até melhor, pois assim eles irão ganhar dando treinamentos e novos contratos de manutenção irão surgir. Ou seja, uma maneira de desenvolver software a lá Dick Vigarista e seguindo a Lei de Gérson, e que a médio e longo prazo não traz nem mais retorno financeiro, já que a fama da empresa já terá se espalhado entre os clientes.

Um outro ponto interessante de se comparar a construção do circuito de Yas Marina com a construção de um software, é que às vezes nós acabamos fazendo o mesmo que a FIA fez, burocratizar e criar padrões demais, e o mais preocupante, padrões fora do contexto da realidade, como por exemplo, criar circuitos que dificultem as ultrapassagens. Por isso, que é bom de vez em quando tirar a cabeça do prato. 😉

Lembre-se que a qualidade é uma questão de ponto de vista, e no desenvolvimento de software o ponto de vista mais importante é o do usuário.

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

Fonte:

http://en.wikipedia.org/wiki/Yas_Marina_Circuit

http://www.itv-f1.com/Feature.aspx?Type=General&id=47272

http://www.planet-f1.com/story/0,18954,3213_5658598,00.html

Imagens:

http://www.architecturelist.com/wp-content/uploads/2009/05/yashotel-asymtote.jpg

http://www.ameinfo.com/images/news/1/80441-YasMarina.jpg

http://www.bustler.net/images/uploads/asymptote_yas_hotel_06x.jpg

http://www.thenational.ae/apps/pbcsi.dll/bilde?Site=AD&Date=20090918&Category=NATIONAL&ArtNo=709179849&Ref=AR