Pros que usam TestLink, saiu ontem a versão minor 1.8.3 com alguns bug fixes.
Lista de Bug Fixes e link para download aqui.
O TestLink é uma ferramenta de gerenciamento de testes open source, com interface web based em php e bancos MySQL, Postgress ou MS-SQL. Pode ser integrado com Bugzilla, Mantis..
Para conhecer um pouco mais das features da ferramenta, clique aqui.
quinta-feira, 18 de junho de 2009
quarta-feira, 17 de junho de 2009
Nós pensamos diferente
Ou deveríamos, pelo menos :)
Estava há pouco lendo um artigo no Sticky Minds sobre essa capacidade de olhar de maneira diferente para as coisas. O artigo é o Are you set in your ways da Naomi Karten. Ele fala sobre um livro, o Why We Make Mistakes do Joseph Hallinan.
O livro tras explicações através de situações reais sobre como lembrar de algo que você escondeu, porque homens cometem erros e mulheres não (essa frase foi tirada do site do livro hehehehe), porque realizar várias tarefas ao mesmo tempo não é uma boa idéia, etc.
Há uma passagem do livro no site, em que um homem agride outro que estava numa cadeira de rodas, mas só percebe isso depois que o cara já estava longe. Ele olhou para o outro homem, mas não percebeu a cadeira de rodas (leia a passagem para entender). E quantas vezes não nos deparamos com errinhos que ‘vimos, mas não vimos’? Acho que esse é um bom gancho para falar da importância de revisões.
Mesmo passando corretores ortográficos nos nossos textos, mesmo lendo e relendo-os, há sempre a probabilidade de ter um erro que passamos por ele várias e várias vezes e não conseguimos enxergar. Por isso é importante o olhar de ‘alguém de fora’. Alguém que não participou desse desenvolvimento e que vai ter uma mente analítica para definir se tudo o que está escrito está correto, coerente e entendível.
Outro gancho do texto é a mente do testador (profissional de teste em geral). Um desenvolvedor pode ser um testador? Até pode. Mas não com a mente de desenvolvedor. Ele precisa trocar o chapéu e mudar uma chave no cérebro também. Calma, calma, não estou questionando a capacidade dos desenvolvedores, muito pelo contrário. Acho que muitos que conheci são capazes sim de testar adequadamente, mas o pensamento tem que ser diferente. O testador olha diferente pros requisitos. E fora isso, como eu comentei no post passado, ele precisa ter uma visão de agregar valor. Se algo pode ser melhorado, é papel de todo o time ver isso e sugerir, mas isso fica ainda mais fácil para a equipe de testes que está vendo o programa rodar, que está pensando e agindo como se fosse um usuário.
Não li o livro citado acima, mas parece bem interessante. Para quem tiver interesse:
Amazon
Cultura
E outro artigo interessante da Naomi sobre o mesmo assunto What organizations can learn (not to do) from six-year-olds
Estava há pouco lendo um artigo no Sticky Minds sobre essa capacidade de olhar de maneira diferente para as coisas. O artigo é o Are you set in your ways da Naomi Karten. Ele fala sobre um livro, o Why We Make Mistakes do Joseph Hallinan.
O livro tras explicações através de situações reais sobre como lembrar de algo que você escondeu, porque homens cometem erros e mulheres não (essa frase foi tirada do site do livro hehehehe), porque realizar várias tarefas ao mesmo tempo não é uma boa idéia, etc.
Há uma passagem do livro no site, em que um homem agride outro que estava numa cadeira de rodas, mas só percebe isso depois que o cara já estava longe. Ele olhou para o outro homem, mas não percebeu a cadeira de rodas (leia a passagem para entender). E quantas vezes não nos deparamos com errinhos que ‘vimos, mas não vimos’? Acho que esse é um bom gancho para falar da importância de revisões.
Mesmo passando corretores ortográficos nos nossos textos, mesmo lendo e relendo-os, há sempre a probabilidade de ter um erro que passamos por ele várias e várias vezes e não conseguimos enxergar. Por isso é importante o olhar de ‘alguém de fora’. Alguém que não participou desse desenvolvimento e que vai ter uma mente analítica para definir se tudo o que está escrito está correto, coerente e entendível.
Outro gancho do texto é a mente do testador (profissional de teste em geral). Um desenvolvedor pode ser um testador? Até pode. Mas não com a mente de desenvolvedor. Ele precisa trocar o chapéu e mudar uma chave no cérebro também. Calma, calma, não estou questionando a capacidade dos desenvolvedores, muito pelo contrário. Acho que muitos que conheci são capazes sim de testar adequadamente, mas o pensamento tem que ser diferente. O testador olha diferente pros requisitos. E fora isso, como eu comentei no post passado, ele precisa ter uma visão de agregar valor. Se algo pode ser melhorado, é papel de todo o time ver isso e sugerir, mas isso fica ainda mais fácil para a equipe de testes que está vendo o programa rodar, que está pensando e agindo como se fosse um usuário.
Não li o livro citado acima, mas parece bem interessante. Para quem tiver interesse:
Amazon
Cultura
E outro artigo interessante da Naomi sobre o mesmo assunto What organizations can learn (not to do) from six-year-olds
terça-feira, 16 de junho de 2009
Você não é simplesmente um profissional de TI
Chamativo o título? :)
Se você trabalha desenvolvendo software, você é um realizador de sonhos. Isso mesmo, bem filosófico, mas já parou para pensar o que REALMENTE você realiza? Esse projeto que você está exatamente agora serve pra que? Que serve pra que? Que serve pra que? (...) No fim, projetos são sonhos, ou partes de sonhos (sejam eles bons ou maus, não vou entrar nesse mérito).
O ponto que quero chegar é que deveríamos estar preocupados muito mais com o valor que estamos gerando a partir das nossas atividades do que somente (não que isso não seja essencial) realizá-las com perfeccionismo.
Um caso verídico :)
O cliente teve problemas com um fornecedor A e sondou seu outro fornecedor B ( \o/ )sobre uma possível re-análise do trabalho realizado por eles. Fui consultada nesse momento sobre a atividade e as minhas considerações.
A primeira resposta foi “Olha.. Se é simplesmente pra deixar o pessoal alocado, com atividades, é isso sim. Se for para deixar o cliente feliz, se for pra atender o que ele realmente quer, vai precisar de mais algumas outras coisas.” Ah! Isso é um problema muito sério, de tirar sono e dar muita dor de cabeça. É um verdadeiro trabalho de vidente (obviamente carregado de experiência) entregar pro cliente o que ele quer, especialmente porque num grande número de casos, nem ele sabe.
Ok, falando praticamente. O fornecedor fez um trabalho de especificação de negócio, geração de documento de padrões, casos de uso, e mais outros artefatos. Até ai parece perfeito. Exceto pela qualidade da documentação produzida que ficou deixando a desejar bastante, com requisitos que não aparecem nos casos de uso e outras atrocidades.
A pergunta era: podemos fazer uma reengenharia dos casos de uso e elaborar um documento de requisito de acordo com os nossos padrões?
Resposta de alguém focado em suas atividades, sem olho no cliente (por melhor técnico que seja): Sim.
Resposta dada: Que dá, dá. Mas pra que o cliente quer isso? Por mais que não esteja nos nossos padrões, eles têm uma especificação. A gente vai formatar dentro do template? Fazer trabalho de formatação e era isso? Porque não dá se basear só nos UCs, já que tem informação faltando neles. É melhor se basear no documento de especificação de negócio, ou seja, transcrevê-lo pro template. (Vulgo trabalho burro)
P.: Ok, e o que você sugere?
R.: Qual é o problema? Do que o cliente ta sentindo falta? Por que ele nos pediu pra fazer isso? Ele certamente não quer pagar nossas horas de consultores porque não gostou da cor do documento. Do que temos conversado em reunião e do que temos analisado com essa documentação, sabemos que o cliente não tem rastreabilidade alguma do que está sendo implementado e isso sim é um diferencial. Podemos catalogar decentemente os requisitos atribuindo IDs e outras propriedades, dentro do nosso template, mas mais que isso, podemos dar ao nosso cliente visibilidade, controle, conhecimento. Podemos dar a ele uma ferramenta de verificação se o que ele ta pedindo dos outros fornecedores está realmente sendo atendido.
Isso mesmo, uma matriz de rastreabilidade. Quem já fez isso na mão, ainda mais pra projeto grande deve estar tendo calafrios. É bem xarope mesmo. :) Feliz de quem tem ferramentas que geram isso automaticamente.
Pensem bem o valor que isso agrega! O diretor de TI do cliente XYZ tem que controlar vários fornecedores fazendo as atividades todas em separado. Um time gera especificação, outro codifica, outro gera analise de teste, outro testa e no fim o pobre do diretor não sabe se todo mundo ta usando todos os 647832483278947329 de documentos que deveriam para gerar tudo isso. O que sai no final? Só Deus sabe.
Agora imagina se ele pode ter uma ferramenta que diz pra ele: O requisito 123 está mapeado nos casos de uso A1, B2, C3 e D4. O caso de uso A1 é coberto pelos testes CTA1, CTA2, CTA3; e o B2 pelos CTB1, CTB2...
Há uma idéia bem mais concreta que o requisito realmente foi implementado. Consegue-se avaliar posteriormente o impacto de uma mudança, pode-se gerar vários indicadores como por exemplo o número de defeito por funcionalidade, avaliar a complexidade de uma funcionalidade, entre várias e várias outras coisas.
Virou um post sobre rastreabilidade :) Mas voltando ao título do post, fica um incentivo a não se limitar somente ao que lhe foi pedido para fazer. Questione, pense como fazer melhor, como gerar valor pra sua organização, pro seu cliente, pra você mesmo. Lembre-se que o que você produz vai em algum momento da cadeia estar realizando sonhos.
sexta-feira, 5 de junho de 2009
Teste no ciclo de vida de software
Aspectos básicos de teste
Conhecimentos avançados requerem conhecimentos básicos. Como o estudo da CTAL envolve ter na veia os conteúdos da CTFL, segue uma sessãozinha para relembrar, reforçar ou complementar a sua visão do lugar do profissional de teste no mundo (ou no ciclo de vida do software) :)
Teste no ciclo de vida de software
O teste deve estar intrínseco no ciclo de vida do software, seja ele seqüencial (cascata, V, W,...), iterativo (RAD, espiral,...) ou incremental (evolutivo, métodos ágeis,...). É essencial o alinhamento dessa disciplina com as outras como engenharia de requisitos, gerenciamento de projetos, gerencia de configuração e mudança, manutenção e desenvolvimento, documentação técnica, ...
Modelo Seqüencial:
Nesse modelo, o time irá definir os requisitos do sistema no início e depois gerenciar as “eventuais” mudanças que possam ocorrer (“eventuais” foi um eufemismo mesmo).
O time de testes pode se envolver no início do projeto planejando e projetando os testes através da análise das especificações dos requisitos para identificar condições de teste. Esse planejamento, análise e projeto realizados antecipadamente, favorecem a identificação de defeitos nos requisitos, fazendo do teste um processo mais preventivo que reativo. A detecção de falhas começaria mais tarde, quando os testes de sistema tiverem início (fim da fase de desenvolvimento).
Modelo Incremental:
Adotando uma metodologia ágil como Scrum, o time de teste não recebe o conjunto final e completo de requisitos no início do projeto (se é que recebem algum dia :) ). O time irá receber requisitos a cada 30 dias (ou como definido o sprint).
Nesse caso, o time pode, por exemplo, seguir uma estratégia baseada em riscos, identificando e priorizando áreas de risco, ajudando assim a montar os escopos dos sprints. Projetos e implementações de teste ocorrem logo após a execução, reduzindo a capacidade preventiva do teste. A detecção de falhas começa mais cedo, ao final de cada sprint, e continua repetidamente em ciclos curtos pelo projeto.
Lembrando que aplicação de Metodologia Ágil não quer dizer abolição de documentação!!
(Um parêntesis para o Gerenciamento de Configuração)
Independente do ciclo de vida adotado, gerenciamento de configuração e mudança é crucial para o teste. Falhas nesse processo podem resultar no impedimento de realização dos testes, invalidando as impressões sobre o que realmente está acontecendo no sistema. Pode resultar na perda de uma mudança, na impossibilidade de acertadamente definir o que foi testado e em que ponto foi testado e por em dúvida a confiabilidade do teste.
Saiu na Testing Experience uma matéria sobre isso. Bem cara de pau, eu vou copiar o início da matéria para dar o gostinho:
“A lei número 1 da Engenharia de Software é: ’Não importa onde você está no ciclo de vida do sistema, o sistema irá mudar, e o desejo de mudá-lo persistirá por todo o ciclo’ – Bersoff, et al, 1980"
A matéria está na 6ª edição!
Níveis de teste introduzidos no Syllabus Advanced
No Syllabus Advanced, são introduzidos os níveis de teste:
- Hardware-Software integration testing
- System integration testing
- Feature interaction testing
- Customer Product integration testing
E cada nível (não só esses, mas também todos os outros do Syllabus Foundation) deve ter:
- Objetivos
- Escopo
- Rastreabilidade para a base de teste
- Critérios de entrada e saída
- Artefatos 'entregáveis', incluindo relatórios
- Técnicas de teste
- Métricas e medidas
- Ferramentas de teste
- Conformidade com os padrões da organização e outros padrões
E assim termina o primeiro resuminho da introdução do syllabus (também com base no Advanced Software Testing Vol.1 do Rex Black.
Conhecimentos avançados requerem conhecimentos básicos. Como o estudo da CTAL envolve ter na veia os conteúdos da CTFL, segue uma sessãozinha para relembrar, reforçar ou complementar a sua visão do lugar do profissional de teste no mundo (ou no ciclo de vida do software) :)
Teste no ciclo de vida de software
O teste deve estar intrínseco no ciclo de vida do software, seja ele seqüencial (cascata, V, W,...), iterativo (RAD, espiral,...) ou incremental (evolutivo, métodos ágeis,...). É essencial o alinhamento dessa disciplina com as outras como engenharia de requisitos, gerenciamento de projetos, gerencia de configuração e mudança, manutenção e desenvolvimento, documentação técnica, ...
Modelo Seqüencial:
Nesse modelo, o time irá definir os requisitos do sistema no início e depois gerenciar as “eventuais” mudanças que possam ocorrer (“eventuais” foi um eufemismo mesmo).
O time de testes pode se envolver no início do projeto planejando e projetando os testes através da análise das especificações dos requisitos para identificar condições de teste. Esse planejamento, análise e projeto realizados antecipadamente, favorecem a identificação de defeitos nos requisitos, fazendo do teste um processo mais preventivo que reativo. A detecção de falhas começaria mais tarde, quando os testes de sistema tiverem início (fim da fase de desenvolvimento).
Modelo Incremental:
Adotando uma metodologia ágil como Scrum, o time de teste não recebe o conjunto final e completo de requisitos no início do projeto (se é que recebem algum dia :) ). O time irá receber requisitos a cada 30 dias (ou como definido o sprint).
Nesse caso, o time pode, por exemplo, seguir uma estratégia baseada em riscos, identificando e priorizando áreas de risco, ajudando assim a montar os escopos dos sprints. Projetos e implementações de teste ocorrem logo após a execução, reduzindo a capacidade preventiva do teste. A detecção de falhas começa mais cedo, ao final de cada sprint, e continua repetidamente em ciclos curtos pelo projeto.
Lembrando que aplicação de Metodologia Ágil não quer dizer abolição de documentação!!
(Um parêntesis para o Gerenciamento de Configuração)
Independente do ciclo de vida adotado, gerenciamento de configuração e mudança é crucial para o teste. Falhas nesse processo podem resultar no impedimento de realização dos testes, invalidando as impressões sobre o que realmente está acontecendo no sistema. Pode resultar na perda de uma mudança, na impossibilidade de acertadamente definir o que foi testado e em que ponto foi testado e por em dúvida a confiabilidade do teste.
Saiu na Testing Experience uma matéria sobre isso. Bem cara de pau, eu vou copiar o início da matéria para dar o gostinho:
“A lei número 1 da Engenharia de Software é: ’Não importa onde você está no ciclo de vida do sistema, o sistema irá mudar, e o desejo de mudá-lo persistirá por todo o ciclo’ – Bersoff, et al, 1980"
A matéria está na 6ª edição!
Níveis de teste introduzidos no Syllabus Advanced
No Syllabus Advanced, são introduzidos os níveis de teste:
- Hardware-Software integration testing
- System integration testing
- Feature interaction testing
- Customer Product integration testing
E cada nível (não só esses, mas também todos os outros do Syllabus Foundation) deve ter:
- Objetivos
- Escopo
- Rastreabilidade para a base de teste
- Critérios de entrada e saída
- Artefatos 'entregáveis', incluindo relatórios
- Técnicas de teste
- Métricas e medidas
- Ferramentas de teste
- Conformidade com os padrões da organização e outros padrões
E assim termina o primeiro resuminho da introdução do syllabus (também com base no Advanced Software Testing Vol.1 do Rex Black.
sexta-feira, 29 de maio de 2009
Testing Experience Magazine – The new ISTQB® Certified Tester Advanced Level Focus on practical know-how by Professor Mario Winter
Notícia quentinha, saída do forno! Saiu a sexta edição da Testing Experience. Pra quem não conhece ainda, trata-se de uma revista especializada em teste de software de periodicidade trimestral, com artigos bastante interessantes. Para pegar a sua, basta se inscrever no site e fazer o download free da versão virtual.
Resumo da 6ª edição
A última matéria da revista é a que dá título a esse post, escrita por Mario Winter que dentre os vários itens interessantes do seu currículo, guarda o título de membro fundador do Board da Alemanha.
A matéria é bem focada na realidade da Alemanha, falando sobre quando começa a ser aplicado o novo formato lá e outras informações mais direcionadas. O que eu colhi de mais significativo da matéria:
O syllabus sofreu uma modificação considerável em 2007 (comparado a versão anterior de 2003), chegando a triplicar de tamanho (de 38 para 114 páginas) e isso se deve ao cunho prático adotado nessa nova versão. Isso também significa que os cursos têm maior duração, obviamente.
O trabalho de padronização do syllabus está sendo mundial. Todos os Boards estão contribuindo e sendo afetados por essa padronização que só trás ganhos como a unificação do uso de terminologias específicas em projetos offshore.
O uso de habilidades analíticas está sendo mais bem explorado como no exemplo dado na matéria: As figuras apresentadas indicam que determinado projeto e produto estão atrasados. Qual a explicação desse atraso e que passos devem ser tomados para recolocar o projeto no planejamento de cronograma?
As três áreas de conhecimento estão bem dividas explicitando a especialização natural da profissão. Para gerentes de teste, é necessário conhecimento para responder perguntas como ‘Como medir os benefícios do teste para o negócio?’; ‘O que é FMEA (Análise de Modo e Efeitos de Falhas) e como isso pode ser implementado?’. Para analista e analista técnico o foco se dá em técnicas baseadas em especificação, estrutura, erro e experiência; sendo o analista focado nas de especificação, erro e experiência e o técnico devendo executar bem todas elas, exceto algumas de especificação.
Também na matéria é citada uma lista de indicações de livros do site do GTB (German Testing Board) que me parece muito proveitosa. É uma excelente dica de manutenção de conhecimento.
Vale a pena dar uma conferida na revista não só por esta, mas por todas as outras matérias. E se você não a acompanhava, vale a pena passar a acompanhar.
Abs,
Resumo da 6ª edição
A última matéria da revista é a que dá título a esse post, escrita por Mario Winter que dentre os vários itens interessantes do seu currículo, guarda o título de membro fundador do Board da Alemanha.
A matéria é bem focada na realidade da Alemanha, falando sobre quando começa a ser aplicado o novo formato lá e outras informações mais direcionadas. O que eu colhi de mais significativo da matéria:
O syllabus sofreu uma modificação considerável em 2007 (comparado a versão anterior de 2003), chegando a triplicar de tamanho (de 38 para 114 páginas) e isso se deve ao cunho prático adotado nessa nova versão. Isso também significa que os cursos têm maior duração, obviamente.
O trabalho de padronização do syllabus está sendo mundial. Todos os Boards estão contribuindo e sendo afetados por essa padronização que só trás ganhos como a unificação do uso de terminologias específicas em projetos offshore.
O uso de habilidades analíticas está sendo mais bem explorado como no exemplo dado na matéria: As figuras apresentadas indicam que determinado projeto e produto estão atrasados. Qual a explicação desse atraso e que passos devem ser tomados para recolocar o projeto no planejamento de cronograma?
As três áreas de conhecimento estão bem dividas explicitando a especialização natural da profissão. Para gerentes de teste, é necessário conhecimento para responder perguntas como ‘Como medir os benefícios do teste para o negócio?’; ‘O que é FMEA (Análise de Modo e Efeitos de Falhas) e como isso pode ser implementado?’. Para analista e analista técnico o foco se dá em técnicas baseadas em especificação, estrutura, erro e experiência; sendo o analista focado nas de especificação, erro e experiência e o técnico devendo executar bem todas elas, exceto algumas de especificação.
Também na matéria é citada uma lista de indicações de livros do site do GTB (German Testing Board) que me parece muito proveitosa. É uma excelente dica de manutenção de conhecimento.
Vale a pena dar uma conferida na revista não só por esta, mas por todas as outras matérias. E se você não a acompanhava, vale a pena passar a acompanhar.
Abs,
quinta-feira, 28 de maio de 2009
CTAL Inside
A certificação Advanced Level da ISTQB é direcionada para pessoas que já tem experiência em teste de software (testadores, analistas, gerente, consultores de teste) ou que estejam interessadas em aprofundar seus conhecimentos na área (gerentes de projeto, de desenvolvimento, de qualidade, analistas, diretores de TI). Para ter a certificação é necessário ter a CTFL e atender aos requisitos do Exam Board que valida se o candidato tem experiência prática suficiente para ser considerado um profissional Advanced Level (3 anos de experiência em teste de software, desenvolvimento, garantia da qualidade ou similar).
Taxas (Aplicadas nos Estados Unidos):
US$200,00 para a prova e US$100,00 para o exame de qualificação
Especialidades
* Advanced Level Test Analyst
* Advanced Level Test Manager
* Advanced Level Technical Test Analyst
Objetivos da certificação
Assegurar entendimento e execução de técnicas atuais e inovadoras por profissionais de teste experientes
Apoiar/Incentivar o desenvolvimento profissional
Servir de guia na profissão de teste
Conhecimentos avaliados
Técnicas avançadas de testes funcionais para testadores e programadores, conceitos contemporâneos de gerenciamento de testes, melhoria de processo, automação de testes, performance, usabilidade e outros tipos de testes não funcionais.
Cursos
Segundo o ASTQB, um curso para as 3 especialidades levaria em torno de 15 a 20 dias de duração. Que eu conheça, não tem cursos para CTAL no Brasil ainda. :)
A prova
São 65 questões do tipo múltipla escolha
É necessária pontuação acima ou igual a 65%
O tempo de prova é de 3h
Hoje no Brasil a prova não é aplicada, como comentei no post anterior. A BSTQB está em processo de tradução do syllabus.
Sugestão: Acompanhar a lista de discussão da BSTQB
Processo de certificação (descrito no ASTQB)
É recomendado inscrever-se com alguns dias de antecedência para que sejam avaliadas as documentações. Será paga a taxa de qualificação e deve ser enviada uma cópia do certificado da CTFL e um currículo ou comprovação da experiência de 3 anos ou mais na área, como citado acima.
O candidato será informado da sua aceitação, assim como o centro de exames. Se o candidato estiver em treinamento, o centro de treinamento também será informado.
Se o processo de avaliação não for completado até a data de aplicação da prova, o candidato poderá fazer a prova desde que tenham sido pagas as taxas de qualificação e da prova. Entretanto o resultado só será divulgado após a avaliação de qualificação.
Se o candidato não passar na qualificação, o valor pago não será devolvido, entretanto essa taxa servirá como crédito para futuras tentativas de realização do exame.
Fonte: http://www.astqb.org/
Taxas (Aplicadas nos Estados Unidos):
US$200,00 para a prova e US$100,00 para o exame de qualificação
Especialidades
* Advanced Level Test Analyst
* Advanced Level Test Manager
* Advanced Level Technical Test Analyst
Objetivos da certificação
Assegurar entendimento e execução de técnicas atuais e inovadoras por profissionais de teste experientes
Apoiar/Incentivar o desenvolvimento profissional
Servir de guia na profissão de teste
Conhecimentos avaliados
Técnicas avançadas de testes funcionais para testadores e programadores, conceitos contemporâneos de gerenciamento de testes, melhoria de processo, automação de testes, performance, usabilidade e outros tipos de testes não funcionais.
Cursos
Segundo o ASTQB, um curso para as 3 especialidades levaria em torno de 15 a 20 dias de duração. Que eu conheça, não tem cursos para CTAL no Brasil ainda. :)
A prova
São 65 questões do tipo múltipla escolha
É necessária pontuação acima ou igual a 65%
O tempo de prova é de 3h
Hoje no Brasil a prova não é aplicada, como comentei no post anterior. A BSTQB está em processo de tradução do syllabus.
Sugestão: Acompanhar a lista de discussão da BSTQB
Processo de certificação (descrito no ASTQB)
É recomendado inscrever-se com alguns dias de antecedência para que sejam avaliadas as documentações. Será paga a taxa de qualificação e deve ser enviada uma cópia do certificado da CTFL e um currículo ou comprovação da experiência de 3 anos ou mais na área, como citado acima.
O candidato será informado da sua aceitação, assim como o centro de exames. Se o candidato estiver em treinamento, o centro de treinamento também será informado.
Se o processo de avaliação não for completado até a data de aplicação da prova, o candidato poderá fazer a prova desde que tenham sido pagas as taxas de qualificação e da prova. Entretanto o resultado só será divulgado após a avaliação de qualificação.
Se o candidato não passar na qualificação, o valor pago não será devolvido, entretanto essa taxa servirá como crédito para futuras tentativas de realização do exame.
Fonte: http://www.astqb.org/
quarta-feira, 20 de maio de 2009
Apresentação do Blog - CTAL
Bem vindos ao Ensaios de Qualidade
O objetivo desse blog pra mim é o de aprender um pouco mais tentando passar alguns conhecimentos e experiências na área de qualidade de software, especialmente testes de software.
O motor de início é a CTAL, certificação de testes para a qual estou estudando no momento. Antes de falar sobre a certificação e essa escolha, quero indicar um post bastante famoso do Fábio Martinho com um resumo das principais certificações da área no mercado no site Test Expert
CTAL (Certified Tester Advanced Level) é a certificação do ISTQB para níveis avançados. São oferecidas as especialidades ‘Test Analyst’, ‘Test Manager’ e ‘Technical Test Analyst’. O conjunto dessas três certificações dá ao profissional o diploma CTAL Full Advanced Level. O meu foco, por hora, será na especialidade Test Analyst e como base de estudos, fora o syllabus, estou usando o livro Guide to the ISTQB Advanced Certification as an Advanced Test Analyst do Rex Black
E como se faz pra tirar essa certificação?
O primeiro passo é tirar a CTFL, que é a certificação Foundation Level da ISTQB. No Brasil, ela é aplicada pelo BSTQB ou pela ISEB através de um centro Prometric.
E, segundo o ASTQB, três anos de experiência comprovada em teste de software, desenvolvimento, garantia da qualidade, engenharia de sistemas ou funções relacionadas.
E porque eu estou usando o ASTQB como referência e não o BSTQB? Porque atualmente nenhuma CTAL é aplicada no Brasil. Ao que venho acompanhando, o syllabus está em processo de tradução. A minha expectativa é poder fazer essa certificação ainda esse ano. Caso os planos mudem, com certeza vai dar pra acompanhar por aqui. :)
E dentre todas aquelas certificações que o Fábio apresentou no post dele, porque eu escolhi a CTAL? Bem, antes de escolher a CTAL, na realidade eu escolhi a CTFL. Eu precisava de uma certificação em testes por uma demanda profissional e além de ser uma certificação internacional, eu tinha a comodidade de escolher quando fazer a CTFL, já que é possível fazer a prova por um centro Prometric. Então providenciei um material para estudar: Foundations of Software Testing: ISTQB Certification de Dorothy Graham, Erik Van Veenendaal, Isabel Evans e Rex Black, agendei a prova e já sai na hora com o meu resultado da sala.
Os estudos então continuam e o próximo objetivo é a CTAL. Espero que a manutenção do blog além de me ajudar a focar nos estudos para a certificação, possa ajudar os transeuntes com alguns assuntos interessantes que pretendo compartilhar nesse canal.
Abs,
O objetivo desse blog pra mim é o de aprender um pouco mais tentando passar alguns conhecimentos e experiências na área de qualidade de software, especialmente testes de software.
O motor de início é a CTAL, certificação de testes para a qual estou estudando no momento. Antes de falar sobre a certificação e essa escolha, quero indicar um post bastante famoso do Fábio Martinho com um resumo das principais certificações da área no mercado no site Test Expert
CTAL (Certified Tester Advanced Level) é a certificação do ISTQB para níveis avançados. São oferecidas as especialidades ‘Test Analyst’, ‘Test Manager’ e ‘Technical Test Analyst’. O conjunto dessas três certificações dá ao profissional o diploma CTAL Full Advanced Level. O meu foco, por hora, será na especialidade Test Analyst e como base de estudos, fora o syllabus, estou usando o livro Guide to the ISTQB Advanced Certification as an Advanced Test Analyst do Rex Black
E como se faz pra tirar essa certificação?
O primeiro passo é tirar a CTFL, que é a certificação Foundation Level da ISTQB. No Brasil, ela é aplicada pelo BSTQB ou pela ISEB através de um centro Prometric.
E, segundo o ASTQB, três anos de experiência comprovada em teste de software, desenvolvimento, garantia da qualidade, engenharia de sistemas ou funções relacionadas.
E porque eu estou usando o ASTQB como referência e não o BSTQB? Porque atualmente nenhuma CTAL é aplicada no Brasil. Ao que venho acompanhando, o syllabus está em processo de tradução. A minha expectativa é poder fazer essa certificação ainda esse ano. Caso os planos mudem, com certeza vai dar pra acompanhar por aqui. :)
E dentre todas aquelas certificações que o Fábio apresentou no post dele, porque eu escolhi a CTAL? Bem, antes de escolher a CTAL, na realidade eu escolhi a CTFL. Eu precisava de uma certificação em testes por uma demanda profissional e além de ser uma certificação internacional, eu tinha a comodidade de escolher quando fazer a CTFL, já que é possível fazer a prova por um centro Prometric. Então providenciei um material para estudar: Foundations of Software Testing: ISTQB Certification de Dorothy Graham, Erik Van Veenendaal, Isabel Evans e Rex Black, agendei a prova e já sai na hora com o meu resultado da sala.
Os estudos então continuam e o próximo objetivo é a CTAL. Espero que a manutenção do blog além de me ajudar a focar nos estudos para a certificação, possa ajudar os transeuntes com alguns assuntos interessantes que pretendo compartilhar nesse canal.
Abs,
Assinar:
Postagens (Atom)