Certificação CBTS

Bom dia pessoal,

Primeiramente agradecer a minha família pelo apoio e paciência, especialmente minha esposa Juliana Lopes e minha filha, aos amigos da homologação e a Aker pelo curso preparatório.

Obtive a Certificação Brasileira de Teste de Software - CBTS da Associação Latino Americana de Teste de Software. 

Valeu

Certificação Brasileira de Teste de Software (CBTS)

A Certificação Brasileira em Teste de Software (CBTS) foi criada pela Associação Latino Americana de Teste de Software (Alast) com o objetivo de estabelecer padrões para avaliar a qualificação dos profissionais que atuam na área de testes de software (ALATS – ASSOCIAÇÃO LATINO AMERICANA DE TESTE DE SOFTWARE, 2010).

Não a pré-requisitos para a realização do exame, que será exigido os seguintes tópicos:

• Introdução ao Processo de Teste;

• Processo de Teste;

• Ambiente de Teste; 

• Análise de Risco;

• PMBOK do PMI;

• Planejamento de Teste;

• Elaboração do Teste;

• Gestão de Defeitos; 

• Teste de Aceitação;

• Relatório de teste;

• Estimativa de teste;

• Tópicos especiais em teste de software.

Os assuntos podem mudar de um exame para outro, recomenda-se fazer download sempre da última versão disponibilizada no site da Alast.

CRIANDO A INFRA-ESTRUTURA PARA OS TESTES - SCRIPTS

Scripts

Os scripts são linguagens de programação interpretada de alto nível, que são executadas dentro de outros programas ou até mesmo outras linguagens de programação, são freqüentemente usadas como ferramentas de configuração e instalação em sistemas operacionais (Shell script), como por exemplo, em alguns sistemas operacionais da família Linux, que usam as linguagens GNU/Shell bash ou sh.

Os scripts mais conhecidos são:

·         Shell scripts;

·         Bash/Linux;

·         Sh/Linux;

·         Bat/Windows;

·         VBScripts/Windows;

·         JavaScripts/Web;

·         Perl/Multi-plataforma;

·         Python/Multi-plataforma.

O uso de scripts nos ambiente de testes é imprescindível, pois facilitam a configuração dos ambientes de testes, em testes repetitivos e de validação (performance e stress), como são fáceis de montar e de se alterar dá ao testador uma grande flexibilidade.

O que é testar?

Bom dia,

Estou estudando para a certificação CBTS, e achei estas definições pertinente, resolvi compartilhar:

• Testar é verificar se o software está fazendo o que deveria fazer, de acordo com os seus requisitos, e não está fazendo o que não deveria fazer (Rios e Moreira – 2002);
• Testar é o processo de executar um programa ou sistema com a intenção de encontrar defeitos (teste negativo) (Glen Myers – 1979);
• Testar é qualquer atividade que a partir da avaliação de um atributo ou capacidade de um programa ou sistema, seja possível determinar se ele alcança os resultados desejados (Bill Hetzel – 1988).

Desenvolvimento aberto e backdoors

O artigo abaixo foi escrito por Rodrigo Fragola no http://www.blogdofragola.blogspot.com.br/ e rendeu uma ótima discussão. Compartilho agora com vocês e retomo o debate: 

o desenvolvimento aberto oferece maior segurança? Vejam o que já rolou sobre o assunto clicando aqui.  

Recentemente, tive uma dessas discussões apaixonadas sobre desenvolvimento aberto – das quais já não costumo mais ter paciência para participar.  Aprendi com o tempo que a área de tecnologia não deve ser movida por paixões, mas por decisões práticas e objetivas, que levem em consideração o ambiente ao redor. E partindo desse princípio, pode-se dizer que a grande maioria das técnicas e tecnologias é aplicável. 

Desenvolvimento aberto (código aberto e software livre são utilizados popularmente como sinônimos, o que não exatamente apropriado) é uma forma de desenvolvimento de software, nada mais. Nem é preciso entrar nos meandros da discussão, porque ela agrega muito pouco no quesito segurança e nada, nos paradigmas fundamentais da programação. 

O desafio atual da segurança no desenvolvimento reside naquela clássica questão de se saber o que realmente um código está fazendo (por exemplo, se ele está ou não em looping), um problema sem solução. 

Hoje, temos ferramentas que “fiscalizam” as melhores práticas de programação, capazes de detectar, em tempo real, um bom nível de erros de codificação. Mas no que diz respeito ao problema apresentado, são incompletas em sua funcionalidade. No final das contas, pressupõe-se que a intervenção humana ainda é necessária. 

O principal argumento da suposta segurança dos sistemas abertos baseia-se na abertura e na visualização do código por milhões de pessoas. A alegação apresenta um componente de obviedade tentador. Afinal, algo visto e validado por milhões de pessoas deve ser mais seguro do que aquilo que ficou restrito a duas ou três. Mas a realidade é outra. 

O código aberto não é nenhuma novidade, existe há muito tempo. Um exemplo clássico foi o bug da pilha TCP/IP que atingiu 100% dos Sistemas Operacionais, há mais de 10 anos.  Ou seja, todos os fornecedores tinham o mesmo bug. Isso significa que utilizaram o mesmo código, fatalmente derivado de um BSD, que era aberto, livre para uso. 

Ainda que o código tenha sido visto por milhões de pessoas de diferentes corporações, o bug existiu por muito tempo. Então, por que, ao olharem para o código, não viram o bug?

Muitas pessoas confundem a velocidade na correção de um problema de segurança com a inexistência dele.  Um grande equívoco! Já que a agilidade em corrigi-lo está vinculada diretamente ao compromisso do fornecedor em fazê-lo, seja ele aberto ou fechado. 

Assim, conclui-se que o sistema não está livre de problemas de segurança, já que os fornecedores, abertos ou fechados, têm esses mecanismos de fornecimento.

Então, onde estão os analistas de código? Por que o código aberto não é mais seguro?

Se oferecesse maior segurança, o software livre (baseado em desenvolvimento aberto) não teria bugs. Todos podem visualizar o código, entretanto 99,9999% dos bugs são descobertos em tempo de execução na maioria dos sistemas, e não com análise de código.  

Analisar o código, aliás, é algo mais complexo do que desenvolver o próprio código. Não existe um processo de automação que diga o que um código está fazendo. Além disso, já se tem poucas pessoas desenvolvendo código em comparação às pessoas que usam os produtos e, talvez, praticamente ninguém verificando.

Podemos até fazer uma analogia com os processos de compra do Governo. Todos eles são públicos e estão disponíveis para a população verificar. Nem por isso o número de problemas apresentados na televisão em relação a esses procedimentos diminui. A população em geral que tem acesso a tais processos não tem capacidade de avaliá-los, apesar de pagar por eles e usufruir de seu resultado.

Para piorar (no que diz respeito à segurança), temos as bibliotecas de terceiros, amplamente usadas, as BIOS de computador e os sistemas de apoio embarcados para processamentos especializados (FPGA, por exemplo). Todos, livres ou não, com possibilidades de backdoors. O mercado sempre foi colaborativo, não se esqueçam desse ponto. Bibliotecas, integrações e compartilhamento de código entre sistemas sempre existiram. Todas essas camadas de apoio, que são ligadas à execução de um sistema, podem esconder brechas de segurança.

Quantas vezes você, leitor, verificou o código aberto de alguma aplicação para ver se existe algo suspeito nele? Será que este “IF” esconde um backdoor? Quantas pessoas você conhece que já fizeram isso? Eu não me lembro de nenhuma nos últimos 15 anos – pelo menos que tenha descoberto algo  relevante. Conheci muita gente que o fez para corrigir um problema ou aprender como se faz algo, mas nunca para tirar conclusões sobre aspectos de segurança ou corretude do sistema.

Como se já não bastasse a dificuldade técnica na avaliação de um código feito por outra pessoa (em ambientes de desenvolvimento essa é uma reclamação constante de novos programadores que entram na equipe), ainda existe a possibilidade de estarem escondidas entre os códigos, ações não tão óbvias. 

Lembro de um campeonato que existia na época de faculdade, cujo objetivo era desenvolver um programa em C que parecia fazer algo específico, mas, na verdade, escondia outras operações. Havia também uma competição que premiava o programa em C mais “confuso”, de modo que, ao ser lido, o leitor não pudesse saber o que ele fazia. Um dos requisitos desses campeonatos era que o programa fosse pequeno, capaz de ser analisado por uma pessoa. 

Se é possível esconder códigos em programas pequenos, pense agora no volume de códigos existentes atualmente! 

Um backdoor pode ser apenas uma atribuição errônea de uma variável ou um conjunto de 03 linhas de código, bem diferente de milhares de linhas de código, como ocorreu no FLAME. 

Resiliência: Os backdoors vieram para ficar, sejam por erros de programação ou inserção proposital.

A qualidade de software como base competitiva

Nos dias atuais, com um mercado altamente competitivo, que reúne vários fabricantes e fornecedores de diversos tipos de produtos e serviços, a qualidade deixa de ser um diferencial competitivo e passa a ser um item básico de sobrevivência das organizações, uma necessidade permanente. Desta forma, uma empresa que forneça bens e/ou serviços com baixa qualidade corre um sério risco de ser descartada pelo mercado consumidor.

Devido a esse mercado altamente competitivo, as empresas passaram a se preocupar em adotar as técnicas mais modernas de qualidade e produtividade para combinar os recursos disponíveis de maneira a aumentar o seu volume de negócios, garantindo a satisfação dos seus clientes e suas margens de lucro.

Em contrapartida, se as empresas não entregam novos produtos ou funcionalidades aos clientes, rapidamente se tornam obsoletas. Assim, o grande desafio é equilibrar as ações para entregar constantemente novos produtos com qualidade e custos adequados. 

Esta teoria é facilmente compreendida através da triângulo da qualidade (TRIPLE CONSTRAINT). Uma estrutura para a avaliação de demandas conflitantes, um triângulo em que um dos lados ou um dos cantos representa um dos parâmetros que está sendo gerenciado pela equipe do projeto. (PMI, 2004:375) 

O triângulo trata do gerenciamento de necessidades conflitantes do projeto, como o escopo, o tempo e o custo. No que tange a qualidade do projeto é necessário encontrar o balanceamento desses três fatores.

Para encontrar esse equilíbrio existem diversas ferramentas como, por exemplo, o PDCA (Plan, Do, Check, Action), o KAMBAN e o 05 Porquês, que têm a função de ajudar as empresas a atingir a excelência nos seus projetos, melhorando continuamente e aplicando valor ao seu produto.

Existem inúmeras vantagens para se efetuar testes de qualidade nos softwares desenvolvidos. A principal delas é a satisfação dos clientes, pois reduzindo o número de reclamações deles, o produto passa a ser indicado e a imagem da empresa melhora a cada dia. Com isso, surge a fidelização em relação aos produtos, a maturidade e estabilidade dos softwares passam a ser atingidas rapidamente e os custos com desenvolvimento e manutenção são reduzidos, gerando maior receita à empresa.

Com base na pesquisa e na observação das empresas estudadas, seguem as recomendações sobre a estrutura organizacional que melhor se adéquam ao departamento de testes de software:

- Não é recomendado que o Departamento de Qualidade e Testes de Software seja coordenado pela mesma gerência da Equipe de Desenvolvimento, pois pode haver conflitos de interesse;

- O departamento de Testes de Software deve estar preferencialmente abaixo de uma diretoria específica de qualidade da empresa;

- A estrutura interna do Departamento de Teste de Software deve seguir os padrões de certificações existentes, citadas anteriormente, que são:

• Líder do Projeto de Testes: responsável pela liderança de um projeto de teste específico, normalmente relacionado a um sistema de desenvolvimento, seja um projeto novo ou em manutenção (RIOS e MOREIRA, 2006);

• Engenheiro/Arquiteto de Teste: responsável pela montagem da infraestrutura de teste, montando o ambiente de teste, escolhendo as ferramentas de teste e preparando a equipe para executar o seu trabalho neste ambiente de teste;

• Analista de Teste: responsável por modelar, especificar e documentar os casos de testes que devem ser realizados, em resumo esta função cria os Planos de Testes que o testador irá executar;

• Testador: responsável por executar os testes e analisar os resultados obtidos, seguindo parâmetros previamente definidos no Plano de Testes.

Para o profissional, temos algumas certificações no mercado. São elas:

Para as empresas desenvolvedoras temos:

CRIANDO A INFRA-ESTRUTURA PARA OS TESTES

Neste capítulo são sugeridas ferramentas, procedimentos e workflow para realização dos diversos tipos de testes e a montagem de laboratórios de testes, simulando os ambientes reais de forma mais completa possível.

Ferramentas

Sistemas de máquinas virtuais

A virtualização é uma tecnologia que oferece uma camada de abstração dos verdadeiros recursos de uma máquina física, provendo recursos (hardware) virtuais para cada sistema operacional.

Com isso temos a vantagem de executar vários sistemas operacionais em um mesmo sistema computacional simultaneamente, entre outras vantagens como:

·         Redes virtuais: cria “switchs” virtuais entre as máquinas virtuais podendo também incluir interfaces de rede reis;

·         Compartilhamento de memória RAM e disco: cada máquina virtual pode utilizar uma quantidade de memória diferente, definida pelo usuário;

·         Snapshot: possibilidade de criar registros instantâneos de uma máquina virtual num dado momento. Assim, é possível testar configurações, e se elas derem erradas pode-se reverter.

Alguns produtos que implementam estas funcionalidades e muitas outras:

·         VM-ware (http://www.vmware.com/);

·         Oracle Virtual Box (http://www.virtualbox.org);

·         GNU XEN (http://www.xen.org/).

Em um ambiente de teste os sistemas de virtualização é uma arma poderosa, permite que se simulem vários tipos de clientes, sistemas e a economia em espaço físico para a montagem dos laboratórios.

Desculpem a ausência... seguem as postagens!!!

Missão, Visão e Valores da equipe

A missão deve responder o que a empresa ou a organização se propõe a fazer, e para quem (FARIA, 2004).

O enunciado da visão é a descrição do futuro desejado para a empresa. Esse enunciado reflete o alvo a ser procurado (FARIA, 2004):
• Pelos esforços individuais;
• Pelos esforços das equipes e
• Pela alocação dos recursos.

Valores são princípios, ou crenças, que servem de guia, ou critério, para os comportamentos, atitudes e decisões de todas e quaisquer pessoas, que no exercício das suas responsabilidades, e na busca dos seus objetivos, estejam executando a Missão, na direção da Visão (FARIA, 2004).

É recomendado que toda empresa tenha sua missão, visão e valores, desta forma o departamento de testes de softwares também deve ter sua missão, exemplo:
“Disponibilizar produtos com excelência buscando melhorar continuamente a eficácia do Sistema de Gestão da Qualidade.”

Desafio: “Realizar testes com a maior abrangência de ambientes possíveis.“

ESTRUTURA ORGANIZACIONAL

Da empresa

 Com base na pesquisa e na observação das empresas estudadas, seguem as recomendações sobre a estrutura organizacional que o departamento de testes de software melhor se adéqua:

·         Não é recomendado o departamento de qualidade e testes de softwares ser gerenciados pela mesma gerência de desenvolvimento, pois, pode gerar conflitos de interesses;

·         De preferência o departamento de testes de software estar abaixo de uma diretoria específica de qualidade da empresa;

Da equipe de testes

A estrutura interna do departamento de teste de software é recomendável seguir os padrões de certificações existentes citadas anteriormente que são:

• ·         Líder do projeto de testes: responsável pela liderança de um projeto de teste específico, normalmente relacionado a um sistema de desenvolvimento, seja um projeto novo ou em manutenção (RIOS e MOREIRA, 2006);
• ·         Engenheiro/Arquiteto de teste: responsável pela montagem da infra estrutura de teste, montando o ambiente de teste, escolhendo as ferramentas de teste e preparando a equipe para executar o seu trabalho neste ambiente de teste;
• ·         Analista de teste: responsável por modelar, especificar e documentar os casos de testes que devem ser realizados, em resumo esta função cria os Planos de testes que o testador irá executar;
• ·         Testador: responsável por executar os testes e analisar os resultados obtidos, seguindo parâmetros previamente definidos no Plano de testes;
• 
  
• Logo abaixo iremos definir o que é um Plano de teste, ficando mais claro as funções de cada integrante da equipe.

CMMI (Capability Maturity Model Integration for Development)

O gerenciamento de projetos ou processos de software se refere à aplicação de conhecimentos, habilidades.

O gerenciamento de projetos ou processos de software se refere à aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto a fim de satisfazer seus requisitos, e é realizado com o uso de processos tais como: especificação, implementação, testes, manutenção e evolução (CITS - CENTRO INTERNACIONAL DE TECNOLOGIA DE SOFTWARE, 2008).

Para auxiliar neste gerenciamento temos como opção seguir o padrão  CMMI (Capability Maturity Model Integration for Development) foi criado pelo SEI - Software Engineering Institute, sendo reconhecido mundialmente por atestar a maturidade dos processos de desenvolvimento da organização. Reúne diretrizes e boas práticas, tanto acadêmicas quanto de mercado, as quais devem ser incorporadas pelas empresas em seus processos (CITS - CENTRO INTERNACIONAL DE TECNOLOGIA DE SOFTWARE, 2008).

Ele possui cinco níveis de maturidade que especificam o desenvolvimento dos seus processos de desenvolvimento de softwares:

• ·         Inicial;
• ·         Gerenciado;
• ·         Definido;
• ·         Quantitativamente Gerenciado;
• ·         Otimizado.

O CMMI abrange 25 áreas de processo divididas em 4 categorias:

·         Gerenciamento de projetos:

·         Definição do processo organizacional;

·         Foco no processo organizacional;

·         Treinamento organizacional;

·         Desempenho do processo organizacional.

·         Gerenciamento de processos:

·         Gerenciamento quantitativo de projeto;

·         Gerenciamento de risco;

·         Gerenciamento integrado de projeto;

·         Gerenciamento de acordo com fornecedor;

·         Monitoramento e controle de projetos;

·         Planejamento de projetos;

·         Gerenciamento integrado de fornecedores.

·         Engenharia:

·         Validação;

·         Verificação;

·         Integração de produtos;

·         Solução técnica;

·         Desenvolvimento de requisitos;

·         Gerenciamento de requisitos.

·         Suporte:

·         Gerenciamento de configuração;

·         Garantia de qualidade de processo e produto;

·         Medição e analise;

·         Análise e tomada de decisão;

·         Análise de causas e resolução;

·         Ambiente organizacional para integração.

ISO/IEC 14598 - Engenharia de Software - Avaliação da Qualidade de Produto de Software

A Norma ISO/IEC 14598-5 define um processo de avaliação da qualidade de produto de software, onde se define as principais características de um processo de avaliação (repetibilidade, reproducibilidade, imparcialidade e objetividade) (GOMES, 2000).

As etapas são:

·         Estabelecer os requisitos de avaliação: analisar os requerimentos para identificar o propósito da avaliação;

·         Especificar a avaliação: define o escopo e métricas da avaliação e as medições a que o produto será submetido.

·         Projetar a avaliação: com base nas especificações do produto elaborar um plano de avaliação no qual estejam relacionados os componentes do produto de software a serem avaliados e os métodos de avaliação;

·         Executar a avaliação: consiste na inspeção, medição e teste dos produtos e seus componentes de acordo com o plano de avaliação;

·         Conclusão da avaliação: consiste no relatório de avaliação e liberação dos dados obtidos na fase anterior.

Outra visão da norma:

Figura 4. Visão Geral do processo – ISO 14598-1 (COLOMBO, 2007).

NBR ISO/IEC 12119 (atual ISO/IEC 25051)

Norma que estabelece os requisitos de qualidade para pacotes de software e instruções de como testar um pacote de software com relação aos requisitos estabelecidos (GOMES, 2000).

Estes requisitos são:

·         Descrição do produto – informações sobre o produto e suas principais funcionalidades têm como finalidade ajudar o usuário ou o comprador a avaliar se o produto atende suas necessidades;

·         Documentação do usuário – documentação de fácil compreensão identificando o conhecimento necessário para a utilização da aplicação;

·         Documentação do produto e dados – são os requisitos de programas e dados necessários para seu funcionamento.

Os testes definidos nesta norma são para validar os itens citados acima e seguem a seguinte estrutura:

Figura 3. Estrutura da Norma ISO/IEC 12119.

Certificações para as empresas de desenvolvimento de software

NBR ISO 13596

Norma voltada à área de tecnologia da informação – Avaliação de produtos de software, características de qualidade e diretrizes para seu uso. Versão brasileira da norma ISO/IEC 9126.

A definição de qualidade pela norma NBR ISO 13596 é a totalidade das características de uma entidade, que lhe confere a capacidade de satisfazer as necessidades explicitas e implícitas (ABNT - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS., 1996).

Pontos fortes desta norma:

·         Confiabilidade:

·         Maturidade;

·         Tolerância a falhas.

·         Eficiência – definido pelo relacionamento desempenho x recursos utilizados;

·         Funcionalidade:

·         Adequação;

·         Exatidão;

·         Interoperabilidade;

·         Conformidade;

·         Segurança.

·         Portabilidade:

·         Adaptabilidade;

·         Suporte a várias plataformas.

NBR ISO/IEC 9126

A norma fornece um modelo de propósito geral o qual define seis amplas categorias de características de qualidade de software que são, por sua vez, subdivididas em subcaracteristicas (GOMES, 2000):

·         Funcionalidades – conjunto de funções que satisfazem os requisitos definidos no produto, as subcategorias:

·          Adequação – propões-se a fazer o que é definido nos requisitos?

·         Gerar resultados corretos, conforme definido nos requisitos?

·         Interoperabilidade – é capaz de interagir com os sistemas especificados?

·         Segurança de acesso – evita acessos não autorizados?

·         Conformidade – está de acordo com as normas e convenções previstas em leis e descrições similares?

·         Confiabilidade – o desempenho se mantém em longos períodos, as subcategorias:

·         Maturidade – freqüência de falhas;

·         Tolerância a falhas – comportamento quando as falhas ocorrem;

·         Recuperabilidade – é capaz de recuperar dados após uma falha?

·         Usabilidade – facilidade no uso do software, as subcategorias:

·         Inteligibilidade;

·         Apreensibilidade;

·         Operacionalidade.

·         Eficiência – os recursos e os tempos utilizados são compatíveis com o nível de desempenho especificado nos requisitos.

·         Manutenibilidade – facilidade nas correções, atualizações e alterações, as subcategorias:

·         Analisabilidade – facilidade encontrar erros quando ocorrem;

·         Modificabilidade – facilidade em modificar as funcionalidades;

·         Estabilidade – riscos de bugs quando se faz alterações;

·         Testabilidade – facilidade de testar as alterações.

·         Portabilidade – utilização do produto em diversas plataformas com pequeno esforço de adaptação.

Certificações para o profissional

Certificação Brasileira de Teste de Software (CBTS)

A Certificação Brasileira em Teste de Software (CBTS) foi criada pela Associação Latino Americana de Teste de Software (Alast) com o objetivo de estabelecer padrões para avaliar a qualificação dos profissionais que atuam na área de testes de software (ALATS – ASSOCIAÇÃO LATINO AMERICANA DE TESTE DE SOFTWARE, 2010).

Não a pré-requisitos para a realização do exame, que será exigido os seguintes tópicos:

·                    Introdução ao Processo de Teste;

·                    Processo de Teste;

·                    Ambiente de Teste;

·                    Análise de Risco;

·                    PMBOK do PMI;

·                    Planejamento de Teste;

·                    Elaboração do Teste;

·                    Gestão de Defeitos;

·                    Teste de Aceitação;

·                    Relatório de teste;

·                    Estimativa de teste;

·                    Tópicos especiais em teste de software.

Os assuntos podem mudar de um exame para outro, recomenda-se fazer download sempre da última versão disponibilizada no site da Alast.

Certificações da Quality Assurance Institute (QAI)

As certificações da Quality Assurance Institute (QAI) são internacionais e foram lançadas em 1990, desde sua criação aproximadamente 35 mil profissionais adquiriram a certificação em 43 países (QAI BRASIL, 2011).

As três certificações abaixo são relacionadas à área de testes de software focada ao profissional da área.

Certified Associate Software Testing (CAST)

A primeira de uma série de certificações seqüenciais que representa a evolução dos conhecimentos do profissional da área de testes de software.

Os pré-requisitos para realizar a prova de certificação são:

·         Formação de 3 ou 4 anos em alguma instituição de nível universitário reconhecido;

·         Formação de 2 anos em alguma instituição de nível universitário reconhecido e 1 ano de experiência na área de sistemas de informação;

·         Três anos de experiência na área de sistemas de informação.

A certificação irá exigir 10 tópicos:

·                    Princípios e Conceitos de Teste de Software;

·                    Construindo o ambiente de teste;

·                    Gerenciando o projeto de teste;

·                    Planejamento de Teste;

·                    Execução do Plano de Teste;

·                    Teste de Status, Analysis and Reporting;

·                    Usuário testes de aceitação;

·                    O teste de software desenvolvidos por organizações fora;

·                    Controles de Teste de Software e da adequação dos procedimentos de segurança;

·                    Testar novas tecnologias.

Certified Software Tester (CSTE)

A segunda de uma série de certificações seqüenciais que representa a evolução dos conhecimentos do profissional da área de testes de software.

Os pré-requisitos para realizar a prova de certificação são:

·         Formação universitária na área de TI, mais dois anos de experiência profissional;

·         Seis anos de experiência profissional;

·         Estão trabalhando, ou que tenham trabalhado em qualquer momento dentro dos últimos 18 meses, na área abrangida pela certificação.

A certificação irá exigir 10 tópicos:

·         Princípios e Conceitos de Teste de Software;

·         Construindo o ambiente de teste;

·         Gerenciando o projeto de teste;

·         Planejamento de Teste;

·         Execução do Plano de Teste;

·         Teste de Status, Analysis and Reporting;

·         Usuário testes de aceitação;

·         O teste de software desenvolvidos por organizações fora;

·         Controles de Teste de Software e da adequação dos procedimentos de segurança;

·         Testar novas tecnologias.

 Certified Software Quality Analist (CSQA)

A segunda de uma série de certificações seqüenciais que representa a evolução dos conhecimentos do profissional da área de testes de software.

Os pré-requisitos para realizar a prova de certificação são:

·         Formação universitária na área de TI, mais dois anos de experiência profissional;

·         Seis anos de experiência profissional;

·         Estão trabalhando, ou que tenham trabalhado em qualquer momento dentro dos últimos 18 meses, na área abrangida pela certificação.

A certificação irá exigir 10 tópicos:

1.      Princípios da Qualidade e Conceitos;

2.      Liderança em Qualidade;

3.      As linhas de base de qualidade (Avaliação e Modelos);

4.      Garantia da Qualidade;

5.      Planejamento da Qualidade;

6.      Definir, construir, implementar e melhorar processos de trabalho;

7.      Práticas de Controle de Qualidade;

8.      Métricas e Mensuração;

9.      Controle Interno e de Segurança;

10.  Prestação de serviços.

Certified Tester Foundation Level - (BSTQB/ISTQB)

Esta certificação é internacional que foi criada no Reino Unido com a British Computer Society´s Information Systems Examination Board (ISEB) em 1998, é reconhecida por uma comissão nacional do International Software Testing Qualifications Board (ISTQB), a principal diferença é que este certificado não expira e não precisa ser renovado (BSTDB, 2010).

Existem dois níveis da mesma certificação e os pré-requisitos são:

·         Certified Tester Foundation Level (CTFL), não há pré-requisitos, mas recomenda-se:

·         Tenha um mínimo conhecimento em qualquer desenvolvimento de software ou teste de software, seis meses de experiências em um sistema ou teste de aceite ou desenvolvedor de software;

·         Fazer o curso que é autorizado pelos padrões do ISTQB (por uma comissão nacional reconhecida).

·         Certified Tester Advanced Level (CTAL) os pré-requisitos são:

·         Dois anos de experiência prática em Teste de Software ou Qualidade em TI;

·         Dois anos dedicados à Pesquisa Acadêmica relacionada à Qualidade de TI em nível de Pós Graduação, ou como instrutor de cursos ou disciplinas relacionadas à Qualidade de TI;

·         Três anos em Desenvolvimento de Sistemas, Análise de Sistemas ou Engenharia de Software;

·         Certificação ISTQB Certified Tester, Foundation Level (CTFL).