A volta dos que não deveriam ter ido
Esta semana eu completaria 10 meses sem postar no blog. Quando o criei, meu maior medo era exatamente deixá-lo de lado, tanto que comentei isto no meu post inaugural.
Em maio de 2010, eu estava afastado da área de testes e todos os meus esforços para voltar a ela dentro da empresa onde trabalho eram infrutíferos. Mas testes de software é a minha especialidade, é o que gosto de fazer, e decidi que não a abandonaria. Permaneci estudando, lendo muito, me certificando e o blog tinha o objetivo de preencher a necessidade de conversar sobre o tema, de dar vazão às idéias que eu bebia de diversas fontes.
Só que em junho do ano passado fui premiado com o nascimento da minha segunda filha, o que me trouxe uma enorme realização pessoal e me levou parte do orçamento. Em outubro, recebi a missão de ser assessor do departamento onde trabalho, o que me foi importante profissionalmente e recuperou parte do orçamento. Não tenho do que reclamar, mas o fato é que ambos os acontecimentos tomaram todo o tempo livre que eu disupunha, seja em casa, seja no trabalho, e anulou qualquer chance de me dedicar aos estudos na área de testes e ao blog em si.
Os meses foram passando e volta e meia eu pensava no blog, imaginava alguns assuntos que gostaria de abordar, ensaiava uma retomada, visitava a área administrativa para atualizar versões do WordPress e dos plugins, mas nunca conseguia, simultaneamente, tempo e inspiração para criar novos posts.
Mas quis o destino que, em março deste ano, as portas antes fechadas resolvessem se abrir: resolveu-se que minha experiência e conhecimento seriam melhor aproveitados em uma nova área da empresa, dedicada à Engenharia de Desempenho. Se antes eu tinha interesse apenas pessoal de manter-me atualizado sobre o assunto, agora eu tenho um compromisso profissional de agregar conhecimento e transformá-lo em valor para os processos de qualidade da empresa.
Volto portanto a trabalhar com testes de software, mais especificamente com testes de performance. Agora que me sobra inspiração, falta apenas arrumar um tempinho aqui ou ali para blogar. Espero ter a chance de voltar também a compartilhar minhas idéias com o leitor.
Para cada modelo, uma estratégia
Agora que já destrinchei os princípios fundamentais dos testes de software, vamos analisar as implicações daquele que, para mim, é o princípio mais importante: "testes dependem do contexto".
Para que uma iniciativa de testes seja bem sucedida, ela precisa estar integrada ao ciclo de vida de software. Como cada modelo de desenvolvimento tem características específicas, é necessário que os testes sejam planejados de modo a respeitar as limitações e tirar proveito das vantagens do modelo escolhido.
Vamos analisar aqui três dos modelos de ciclo de vida mais comuns e verificar como os testes podem se alinhar a cada um deles.
•••
Modelo Sequencial
Neste modelo, o sistema é construído de uma única vez, ou seja, as atividades seguem uma sequência rígida de definição, construção e testes. Os requisitos do sistema são definidos, o design é estabelecido, o código é desenvolvido e enfim os testes são realizados. Um fator crítico de sucesso deste modelo é que os requisitos sejam definidos o quanto antes, e que alterações posteriores, quando não evitadas, sejam muito bem gerenciadas. Os exemplos mais comuns de modelos sequenciais são o Waterfall e o V-Model.
Uma vez que a especificação do sistema é disponibilizada no início do ciclo, este tipo de projeto favorece uma estratégia de testes baseada em requisitos. Testes estáticos — como revisões, inspeções e walkthroughs — podem e devem ser realizados sobre estas especificações, fazendo com que a atividade de testes assuma um aspecto preventivo e promovendo a eliminação de defeitos a um custo menor. A disponibilização antecipada das especificações também permite que a confecção de casos de testes fique fora do caminho crítico do projeto, já que esta ocorre paralelamente ao design e à construção da aplicação.
A má notícia é que um modelo sequencial implica na execução dos testes dinâmicos com a última atividade antes do release da aplicação. Isso coloca a equipe de testes em uma posição bastante desconfortável. Quando o deadline do projeto é inexorável, atrasos na fase de construção da aplicação significam um imediato encurtamento do cronograma de execução dos testes. Somado a isso, é natural que a equipe de testes assuma um papel de "vilão", sofrendo imensa pressão para que aprove o release, uma vez que não há mais tempo hábil para corrigir defeitos complexos que eventualmente dêem as caras nesta fase.
•••
Modelo Iterativo-Incremental
Ao invés de construir o sistema de uma só vez, o projeto é dividido em pequenos releases, adicionando funcionalidades paulatinamente, até o momento em que a aplicação é considerada pronta para a entrada em produção. A grosso modo, pode-se considerar que o modelo iterativo-incremental é uma sucessão de pequenos modelos sequenciais.
A duração de cada iteração varia muito. Quando é muito longa, a equipe de testes consegue utilizar a mesma estratégia de testes baseada em requisitos. No entanto, iterações muito curtas dificultam esta abordagem, tanto no que tange ao tempo disponível para desenvolvimento e execução do testes, quanto no que diz respeito à riqueza de informações das especificações.
Nestes casos, a equipe de testes precisa utilizar estratégias diferentes, como a baseada em riscos. Esta estratégia consiste na identificação, avaliação e priorização de áreas de riscos, sejam estes riscos ao produto, ao projeto ou ao negócio. O foco dos testes passa a ser proporcional à prioridade de cada área de risco, fazendo com que as áreas mais críticas recebam uma melhor cobertura dos casos de testes.
Um dos conceitos fundamentais da estratégia de testes baseada em riscos é a execução dos testes de acordo com a prioridade de suas respectivas áreas de risco. Testa-se primeiro o que é crítico e por último o que é cosmético. A vantagem deste approach é fazer com que uma eventual redução do cronograma de execução inviabilize apenas a execução dos testes das áreas de menor risco. Com isto os stakeholders passam a ter uma medida mais realista do riscos que estão assumindo ao manter o deadline em detrimento da qualidade.
Mas o modelo iterativo-incremental também traz alguns obstáculos. Um deles é o suporte mais deficiente do projeto à equipe de testes, uma vez que analistas de negócio, designers e programadores estão sempre trabalhando nas iterações seguintes e não terão a mesma disponibilidade para esclarecer especificações ou corrigir defeitos. Outro aspecto negativo é a necessidade de realização de testes de regressão, evitando que um novo release quebre código que já foi testado e aprovado anteriormente.
•••
Modelo Espiral
Proposto por Barry Boehm, este modelo consiste na utilização de técnicas de design baseadas em prototipação. A partir de um conceito inicial, realiza-se o design e implementação de um primeiro protótipo, que é testado e redesenhado sucessivas vezes até o momento em que se obtém um protótipo operacional, que é submetido a um último ciclo, mais robusto, de redesign, codificação e testes. É um modelo muito utilizado em projetos complexos mas também tem seu espaço em projetos pequenos, baseados em metodologias ágeis.
A característica mais evidente do modelo espiral é a grande quantidade de mudanças que ocorrem nos seus ciclos iniciais. Estas constantes alterações no design e no ambiente do produto inviabilizam a utilização de técnicas de testes mais formais e exigem uma estratégia de testes mais flexível e extremamente adaptável.
Um exemplo de estratégia que se adapta a este perfil é o conceito de "exploratory testing", termo cunhado por Cem Kaner, que pode ser resumido como um método onde, simultaneamente, aprende-se sobre o produto, decide-se o que testar e executa-se os testes. Testes exploratórios exigem uma equipe de testes bastante experiente, uma vez que o feeling do testador é determinante para identificar os pontos onde um bug crítico pode se esconder.
•••
Por fim, é meu dever lembrar ao leitor que as correlações acima entre modelos de ciclo de vida e estratégias de testes não devem obviamente ser recebidas como regras rígidas, mas como conceitos a serem levados em consideração pela equipe de testes na hora de escolher o melhor approach para cada projeto.
Até porque, na maioria das vezes, a estratégia mais eficiente é uma combinação de diferentes approaches numa mesma iniciativa de testes. Tudo depende do contexto. Sempre.
Os Sete Princípios Fundamentais dos Testes de Software
Uma das coisas que nunca saíram da minha cabeça desde que comecei os estudos para a CTFL, que obtive em 2006 como já expliquei em outra oportunidade, é o que encontramos no Syllabus como "Princípios Gerais do Teste", mas que eu prefiro chamar pelo pomposo e cabalístico nome que é título deste artigo.
É impressionante a recorrência com que me utilizo destes princípios para trazer ao chão discussões que se perdiam nas alturas por conta de falácias, chavões ou idéias pré-concebidas.
Por serem importantes para mim, decidi listá-las e explicá-las a meu modo, com a esperança de que sejam igualmente úteis ao leitor.
Os princípios não estão na mesma ordem apresentada pelo Syllabus CTFL. Tomei a liberdade de reordená-los por considerar que esta é uma sequência mais lógica, mais didática.
1. TESTES DEPENDEM DO CONTEXTO
Este princípio foi introduzido por Glenford Myers em seu famoso livro "The Art of Software Testing", de 1979: diferentes projetos têm necessidades diferentes em relação aos testes de software.
Nem toda aplicação tem o mesmo nível de risco e nem todo defeito traz o mesmo impacto quando ocorre. Não há sentido algum em testar uma ferramenta de treinamento da mesma maneira que se testa um site de e-commerce. E é igualmente absurdo imaginar que este último deve ser testado da mesma maneira que um sistema de controle aéreo.
Uma metodologia de testes precisa ser abrangente o suficiente para admitir estratégias que se utilizem de diferentes técnicas de testes. Mas definitivamente não existe uma estratégia "one size fits all".
2. ANTECIPAÇÃO DOS TESTES
Testes não devem ser vistos como uma etapa final ou um simples "polimento" do sistema.
A maioria das empresas desconhece o poder de realizar testes estáticos ao longo das fases de especificação e codificação do sistema. Ignoram que é muito mais barato evitar que problemas nos requisitos sejam transferidos para o design e deste para o código.
Se há algo recorrente em todos os projetos de software é que a etapa de execução dos testes está sempre espremida entre o deploy e a deadline. Com pouco tempo para encontrar defeitos no final do projeto, resta-nos começar a trabalhar assim que o primeiro draft de requisito sai da prancheta.
A qualidade é algo que deve ser construído desde o início, e não algo a ser adicionado no final.
3. TESTES EXAUSTIVOS SÃO IMPOSSÍVEIS
Não há como testar tudo. Nem mesmo "quase tudo". Validar cada combinação de inputs e pré-condições só seria viável se cronograma e orçamento fossem infinitos. Mas a tripla restrição escopo-tempo-custo é cruel e portanto não cabe outra alternativa senão escolher o que testar com base no prazo e no dinheiro que se tem.
Ok, não iremos testar tudo. Mas então o quanto devemos testar? Essa escolha deve ser feita com base no risco que cada funcionalidade oferece para o negócio. Quanto maior o risco, maior o foco que deve ser dado a esta parte do sistema.
4. TESTES INDICAM A PRESENÇA DE DEFEITOS
...PORÉM nunca poderão indicar a ausência absoluta deles! E a lógica é simples: uma vez que os testes não podem ser exaustivos, isso significa que não podemos garantir que um sistema não tem defeitos.
Declarar que um sistema está indo para produção sem defeitos é algo que nem a NASA se atreve a fazer. Até porque depois fica difícil explicar porque o foguete não chegou ao seu destino. 
5. AGRUPAMENTO DE DEFEITOS
É a Lei de Pareto aplicada ao universo dos testes. A idéia é que a maior parte dos defeitos são encontrados em um número reduzido de módulos da aplicação, donde se conclui que o esforço de testes deve dar maior atenção a estes módulos onde a "densidade de defeitos" parece ser maior.
Um aspecto importante deste princípio é a necessidade de analisar cuidadosamente as causas-raízes de determinado agrupamento. Na maioria das vezes, a análise destas causas levam a melhorias no processo de desenvolvimento da empresa.
Por outro lado, há de se tomar cuidado com interpretações equivocadas deste princípio. Encontrar a maior quantidade possível de defeitos não me parece um objetivo eficiente em uma iniciativa de testes pois nem sempre os módulos com o maior número de defeitos são os mais importantes no contexto do negócio.
Como diz Rex Black, "nem todo teste deve encontrar defeitos; alguns devem proporcionar confiança". Pense nisso.
6. O PARADOXO DO PESTICIDA
Agora é a vez de aplicar a Lei de Darwin ao universo dos testes. Um novo inseticida afasta os insetos até o momento em que aparece uma variante que não é afetada pelo princípio ativo e eles voltam a incomodar. Da mesma maneira, um sistema será cada vez mais resistente ao mesmo conjunto de testes executado diversas vezes. Para evitar este problema, é preciso revisar os casos de teste ou mesmo escrever novos casos que exercitem a funcionalidade de maneira diferente. Na nossa metáfora, testar outros princípios ativos.
Um alerta especial aqui vai para testes de regressão, principalmente os automatizados. Às vezes, uma alteração no código pode inserir um bug que não será descoberto pelos casos de teste responsáveis por checar se a funcionalidade foi quebrada. É importante que a equipe de testes mantenha um olhar crítico sobre os testes de regressão, não se deixando levar pela n-ésima execução bem sucedida daquele mesmo set de scripts.
7. A FALÁCIA DA AUSÊNCIA DE ERROS
De nada adianta eliminar um sem-número de defeitos se o sistema não foi projetado com foco nas necessidades do negócio. Em casos como este, os testes só terão contribuído para fazer com que o sistema funcione perfeitamente da maneira que o cliente NÃO precisa.
Nos projetos que gerenciei, sempre pedi à minha equipe que mantivesse um olhar crítico que transcendesse o que está escrito nas especificações. Não adianta apenas saber se o requisito está bem redigido, livre de ambiguidades. É preciso notar se ele atende às necessidades do cliente.
Seminário “Governança e Qualidade de Software”
No próximo dia 08 de Julho, o Laboratório de Engenharia de Software da PUC-Rio realizará um evento com o objetivo de demonstrar a importância da adoção de práticas de governança para a melhoria da qualidade de software.
Também serão discutidas estratégias de redução de custos, além de indicadores de testes de software. Uma mesa redonda debaterá a realidade do mercado frente aos desafios da gestão de ambientes de testes e modelos de subcontratação desta atividade.
Um dos palestrantes, Rafael Espinha, é sócio da PrimeUp, empresa onde em 2010 fiz o excelente treinamento "Testes de Desempenho, Carga e Estresse com Utilização da Ferramenta Open Source JMeter".
As inscrições devem ser realizadas através do telefone 0800 970 9556. Como o evento é gratuito, a participação será limitada a duas pessoas por empresa.
Confira a programação do evento no folheto disponível aqui.
Dropbox comendo mosca nas nuvens
Na manha de hoje, vários usuários do serviço Dropbox receberam um email advertindo sobre uma falha de segurança que aconteceu no último dia 19 e que expôs indevidamente os repositórios de seus usuários.
Segue o conteúdo da nota que recebi:
Hi Pedro,
On June 19, 2011, we had a software bug that caused authentication issues. You can read more about it in our blog post. Our records show that your account wasn't improperly logged into during this time.
We are writing to you because one or more users you share a Dropbox folder with logged into their account during that period. We have no reason to believe that the login was improper, but in the unlikely event it was, there could have been access to the information in the following shared folder:
- Testing
We are very sorry as this never should have happened. We are implementing additional safeguards to prevent this from happening again. If you have any questions please contact us at support@dropbox.com
- The Dropbox Team
No post citado pela nota acima, a Dropbox explica que no dia 19 Jun, às 13:54 PST, fez o deploy de um update de código que acabou por introduzir um bug em seu mecanismo de autenticação. O problema permitia que os usuários se logassem nas contas mesmo com a senha incorreta. O bug só foi descoberto às 17:41 e corrigido às 17:46, o que significa que durante quase QUATRO HORAS qualquer login realizado no serviço foi feito sem validação de senha.
Tudo que a empresa conseguiu averiguar até agora é que aproximadamente 1% das contas realizaram login no sistema durante este período. Só que, como consequência, pastas compartilhadas por essas contas com outros usuários também foram expostas, como o email acima deixa claro ser o meu caso. Interessante é que não há como saber se estes acessos foram mal intencionados, uma vez que nada impede que um usuário legítimo tenha acessado sua própria conta usando, por descuido, uma senha errada. O fato é que diversos clientes do serviço tiveram o conteúdo de seus repositórios acessíveis indevidamente durante um belo tempo.
Considero que há duas lições bastante claras aqui, uma para a Dropbox, outra para seus usuários.
Em um serviço cuja característica principal é o armazenamento de informações heterogêneas dos usuários, em um sem-número de formatos, de conteúdos sensíveis ou não, a segurança deve ser prioridade absoluta. É melhor que o sistema esteja indisponível do que acessível a estranhos. Qualquer feature que estiver com problema é menos nociva do que um bug no componente que vai dar, a um desconhecido, acesso àquelas fotos duvidosas que você tirou no Carnaval passado...
Em um sistema com este perfil, QUALQUER deploy em produção deve ser antecedido por testes de regressão especificamente voltados para a segurança. E neste set, nunca poderia faltar um simples teste negativo de acesso, que comprova que uma senha incorreta NÃO consegue logar no sistema. Do alto das nuvens, a equipe de Quality Assurance da Dropbox comeu uma bela mosca.
Mas o usuário também deve ficar atento ao seu próprio comportamento. Segurança e Internet são dois termos com uma capacidade incrível de se repelirem. Como se pode ver no caso acima relatado, às vezes um erro primário é suficiente para promover este afastamento. Portanto, não é muito auspicioso disponibilizar informações sensíveis neste tipo de serviço. Talvez a melhor maneira de evitar este tipo de situação desconfortável seja criptografar estes dados sensíveis ANTES de mandá-los pras nuvens...
MBA em Garantia de Qualidade de Software
Agora que já escrevi três posts sobre as certificações ISTQB (1, 2 e 3), vou concluir a série de "posts acadêmicos" com uma rápida informação que talvez seja de interesse dos leitores cariocas.
A UFRJ está com inscrições abertas para a 4ª turma de seu curso de pós-graduação lato sensu "MBA em Garantia de Qualidade de Software (MBQA)". Com previsão de início já neste mês de junho, o curso terá duração de 18 meses e carga horária total de 360 horas. As aulas serão ministradas nas noites de quarta e quinta, na sede do Clube de Engenharia, na Av. Rio Branco, Centro.
A ementa do curso está dividida em dois módulos, a saber:
Módulo Tecnológico
1. Comportamento Organizacional
2. Informação e Suporte à Decisão
3. Processo de Software
4. Gerência de Projetos de Qualidade
5. Governança da Qualidade
6. Processo de Teste de Software
7. Técnicas e Ferramentas de Teste
8. Métricas de Software
9. Qualidade de Dados
10. Qualidade do Sistema
11. Segurança de Sistemas
12. Método Ágil e Qualidade
Módulo Metodológico
1. Seminário de Metodologia de Pesquisa
2. Projeto Final
Parece uma excelente oportunidade para o leitor que realmente deseja se aprofundar nesta área de conhecimento. Para maiores informações, acesse a página do curso no site da Escola Politécnica da UFRJ. Mas não deixe pra depois, porque as aulas começam este mês!
Raising the bar: obtendo a CTAL
No artigo anterior eu comentei como foi minha experiência na obtenção da certificação CTFL. Neste aqui, tratarei das certificações avançadas, com um ou outro comentário específico da que eu possuo enquanto escrevo este artigo, a CTAL-TA.
•••
Histórico
Em março de 2010, o CInTeQ - Congresso Internacional em Testes e Qualidade de Software - reuniu em São Paulo grandes expoentes nacionais e internacionais da área de qualidade, entre eles o bam-bam-bam Rex Black, que ofereceu um curso preparatório para o exame CTAL-TA, exame este que foi aplicado (em inglês) ao final do curso.
Um ex-colega meu, dos tempos de EDS, obteve a certificação nesta oportunidade e me incentivou a fazer o mesmo assim que o BSTQB marcasse nova prova.
No meio do mesmo ano de 2010, concluí na Dataprev um projeto de normatização dos Testes de Performance da empresa, projeto esse que renovou meu interesse na área de testes de software e me fez decidir a realizar o exame, em dezembro de 2010.
•••
Como estudar
Diferentemente do Foundation, o exame avançado é sim um exame difícil. Ele vai mais a fundo no conteúdo do exame CTFL e ainda adiciona novos assuntos.
Um problema das certificações CTAL é a absoluta inexistência de material didático em português, exceto pelo Syllabus e Glossário de Termos disponibilizados pelo BSTQB que, como sabemos, são absolutamente insuficientes para ter êxito no exame.
Minha dica é a aquisição da EXCELENTE coleção "Advanced Software Testing", do autor Rex Black (já falamos desse sujeito em outro post). A obra já teve dois volumes publicados (um para CTAL-TA e outro para CTAL-TM) e o terceiro volume, para CTAL-TTA, já está para chegar às lojas. É uma obra completa, que cumpre seu objetivo de dar ao leitor todos os insumos necessários para passar nos exames CTAL sem necessidade de consultar outras fontes.
Meu método para a CTAL-TA foi ler o Volume 1 de cabo a rabo, parando ao final de cada capítulo para ler a seção correspondente do Syllabus, e respondendo em seguida as questões contidas no livro relativas àquele capítulo. Concluída a leitura de toda a publicação, refiz de uma vez só TODOS os exercícios para fixar o conteúdo.
Por último, concluí um mock exam que consegui na Internet e parti pro exame.
•••
A prova
Primeiramente o candidato precisa comprovar que atende as qualificações mínimas e, para tal, deve preencher um formulário online no site do BSTQB, pagar uma taxa de R$8o e aguardar até 30 dias pelo resultado da avaliação. Esta qualificação não expira e portanto pode ser utilizada no em todas as certificações CTAL.
Uma vez qualificado, o candidato pode realizar a inscrição para o exame através do site do BSTQB, no valor de R$350. O board brasileiro oferece mais de 30 locais em todo o país para a realização da prova, o que inclui quase todas as capitais.
O exame CTAL é apresentado em papel, contendo 65 questões múltipla-escolha, com pesos diferentes de acordo com sua complexidade. Cada questão tem 4 opções de resposta. O somatório dos valores das questões de um exame é de 100 pontos. A prova tem 3 horas de duração e para certificar-se o candidato deverá obter nota mínima de 65% da pontuação do exame.
Roadmap para a CTFL
Agora que o leitor já sabe o como estão estruturadas as certificações ISTQB, vou passar um pouco de como foi a minha experiência na obtenção do CTFL.
•••
Histórico
Em 2006, eu morava em Florianópolis e trabalhava como Test Manager na EDS - Electronic Data Systems - empresa multinacional de excelência em serviços de TI. Para concorrer com a filial indiana, que cada vez absorvia mais e mais projetos de teste da corporação, a EDS do Brasil iniciou um processo de treinamento com o objetivo de certificar 100% de seus recursos da área de testes de software.
A EDS Brasil enviou três recursos à sede americana para fazerem um treinamento específico, de onde sairam não só como profissionais certificados CTFL, mas como também preparados para propagar o conhecimento, tornando-se instrutores das turmas que seriam formadas no Brasil.
Tive a honra de ser selecionado para participar da primeira turma de Floripa. Após 40h de treinamento, utilizando material didático próprio da EDS, estavamos prontos para o exame. Só que, naquela época, o BSTQB estava apenas iniciando suas operações como board regional do ISTQB e ainda não aplicava exames para o público em geral. A única maneira de obter a certificação CTFL no Brasil era pela Prometric, líder mundial em certificações em TI. Pra piorar, a Prometric não oferecia locais para aplicação deste exame em Floripa, o que nos obrigou a fazê-lo em Curitiba.
•••
Como estudar
Para quem tem algum background em testes, o exame CTFL não é propriamente um exame difícil. O problema é que ele é baseado em um manual de boas práticas (o Syllabus), práticas essas que nem sempre são utilizadas pelas empresas em que trabalhamos. Isso gera um gap de conhecimento que é preciso preencher com informações de diversas fontes.
A primeira coisa a fazer é cadastrar-se (gratuitamente, diga-se de passagem) no site do BSTQB e fazer os mini-simulados, assim como os mock exams disponíveis na área de arquivos. A idéia é ter uma exata noção do nível de dificuldade da prova e avaliar seu conhecimento em relação ao escopo do exame. MAS ATENÇÃO: tente realizar os exercícios sem ver o gabarito, pois isso permitirá que você se avalie novamente após os estudos. O ideal é que você saiba apenas quantos pontos fez. A dica é pedir a um amigo ou familiar que faça a correção pra você.
Feito isso, é hora de decidir em qual idioma você irá estudar. Apesar do material oficial do ISTQB (syllabus e glossário) ser todo traduzido pelo board brasileiro, ele é insuficiente para obter êxito na prova. É aí que começa o problema pois, em geral, outras referências como livros e sites, o leitor só encontrará em inglês. Eu sempre optei por estudar na língua inglesa, pois prefiro me acostumar aos termos técnicos em inglês para facilitar a leitura de livros e periódicos internacionais, além de ficar livre de traduções horrorosas que vez em quando encontro nas versões do BSTQB.
Pra quem pensa como eu, a dica quente é adquirir o livro "Foundations of Software Testing: ISTQB Certification". Ele é pra lá de completo e poupará o leitor do trabalho de correr atrás de referências extras. Simples assim.
Para os que não querem estudar em inglês, eu recomendo uma leitura do Syllabus Foundation Level e do Glossário de Termos. Este último é pra lá de massante, portanto recomendo dividir sua leitura em partes. Exemplo: separe os termos do Glossário em grupos de 4 letras iniciais e os leia ao fim de cada capítulo do Syllabus. Feito isso, é hora de partir atrás de referências complementares. Sei de gente que passou no exame se utilizando do livro "Base de Conhecimento em Teste de Software", mas como não o li, fica por conta e risco do leitor.
O capítulo mais complicado do Syllabus, de longe, é o que versa sobre Técnicas de Modelagem de Testes. Isso porque quem não conhece o assunto não terá nem como chutar as respostas, uma vez estas não são facilmente dedutíveis por um leigo. Não por acaso, muitas questões da prova são sobre este assunto específico. Portanto, é mister que o candidato tenha a preocupação de entender perfeitamente quando e como aplicar cada técnica de modelagem.
Abaixo listo alguns sites que podem servir como referência aos candidatos:
- IEEE 829-2008 - http://www.cs.unb.ca/profs/wdu/cs3043w10/IEEE-829-2008.pdf
- Templates IEEE 829 - http://www.testexpert.com.br/?q=node/1666
- The Test Management Guide (sobre técnicas de modelagem de testes) - http://www.ruleworks.co.uk/testguide/
- Simulados - http://qualidadebr.wordpress.com/2009/02/27/simulados-ctfl-bstqb/
Em tempo: não é necessário um conhecimento aprofundado dos standards IEEE, mas é importante ter uma idéia macro da estrutura de cada norma. Há outras normas IEEE igualmente importantes para a prova, mas não as encontrei disponíveis gratuitamente na Internet.
Caso o leitor tenha alguma outra sugestão de material de estudos, peço que entre em contato comigo para que eu atualize este post.
•••
A prova
A inscrição para o exame CTFL é feita através do site do BSTQB e custa R$350. O board brasileiro oferece mais de 30 locais em todo o país para a realização da prova, o que inclui quase todas as capitais.
O exame CTFL é apresentado em papel, contendo 40 questões múltipla-escolha, com 4 opções de resposta para cada questão. A prova deve ser realizada em um tempo máximo de 60 minutos. Para ser aprovado, o candidato precisa acertar 25 questões (60% da prova).
Certificações ISTQB
O ISTQB – International Software Testing Qualifications Board – é uma entidade internacional cujo objetivo é oferecer globalmente uma estrutura de certificação em testes de software. Fundada em 2002 na Escócia, hoje tem sua sede estabelecida na Bélgica.
Seu braço brasileiro, o BSTQB, é responsável pela promoção das certificações e aplicação dos exames no Brasil, assim como pela tradução das documentações oficiais da entidade para a Língua Portuguesa.
Mais de 155 mil pessoas em todo mundo já obtiveram um dos três níveis das certificações ISTQB, cujas características analisaremos a seguir.
•••
CTFL – Certified Tester Foundation Level
É certificação mais básica, direcionada a qualquer profissional que tenha ou queira ter envolvimento com a área de testes de software. O certificado garante que o profissional detém entendimento básico sobre o tema.
O exame não tem pré-requisitos obrigatórios, o que significa que qualquer pessoa pode se candidatar a fazê-lo.
A certificação não tem prazo de validade e seu exame é oferecido pelo BSTQB desde 2006.
•••
CTAL – Certified Tester Advanced Level
No nível seguinte, encontramos as três certificações CTAL, em que cada uma possui um foco específico, a saber:
- CTAL-TM (Test Manager). Para profissionais envolvidos nas atividades de gerenciamento dos processos de testes, como definição de estratégias, planejamento dos testes, liderança de recursos, gerência de comunicação, etc.
- CTAL-TA (Test Analyst). Visa os profissionais envolvidos diretamente com testes funcionais, como análise dos requisitos, desenvolvimento dos testes e a execução dos mesmos.
- CTAL-TTA (Technical Test Analyst). O foco aqui são os profissionais com atividades relacionadas com testes não-funcionais, como performance, segurança, etc.
Para candidatar-se a qualquer exame CTAL, é necessário cumprir os seguintes pré-requisitos:
- Ser um profissional certificado CTFL.
- Comprovar atividades exercidas, em período integral, em pelo menos um dos itens abaixo:
- 2 anos de experiência prática em Teste de Software ou Qualidade em TI.
- 2 anos dedicados à Pesquisa Acadêmica relacionada a Qualidade de TI em nível de Pós Graduação, ou como instrutor de cursos ou disciplinas relacionadas à Qualidade de TI.
- 3 anos em Desenvolvimento de Sistemas, Análise de Sistemas ou Engenharia de Software.
Embora não seja uma denominação oficial do ISTQB, aqueles que obtêm êxito nas três certificações avançadas são comumente reconhecidos como CTAL-FULL.
Assim como a CTFL, esta certificação não tem prazo de validade. Desde 2010, o BSTQB oferece exames para a certificação CTAL-TA. Em 2011, já estão programados exames para as certificações CTAL-TM e CTAL-TTA.
•••
CTEL - Certified Tester Expert Level
O mais alto nível das certificações ISTQB possui uma estrutura ainda mais modularizada que a imediatamente anterior. Aqui o foco é no profissional que realmente deseja se especializar em um determinado aspecto dos testes de software.
Os seguintes módulos já foram lançados ou estão em desenvolvimento:
- Improving the testing process
- Test management
- Test automation
- Security
Outros módulos ainda estão sendo considerados pelo ISTQB, como Agile testing, Model-based testing, Performance testing, Static testing e Test design techniques. Isso serve de exemplo de quão compartimentada esta certificação pode se tornar.
Outra questão interessante é que cada módulo tem seu próprio critério para que o profissional seja considerado elegível para o exame. O módulo "Improving the testing process", por exemplo, possui os seguintes pré-requisitos:
- Ser um profissional certificado CTAL-TM.
- Comprovar atividades exercidas em todos os itens abaixo:
- 5 anos de experiência prática em testes de software.
- 2 anos de experiência na área de conhecimento da certificação em questão (neste caso, melhoria de processos de testes).
- ao menos um artigo publicado, ou apresentação realizada em uma conferência de testes, sobre a área de conhecimento da certificação em questão.
Percebam que é perfeitamente possível que um ou outro módulo exija as três certificações avançadas como pré-requisito para seu exame.
Outro aspecto interessante sobre esta certificação é que, diferentemente das outras, ela vale por apenas 5 anos. Os profissionais CTEL deverão acumular um determinado número de créditos, de acordo uma política específica do ISTQB, para que a validade de suas certificações sejam estendidas por mais 5 anos.
A oferta de exames CTEL ainda é muito incipiente. Na verdade, não conheço nenhum board regional que esteja realizando exames para certificações CTEL neste momento. Não há previsão sobre quando o BSTQB irá iniciar o processo desta certificação no Brasil.
•••
No próximo artigo falarei um pouco sobre meu processo de conquista das certificações CTFL e CTAL-TA. Talvez seja útil para aqueles que se interessem em obtê-las.
Vitrines e tangerinas
Há uns 12 anos, eu ainda tinha o singelo status de namorado daquela que hoje é minha mulher, quando esta passou a atuar como vitrinista de uma grande rede do varejo de moda do Rio de Janeiro.
Lembro-me que fiquei extremamente surpreso, pra não dizer estupefato, com a complexidade desta atividade e suas respectivas ramificações por todo o processo comercial da empresa. Dia após dia, ela me trazia novas visões, novos detalhes, novas decisões que tinha que tomar como parte de seu trabalho. E era cada vez mais embaraçoso reconhecer que eu, em minha mais completa ignorância sobre o assunto, acreditava que aquilo deveria ser algo tão simples quanto "empilhar-meia-dúzia-de-camisetas-e-vestir-um-manequim".
Anos depois, sou eu que tenho que me defrontar com a surpresa nos rostos daqueles que se impressionam quando começo a discorrer sobre testes de software. Planos de teste? Critérios de aceitação?? Matriz de rastreabilidade??? Eu não os culpo. Para eles, testar parecia mesmo ser uma tarefa trivial, daquelas que os deixava à vontade para dizer coisas como "meu produto está pronto, agora é só dar uma testadinha pra garantir".
Neste ponto, quero tranquilizar o leitor e prometer que não serei óbvio a ponto de dizer que a matéria de testes de softwares é tão complexa quanto a programação visual de vitrines. É uma metáfora que me parece tão eficiente quanto explicar o que é uma bergamota para quem nunca viu uma mexerica.
Tangerinas à parte, existe um paradoxo que é preciso que se faça notar. Testar parece simples e... conceitualmente é mesmo! Aqueles que possuem um testing mindset, e têm a lógica da qualidade correndo em suas veias, não encontram dificuldade alguma em expressar seu ponto de vista sobre este assunto, com o mesmo desembaraço de quem está dizendo algo trivial. O grande desafio é fazer com que os outros acreditem como algo tão óbvio é também – e veja só quanto atrevimento – absolutamente necessário!
Feito este preâmbulo, vamos ao epílogo do prólogo.
É muito comum vermos blogs nascerem inspirados e movimentados e, com o passar do tempo, perderem seu ímpeto e acabarem por ficar às moscas. Acho que é por isso que há muito tempo me sobra desejo e me falta coragem para inaugurar um blog sobre testes de software.
A solução para isso talvez seja compartilhar esta responsabilidade com os leitores.
Pronto. Agora ficou bem mais fácil.