Estou de volta. Dei um tempo no blog para organizar o casamento, sair de férias e quando voltei, voltei no projeto a mil! Agora em 2011, espero retomar o pique dos posts.
Primeiro, um 2011 cheio de realizações para todos! :)
E falando em realizações e conquistas, em 2010 eu tirei a CTAL-TA. Quando criei o blog, a idéia era ir me preparando para a prova e postando aqui o material que eu ia lendo e compartilhando esse preparo, mas muitas coisas aconteceram. O trabalho não deu muita folga e mesmo o m eu planejamento inicial não foi muito seguido.
O que eu usei para me preparar? Apenas li o livro Advanced Software Testing do Rex Black que indiquei aqui no blog.
O livro é bem legal. O ponto que ele peca um pouco, em minha opinião, é no detalhamento de resoluções de questões relativas a técnicas de análise. No mais, é um excelente guia.
Não li o Syllabus. Mas não recomendo essa prática, afinal é o material oficial da CTAL.
Sobre simulados, baixei alguns no VTB (Vietnamese Testing Board), mas só resolvi um que tinha gabarito. Não vejo sentido em resolver sem ter certeza se está correto ou não.
Eu achei os simulados do Advanced Software Testing bem legais. Pra CTFL também só usei o Foundations of Software Testing.
O que eu achei do nível da prova? Tem perguntas bem fáceis, como as questões de ética e questões sobre definição de PDCA, auditoria, etc. Tem perguntas mais chatinhas de responder como quantidade de testes que devem ser feitos em determinado cenário aplicando as técnicas A e B (tem essas perguntas para treinar no Advanced Software Testing).
Quais pontos eu acho que fui pior e podia ter me dedicado mais? Tem várias normas citadas no livro. Não só as IEEE e ISO, mas também as BS e DO. Se tivesse tido mais tempo para estudar teria baixado as normas e lido.
Quanto tempo eu dediquei para estudar? Comecei o blog em maio/2009, mas não posso dizer que venho estudando desde então. Li o livro até a parte de Análise por Valor Limite, que eu postei em março/2010. Depois parei de ler o livro. Ainda não haviam marcado a CTAL no Brasil, eu estava sem perspectiva de fazer a prova fora do BSTQB e sem um prazo, fiquei desmotivada. Quando voltei de viagem de lua de mel, estava na última semana para me inscrever na prova e só depois da confirmação retomei a minha leitura. Mas como havia iniciado há muito tempo, resolvi começar do começo. Lógico que não deu tempo de ler o livro inteiro. Li até o quarto capitulo, e os seguintes eu apenas resolvi as questões do simulado que tem no final. No total eu diria que foi algo em torno de 1 mês se eu fosse por em tempo produtivo.
Qual a minha visão geral da prova? Assim como a CTFL, acredito que se você é uma pessoa que freqüenta eventos de teste, está atualizado com os conceitos, técnicas, anda visitando os blogs, participando de listas de discussão, não fica acomodado em mundos que muitas vezes são restritos no trabalho, há grandes chances de passar sem surtar estudando. Claro que vale a pena dedicar um tempo para o estudo, não é uma prova tão trivial quanto a CTFL. Se você não achou a CTFL fácil, então estude o dobro pra CTAL, senão não passa.
O que eu recomendo? Já me mandaram emails perguntando isso. Bom, primeiro eu fiz um relato de como foi PRA MIM. Não quer dizer que vai ser assim para todos. Outros que fizeram a CTAL podem ter opiniões diferentes, claro. Não recomendo fazer o meu plano de estudo (até porque não segui nenhum). Recomendo o leitura do Syllabus, do Advanced Software Testing e resolução de simulados, que como comentei tem alguns no Vietnamese Testing Board. Também acho um bom caminho se preparar como se fosse fazer o ISEB Intermediate. Eu não fiz essa prova, mas pode ser um bom passo intermediário para quem quer ter mais certeza do seu preparo antes da CTAL. O ISEB segue a mesma linha do ISTQB e a CTFL vale como certificação inicial para ambos os boards.
É isso. Boa sorte para o pessoal que vai fazer a CTAL na próxima prova.
Mostrando postagens com marcador ISTQB. Mostrar todas as postagens
Mostrando postagens com marcador ISTQB. Mostrar todas as postagens
domingo, 2 de janeiro de 2011
domingo, 5 de julho de 2009
Estudo CTAL: Processo de Teste
No Advanced Software Testing Vol 1 do Rex Black, processo de teste está no segundo capítulo. Segue abaixo um overview desse capítulo.
**
O processo de teste consiste em:
-- Planejar e Acompanhar
-- Analisar e Projetar
-- Implementar e Executar
-- Avaliar critérios de saída e reportar resultados do teste
-- Atividades de fechamento de teste
O foco do livro é dado nas 3 atividades do meio.
Análise e Projeto de Teste
Nas atividades de planejamento, o líder de teste e o gerente de teste trabalham junto aos stakeholders na definição dos objetivos de teste. No template IEEE 829, essa informação fica documentada em “Features to be tested”.
Um pouco mais sobre documentação e norma IEEE 829 em:
- Sem Bugs – Como documentar seus testes
- ANSI/IEEE 829-1983 IEEE Standard for Software Test Documentation –Description
A partir dos objetivos de teste, na fase de análise e projeto, são desenvolvidas as atividades de:
-- Identificar e refinar as condições de teste para cada objetivo de teste
-- Criar casos de teste que exercitem as condições de teste identificadas
Saber o que testar, ainda não é suficiente. É preciso saber em que ordem e o quanto. Para que as áreas mais importantes sejam testadas primeiramente e o esforço de teste seja mais efetivo e eficiente, é preciso priorizar as condições de teste.
Essa definição de prioridades normalmente envolve a determinação do impacto e da probabilidade de um risco de qualidade (Conceito aplicado em estratégia baseada em risco – que fica pra outro post).
Durante o processo, as condições de teste e o risco associado a elas pode mudar conforme as necessidades (ou entendimento das necessidades) do projeto. Essas atividades de priorização e re-priorização ocorrem durante todo o ciclo, da análise e projeto, à implementação e execução, e influencia na avaliação dos critérios de saída e report de resultados.
Objetivos de testes funcionais
Objetivos de teste funcionais podem ser aplicados durante todo o ciclo, em qualquer nível de teste. É importante testar os principais objetivos de teste primeiro para não se deparar com falhas muito graves ao final da execução.
No livro há um exemplo de um vídeo game e a funcionalidade de salvar e resumir o jogo. Um exemplo que eu gosto de usar é o de um telefone celular. Qualquer aplicação para celular deve ser capaz de tratar uma ligação. Ele deve ser interrompido para que o usuário receba a ligação e deve continuar após o término da ligação. Receber uma ligação é a funcionalidade principal do telefone (mesmo que hoje em dia eles praticamente cozinhem pra você), e quem está ligando não pode receber uma mensagem de indisponibilidade porque você está consultando sua agenda, ou porque está jogando, ou usando a calculadora. Esse é um teste que deve estar nos testes unitários, de integração, de sistema e de aceitação. Todos dando uma especial atenção a esse objetivo de teste. Lembrando que o teste começa ainda antes, na revisão de requisitos, de projeto e de código.
Posteriormente no livro é detalhada a estratégia baseada em riscos. Se você não está usando essa estratégia, você necessitará selecionar as entradas e técnicas de acordo com a estratégia utilizada, que claro, deve estar alinhada com o plano de teste, com as políticas de teste, etc.
Há duas escolhas importantes no processo de identificar e documentar as condições de teste:
- O nível de detalhamento das condições de teste na documentação
- A estrutura da documentação para as condições de teste
Há várias maneiras de se estruturar as condições de testes. Uma delas pode ser um paralelismo com a documentação base. Por exemplo, se a sua empresa trabalha com requisitos de marketing e especificações de requisitos, entende-se usualmente que o primeiro é uma descrição alto nível e o segundo, baixo nível. Assim, com base nesses documentos, você pode criar uma estrutura de condições de teste alto nível e uma em baixo nível equivalentemente.
Outra abordagem envolve a análise dos riscos de qualidade, identificando esses riscos para cada funcionalidade e assim temos as condições de teste.
O importante é que o nível de detalhamento deve estar alinhado com a estratégia de testes, que deve estar alinhada com o plano, que está alinhado com as políticas,...
Aproveite para criar a rastreabilidade nesse momento. É sempre mais fácil do que tentar criá-la numa abordagem bottom-up.
Tendo as condições de teste documentadas, o próximo passo é, normalmente, escrever os casos de teste. Há estratégias reativas discutidas no syllabus Foundation que nem sempre têm casos de teste documentados. Esses testes serão escritos utilizando técnicas que serão abordadas posteriormente.
Para os casos de teste, também deverá ser selecionado um nível e uma estrutura que deve ter todo o alinhamento já mencionado acima.
O processo de design depende agora das técnicas selecionadas para o projeto do caso de teste, mas em linhas gerais pode-se dizer que ele contém:
- Pré-condições
- Requisitos de ambiente
- Entradas de teste e outros requisitos de dados para o teste
- Resultados esperados
- Pós-condições
Definir os resultados esperados pode não ser tão trivial, especialmente considerando que esses resultados nem sempre são saídas na tela, mas condições de dados ou de ambiente. Para acuracidade dessa definição usamos o oráculo de teste.
Oráculo de teste
É a fonte que usamos para determinar o resultado esperado de um teste. Podem ser requisitos, um manual, um especialista,... Só não pode ser o código, ou a validade do teste estará comprometida. Seria o mesmo que testar o compilador.
Agora se você está achando que esse oráculo é uma especificação detalhada de testes, para a qual os resultados podem ser perfeitamente mapeáveis, isso é quase uma utopia. Normalmente essas fontes são superficiais, vagas, ambíguas e no caso de mais uma fonte, às vezes contraditórias. É preciso acrescer a elas experiência e um pouco de pessimismo profissional. Isso não acontece apenas no nível de sistema, mas em todos os outros níveis de teste.
Quem nunca teve a experiência de brincar de ping-pong com um bug? Vai pro teste, vai pro dev, vai pro teste, vai pro dev,... Isso decorre muitas vezes da ausência de um oráculo estável e confiável.
Padrões
Especificação de design de teste da IEEE 829:
Nele é descrita uma coleção de casos de teste e as condições de teste que ele cobre num alto nível. Inclui as seguintes seções:
- Identificador da especificação de teste
- Funcionalidades que serão testadas
- Refinamento de abordagem (técnicas específicas, ferramentas, etc)
- Identificação do teste
- Critério de validação (como determinar se a funcionalidade passou ou não no teste)
Essa coleção de testes descrita na especificação de design é também chamada de suíte de teste.
Especificação de casos de teste IEEE 829:
Detalha o caso de teste. Inclui as seguintes seções:
- Identificador da especificação de teste
- Itens de teste (o que vai ser entregue e testado)
- Especificações de entrada (arquivos, entradas do usuário, etc)
- Especificações de saída (resultados esperados, telas, arquivos, etc)
- Requisitos de ambiente (software, hardware, pessoal, etc)
- Requisitos procedurais especiais (permissões, intervenção do operador, etc)
- Dependência entre casos (se necessário para definir as pré-condições)
Casos de teste variam em esforço, duração, número de condições cobertas e podem ser escritos de maneiras diferentes.
ISO 9126:
Esse padrão determina seis características de qualidade de software: funcionalidade, confiabilidade, usabilidade, eficiência, manutenabilidade e portabilidade. Cada característica tem 3 ou mais sub-características. Vide figura abaixo.
O foco da certificação é na funcionalidade, os demais são considerados testes não funcionais, mas alguma dessas características pode sim vir a intervir no teste funcional.
Testes estáticos
São as inspeções, revisões. Todos conhecem a clássica curva de custo de detecção de um defeito ao longo das fases do projeto, certo? Tem um post do Fernando Palma sobre o assunto com uma figurinha do custo da não qualidade.
Fazer a análise e o projeto de teste em cima de uma especificação pode ser a própria revisão.
Métricas
Nessa parte do processo é possível medir:
- percentual de requisitos cobertos pelas condições de teste
- percentual de condições de teste cobertas pelos casos de teste
- número de defeitos encontrados na fase de análise e projeto de teste
Próximo post CTAL-related será sobre Implementação e Execução, continuando o fluxo do processo de teste.
Glossário de termos usados
**
O processo de teste consiste em:
-- Planejar e Acompanhar
-- Analisar e Projetar
-- Implementar e Executar
-- Avaliar critérios de saída e reportar resultados do teste
-- Atividades de fechamento de teste
O foco do livro é dado nas 3 atividades do meio.
Análise e Projeto de Teste
Nas atividades de planejamento, o líder de teste e o gerente de teste trabalham junto aos stakeholders na definição dos objetivos de teste. No template IEEE 829, essa informação fica documentada em “Features to be tested”.
Um pouco mais sobre documentação e norma IEEE 829 em:
- Sem Bugs – Como documentar seus testes
- ANSI/IEEE 829-1983 IEEE Standard for Software Test Documentation –Description
A partir dos objetivos de teste, na fase de análise e projeto, são desenvolvidas as atividades de:
-- Identificar e refinar as condições de teste para cada objetivo de teste
-- Criar casos de teste que exercitem as condições de teste identificadas
Saber o que testar, ainda não é suficiente. É preciso saber em que ordem e o quanto. Para que as áreas mais importantes sejam testadas primeiramente e o esforço de teste seja mais efetivo e eficiente, é preciso priorizar as condições de teste.
Essa definição de prioridades normalmente envolve a determinação do impacto e da probabilidade de um risco de qualidade (Conceito aplicado em estratégia baseada em risco – que fica pra outro post).
Durante o processo, as condições de teste e o risco associado a elas pode mudar conforme as necessidades (ou entendimento das necessidades) do projeto. Essas atividades de priorização e re-priorização ocorrem durante todo o ciclo, da análise e projeto, à implementação e execução, e influencia na avaliação dos critérios de saída e report de resultados.
Objetivos de testes funcionais
Objetivos de teste funcionais podem ser aplicados durante todo o ciclo, em qualquer nível de teste. É importante testar os principais objetivos de teste primeiro para não se deparar com falhas muito graves ao final da execução.
No livro há um exemplo de um vídeo game e a funcionalidade de salvar e resumir o jogo. Um exemplo que eu gosto de usar é o de um telefone celular. Qualquer aplicação para celular deve ser capaz de tratar uma ligação. Ele deve ser interrompido para que o usuário receba a ligação e deve continuar após o término da ligação. Receber uma ligação é a funcionalidade principal do telefone (mesmo que hoje em dia eles praticamente cozinhem pra você), e quem está ligando não pode receber uma mensagem de indisponibilidade porque você está consultando sua agenda, ou porque está jogando, ou usando a calculadora. Esse é um teste que deve estar nos testes unitários, de integração, de sistema e de aceitação. Todos dando uma especial atenção a esse objetivo de teste. Lembrando que o teste começa ainda antes, na revisão de requisitos, de projeto e de código.
Posteriormente no livro é detalhada a estratégia baseada em riscos. Se você não está usando essa estratégia, você necessitará selecionar as entradas e técnicas de acordo com a estratégia utilizada, que claro, deve estar alinhada com o plano de teste, com as políticas de teste, etc.
Há duas escolhas importantes no processo de identificar e documentar as condições de teste:
- O nível de detalhamento das condições de teste na documentação
- A estrutura da documentação para as condições de teste
Há várias maneiras de se estruturar as condições de testes. Uma delas pode ser um paralelismo com a documentação base. Por exemplo, se a sua empresa trabalha com requisitos de marketing e especificações de requisitos, entende-se usualmente que o primeiro é uma descrição alto nível e o segundo, baixo nível. Assim, com base nesses documentos, você pode criar uma estrutura de condições de teste alto nível e uma em baixo nível equivalentemente.
Outra abordagem envolve a análise dos riscos de qualidade, identificando esses riscos para cada funcionalidade e assim temos as condições de teste.
O importante é que o nível de detalhamento deve estar alinhado com a estratégia de testes, que deve estar alinhada com o plano, que está alinhado com as políticas,...
Aproveite para criar a rastreabilidade nesse momento. É sempre mais fácil do que tentar criá-la numa abordagem bottom-up.
Tendo as condições de teste documentadas, o próximo passo é, normalmente, escrever os casos de teste. Há estratégias reativas discutidas no syllabus Foundation que nem sempre têm casos de teste documentados. Esses testes serão escritos utilizando técnicas que serão abordadas posteriormente.
Para os casos de teste, também deverá ser selecionado um nível e uma estrutura que deve ter todo o alinhamento já mencionado acima.
O processo de design depende agora das técnicas selecionadas para o projeto do caso de teste, mas em linhas gerais pode-se dizer que ele contém:
- Pré-condições
- Requisitos de ambiente
- Entradas de teste e outros requisitos de dados para o teste
- Resultados esperados
- Pós-condições
Definir os resultados esperados pode não ser tão trivial, especialmente considerando que esses resultados nem sempre são saídas na tela, mas condições de dados ou de ambiente. Para acuracidade dessa definição usamos o oráculo de teste.
Oráculo de teste
É a fonte que usamos para determinar o resultado esperado de um teste. Podem ser requisitos, um manual, um especialista,... Só não pode ser o código, ou a validade do teste estará comprometida. Seria o mesmo que testar o compilador.
Agora se você está achando que esse oráculo é uma especificação detalhada de testes, para a qual os resultados podem ser perfeitamente mapeáveis, isso é quase uma utopia. Normalmente essas fontes são superficiais, vagas, ambíguas e no caso de mais uma fonte, às vezes contraditórias. É preciso acrescer a elas experiência e um pouco de pessimismo profissional. Isso não acontece apenas no nível de sistema, mas em todos os outros níveis de teste.
Quem nunca teve a experiência de brincar de ping-pong com um bug? Vai pro teste, vai pro dev, vai pro teste, vai pro dev,... Isso decorre muitas vezes da ausência de um oráculo estável e confiável.
Padrões
Especificação de design de teste da IEEE 829:
Nele é descrita uma coleção de casos de teste e as condições de teste que ele cobre num alto nível. Inclui as seguintes seções:
- Identificador da especificação de teste
- Funcionalidades que serão testadas
- Refinamento de abordagem (técnicas específicas, ferramentas, etc)
- Identificação do teste
- Critério de validação (como determinar se a funcionalidade passou ou não no teste)
Essa coleção de testes descrita na especificação de design é também chamada de suíte de teste.
Especificação de casos de teste IEEE 829:
Detalha o caso de teste. Inclui as seguintes seções:
- Identificador da especificação de teste
- Itens de teste (o que vai ser entregue e testado)
- Especificações de entrada (arquivos, entradas do usuário, etc)
- Especificações de saída (resultados esperados, telas, arquivos, etc)
- Requisitos de ambiente (software, hardware, pessoal, etc)
- Requisitos procedurais especiais (permissões, intervenção do operador, etc)
- Dependência entre casos (se necessário para definir as pré-condições)
Casos de teste variam em esforço, duração, número de condições cobertas e podem ser escritos de maneiras diferentes.
ISO 9126:
Esse padrão determina seis características de qualidade de software: funcionalidade, confiabilidade, usabilidade, eficiência, manutenabilidade e portabilidade. Cada característica tem 3 ou mais sub-características. Vide figura abaixo.
O foco da certificação é na funcionalidade, os demais são considerados testes não funcionais, mas alguma dessas características pode sim vir a intervir no teste funcional.
Testes estáticos
São as inspeções, revisões. Todos conhecem a clássica curva de custo de detecção de um defeito ao longo das fases do projeto, certo? Tem um post do Fernando Palma sobre o assunto com uma figurinha do custo da não qualidade.
Fazer a análise e o projeto de teste em cima de uma especificação pode ser a própria revisão.
Métricas
Nessa parte do processo é possível medir:
- percentual de requisitos cobertos pelas condições de teste
- percentual de condições de teste cobertas pelos casos de teste
- número de defeitos encontrados na fase de análise e projeto de teste
Próximo post CTAL-related será sobre Implementação e Execução, continuando o fluxo do processo de teste.
Glossário de termos usados
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)