Verificação de Requisitos

Questões a serem respondidas pela Verificação de Requisitos 

Verificaçãode validade: O sistemaforneceas funçõesquemelhorapóiamas necessidadesdo cliente?

 

Verificaçãode consistência: Existealgumtipode conflitode requisitos?

 

Verificaçãode completeza:  Todasas funçõesrequisitadaspeloclienteforamincluídas?

Verificaçãode realismo: Os requisitospodemser implementadoscom o orçamentoe a tecnologiadisponíveis?

Facilidadede verificação: Os requisitospodemser verificados?

Palestras de todas as Trilhas de Teste do TDC 2011

O Elias Nogueira do Sem Bugs compartilhou todas as apresenteções das paletras das trilhas de teste do TDC 2011. Vale a leitura.

TDC 2011 São Paulohttp://www.thedevelopersconference.com.br/tdc/2011/saopaulo/trilha-testes#programacao
http://sembugs.blogspot.com/2011/07/slides-da-trilha-de-teste-tdc-2011.html

TDC 2011 Florianópolis
http://sembugs.blogspot.com/2011/08/trilha-teste-tdc2011-florianopolis.html
http://www.thedevelopersconference.com.br/tdc/2011/florianopolis/trilha-testes#programacao

TDC 2011 Goiânia
http://www.thedevelopersconference.com.br/tdc/2011/goiania/trilha-testes#programacao
http://sembugs.blogspot.com/2011/11/palestras-trilha-de-teste-tdc-2011.html

Como agir com bugs

Post sensacional do José Carréra no Bytes don't Bite:

Os bugs também têm sentimentos


Muitas vezes uma imagem diz mais do que mil palavras. No blog Cartoon tester, Andy Glover faz uso de imagens extremamente simples, mas que transmitem de maneira objetiva conceitos e práticas interessantes relacionadas com as atividades do engenheiro de testes.

A imagem abaixo é do post do blog, que fala de maneira correta sobre algumas atitudes que devemos ter no nosso dia a dia quando encontramos bugs. Abaixo, uma breve explicação dos pontos mencionados.

Se você encontrar um bug:

1 – Reporte-o, bugs não gostam de ser esquecidos.

Diversos motivos podem levar um testador a esquecer de reportar algum defeito encontrado, prazos apertados, tarefas acumuladas, desorganização ou simplesmente o fato de que algumas vezes os defeitos são encontrados antes mesmo dos testes, em conversas informais, treinamentos, etc.. e nem sempre os envolvidos tomam as devidas ações nessas situações.

2 – Conheça-o melhor, bugs gostam de ser compreendidos.

Antes de reportar um defeito, devemos entender por completo seu comportamento, sua abrangência e quais são seus impactos.

3 – Tire uma foto, bugs gostam de guardar recordações das ocasiões.

Screenshots, fotos e inclusive vídeos ajudam a evidenciar melhor a reportagem de um defeito, facilitando o entendimento do desenvolvedor e evitando CRs reabertas.

4 – Conheça seus companheiros, bugs são socialites.

Ao encontrar um defeito é comum que outros bugs estejam localizados nas suas redondezas, por isso é importante a varredura nas funcionalidades relacionadas para rapidamente detectar novas falhas.

5 – Reporte rapidamente, do contrário os bugs se estabelecem e fazem moradia.

Agilidade na reportagem permite que sua correção também seja antecipada, evitando que outros bugs causados pela falha já existente sejam revelados.

6 – Seja honesto, bugs não gostam de fofocas.

Classificação de severidade e prioridade supervalorizadas, melhorias registradas como defeitos, entre outros problemas frequentes, causam problemas na comunicação da equipe e atrapalham o andamento das atividades.

7 – Guarde como o conheceu, bugs são românticos.

Ao encontrar um defeito, a primeira tarefa é sempre de verificar quais foram os passos prévios para detecção do problema, reportar como podemos reproduzir o issue é essencial para os desenvolvedores durante a correção e também para os testadores no momento da verificação das correções.

8 – Não o ignore, bugs podem morder quando não apreciados.

Em meio a tantos bugs, normalmente encontrados durante os testes, é comum que em alguns momentos desprezemos alguns defeitos encontrados, por acreditarmos que os mesmos são irrelevantes ou nunca serão corrigidos. Porém, já cansei de ver defeitos ignorados sendo reportados posteriormente por clientes ou quando vistos por outros ângulos gerando consequências graves para o sistema.

Adicionaria a lista de atitudes a verificação dos defeitos já existentes, prática bastante simples, mas que muitas vezes é relegada, e que pode evitar trabalho desnecessário de diversas pessoas.

Lista da Qualidade

O Cristiano Caetano (@c_caetano)criou uma lista contendo os blogs e listas de discussão da área de teste e qualidade:

Segue a lista:

Blogs de teste e qualidade de software brasileiros

http://sembugs.blogspot.com/ (@eliasnogueira)
http://www.testexpert.com.br/?q=blog
https://cristianocaetano.wordpress.com/ (@c_caetano)
http://www.linhadecodigo.com.br/Colaborador.aspx?id=221
http://www.testadores.com/ (@testadores_com)
http://www.bugbang.com.br/ (@Camiloribeiro)
http://ensaiosdeqa.blogspot.com/
http://testavo.blogspot.com/ (@lugatibr)
http://www.zezologs.org/ (@eudescosta)
http://diariodaqualidade.blogspot.com/
http://qualidadebr.wordpress.com/
http://asespecialistas.blog.com/ (@AsEspecialistas)
http://engtesteagil.blogspot.com/ @AndreSousaBH
http://guts-rs.blogspot.com/ (@gutsrs)
http://jppercy.wordpress.com/ (@jppercy)
http://testing.faraco.net/ (@pedrofaraco)
http://basedetestedesoftware.blogspot.com/
http://jmeter.zip.net (@danivieira)
http://www.testexpert.com.br/?q=blog/7 (Fábio Martinho Campos)
http://testesdesoftware.blogspot.com/ Luiz Cesar Soares @cesa_soares
http://interessesafim.blogspot.com/ - @adelinopmazuti
http://theladybugblog.wordpress).com/ @theladybugblog @fernandathiesen
http://lealtic.wordpress.com/ @carinleal
http://edwagneyluz.com/ @edwagneyluz
http://seuenium.com.br @seuenium
http://www.leonardobg.com.br @avontz - Java Selenium e Coca Cola
http://felipesilva-rec.blogspot.com/ @FelipeSilva
http://blog.prasabermais.com/ Luiz Cesar Soares @cesa_soares
http://josepaulopapo.blogspot.com/ Luiz Cesar Soares @cesa_soares
http://www.jailtonalkiminlouzada.com/ Jailton Alkimin Louzada @jailtonjr
http://barbaracabral.wordpress.com/
http://themonsterbug.blogspot.com @mairastella_s


Certificações

Brazilian Software Testing Qualification Board -- 
http://www.bstqb.org.br/
Instituto Brasileiro de Qualidade em Testes de Software
 -- http://www.ibqts.com.br/
Certified Software Quality Analyst (CSQA) -- http://www.softwarecertifications.org/qai_csqa.htm
Software Quality Engineer Certification CSQE -- 
http://www.asq.org/certification/software-quality-engineer/index.html
ISEB Foundation Certificate in Software Testing -- 
http://www.bcs.org/server.php?show=nav.7179
ISEB Practitioner Certificate in Software Testing -- 
http://www.bcs.org/server.php?show=nav.6956
The Certified Software Tester (CSTE)
 -- http://www.softwarecertifications.com/qai_cste.htm
Certified Test Manager (CTM) -- 
http://www.testinginstitute.com/ctm.php
Certified Software Test Professional (CSTP)
 -- http://www.testinginstitute.com/cstp.php
American Software Testing Qualifications Board
 -- http://www.astqb.org/

Listas de discussão brasileiras:

Testadores.com
http://br.groups.yahoo.com/group/testadores/
VV-SW-Brasil - Validação e Verificação de Software
http://br.groups.yahoo.com/group/VV-SW-Brasil/
CMM Brasil
http://br.groups.yahoo.com/group/CMM-Brasil/
ALATS - Associação Latino Americana de Teste de Software
http://br.groups.yahoo.com/group/alats-br/
Teste de Software
http://br.groups.yahoo.com/group/testesoft/
DFTestes: Grupo de amigos profissionais em Teste de Software do Distrito Federal
http://br.groups.yahoo.com/group/DFTestes/
QAI - Quality Assurance Institute Brasil
http://br.groups.yahoo.com/group/qai-brasil/
International Software Testing Qualifications Board
http://groups.google.com.br/group/bstqb
Grupo de estudo criado para quem deseja certificação CSTE da QAI
http://br.groups.yahoo.com/group/cste-brasil/
Grupo de discussão sobre Qualidade de Software
http://br.groups.yahoo.com/group/qa_rs/

Certificações - Qualidade e Teste de SW
http://br.groups.yahoo.com/group/certificacoesqualidadetestedesoftware/
Teste de software PE
https://groups.google.com/group/teste-de-software-pe?lnk=gcimh&hl=pt
Teste de software Sergipe
https://groups.google.com/group/testesergipe?hl=pt&lnk=
Teste de software Belo Horizonte
https://groups.google.com/group/teste-software-bh?hl=pt&lnk=
GETS: Grupo de Estudos em Testes de Software - Brasil
https://groups.google.com/group/gets-br?hl=pt&lnk=
BHZtestes
https://groups.google.com/group/bhztestes?hl=pt&lnk=
Testes Avançados - Recife
https://groups.google.com/group/testes-recife-l?hl=pt&lnk=
Software Testing Brasil
https://groups.google.com/group/software-testing-brasil?hl=pt&lnk=
REC Testing & etc
https://groups.google.com/group/testingetc?hl=pt&lnk=
Qualidademanaus
https://groups.google.com/group/qualidademanaus?hl=pt&lnk=
STG - Student Test Group
https://groups.google.com/group/stg---student-test-group?hl=pt&lnk=
Disseminando a Cultura do Teste de Software no Brasil
https://groups.google.com/group/culturadoteste?hl=pt&lnk=
Testadores
http://br.groups.yahoo.com/group/testadores/
Teste de software
http://br.groups.yahoo.com/group/teste_software/
Certificações - Qualidade e Teste de SW
http://br.groups.yahoo.com/group/certificacoesqualidadetestedesoftware/
Engenharia e Garantia de Qualidade
http://br.groups.yahoo.com/group/Engenharia_e_Garantia_de_Qualidade/
SPIN-MT (Software Process Improvement Network de Mato Grosso)
http://br.groups.yahoo.com/group/SPIN-MT/
MPT.Br
http://mptbr.blogspot.com.br

Engraçados Testes:

http://cartoontester.blogspot.com/ (@Fernanda Rocha)
http://fortester.blogspot.com (@Fernanda Rocha)
http://vidadeprogramador.com.br/ (@Fernanda Rocha)

E o Crowd Test??

Site nacional paga usuário que aponta bugs
Por Vinicius Aguiari

Baseado no modelo de crowdsourcing, Google e Facebook são duas empresas que já remuneram hackers por falhas encontradas em seus sistemas.

E a prática deve crescer no Brasil. O CrowdTest é uma ferramenta que faz a ponte entre usuários e empresas que precisam testar seus novos produtos.

Criado pelos sócios Robert Pereira e Hugo Barros, o site começou a operar em março deste ano e já realizou cerca de 20 ações com empresas como Buscapé, Sul-América, Via6, CupomNow, entre outras. O site surgiu a partir da experiência anterior de Barros à frente da a Base2, empresa especializada em testar softwares.

Segundo Pereira, o candidato não precisa ser um hacker para se tornar um colaborador do serviço. “Trabalhamos com grupos específicos, como usuários de Android, usuários de Firefox, mulheres que utilizam e-commerce, entre outros”, explica ele. Atualmente, a empresa conta com cerca de 1 100 testadores em todo o país.

Existem quatro tipos de erros que o colaborador pode apontar: impeditivos, que causam o travamento do sistema e valem R$ 20; funcionais, ou pequenos bugs de usuabilidade, que valem R$ 10; de interface, como erros de ortografia, botões etc, e que pagam R$ 5; e sugestões de melhorias, que valem R$ 2,50 cada.

De acordo com Pereira, existem colaboradores que recebem até R$ 300 por semana dependo do período. Notebooks, headsets, HDs externos e outros equipamentos também são oferecidos como prêmio.

Em julho deste ano, a CrowdTest foi apontada pela instituto Empreender Endeavor Brasil como umas das novas startups inovadoras do país.


E você? O que acha desta prática??

Que tal da Vinci na sexta feira??

Pense Como da Vinci

View more presentations from André Faria Gomes

Processo de Desenvolvimento de Software

Uma das propostas deste blog era não falar exclusivamente de Teste de Software e passear por outros tópicos em TI. Como até hoje ainda não postei nada que não seja relacionado a  testes, pretendo corrigir esta falha e falar sobre outro assunto.  Ainda é realcionado com engenharia de software, mas já é um  começo. Vamos lá!

Processo de Desenvolvimento de Software

Para a Wiki: "é um conjunto de atividades, parcialmente ordenadas,  com a finalidade de obter um produto de software." Simples como o nome sugere! Mas o que está envolvido neste  conjunto de atividades? Praticamente tudo o que acontece até o  momento em que o software começa a "funcionar" no cliente. Por isso, a tarefas de desenvolvimento, quer sejam elas de criação  ou de manutenção de um software, devem ser divididas em processos.

Para Bezzera(2006) um PDS tem os seguintes objetivos:

– definir quais as fases de trabalho previstas no desenvolvimento
de sistemas, ou seja, qual o modelo de ciclo de vida no qual se
baseia;

– para cada fase, quais as técnicas adotadas (Análise Estruturada,
Análise Essencial, Projeto Estruturado etc.);

– para cada técnica adotada definir as ferramentas a serem
utilizadas (Diagrama de Fluxo de Dados, Diagrama Entidade-Relacionamento,
Diagrama de Transição de Estado etc.);

– definir quais os modelos que as ferramentas irão produzir
(Modelo Funcional, Modelo Conceitual de Dados, Modelo de Controle etc.);

– definir quando, como e por quem tais atividades serão  executadas.

– prover pontos de controle para verificar o andamento do desenvolvimento.

– padronizar a forma de desenvolver software em uma organização.

Etapas do Desenvolvimento de uma Ideia
Fonte

Levantamento de Requisitos (Estudo): etapa para entender o problema que será resolvido pelo software.

Análise: hora de quebrar o sistema em vários componentes e estudar como eles se integram para entender como o sistema funciona.

Projeto: produz uma descrição computacional do que o software fará, qual tecnologia será usada para fazer o "como" o sistema atenda os requisitos do sotware.

Implementação: hora de codificar! 

Testes: Verifica se o sistema faz o que deve e se não faz o que não deve.

Implantação: Entrega! Hora de montar o ambiente e instalar o software no cliente.


Para concluir, um PDS serve para esclarecer as coisas durante  o desenvolvimento de um sistema e tentar evitar o caos que esta atividade pode vir a se tornar.




Bibliografia:

ALMEIDA, Rodrigo Rebouças de. Processos de Desenvolvimento de Software. Disponível em <http://www.rodrigor.com.br/_media/talks/pbjug_tech_day_processos_de_desenvolvimento_de_software.pdf> Acesso em 29/08/2100

BEZERRA, Eduardo. Principios de Analise e Projeto de Sistemas Com UML. BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML, Campus, 2006.  392 p.

Wikipédia. Processo de desenvolvimento de software. Disponível em
<http://pt.wikipedia.org/wiki/Processo_de_desenvolvimento_de_software> Acesso em 29/08/2011

Charges sobre Teste

Depois do Vida de Programador e do Vida de Suporte, chegou a vez dos testers:

4 Tester

Vejam uma amostra:

Syllabus CTFL 2011

O BSTQB acaba de divulgar a nova versão do Syllabus.

Para quem no sabe, o Syllabus é a Base de Conhecimento para Certificação de Teste de Software do International Software Testing Qualifications Board (ISTQB).
A versão disponibilizada já será adotada para o próximo exame CTFL(Certified Tester Foundation Level ), a certificação de nível fundamental destinado a qualquer pessoa envolvida em testes de software.

Para fazer o download: http://www.bstqb.org.br/?q=node/12

Para maiores informações acesse: http://www.bstqb.org.br/

Padronizar documentos de teste

Continuando a falar sobre documentos do teste de software, quando se toma a decisão de documentar, logo em seguida surege outra necessidade: que modelo de documento utilizar? Se a Ana usa um template X e o Marcos um template Y, como vamos conseguir manter a ordem por aqui?

Padronizar estes documentos faz com que a equipe se comunique melhor. Ajuda também a manter o processo de teste coerente, onde todos saberão onde encotrar as inforamções necessárias para cumprir sua parte no processo.

Neste mundo de padronização, temos o padrão IEEE 829 trata exclusivamente de teste de software. Esta norma, tem como proposta descrever um grupo de documentos necessários para o funcionamento do processo de teste de Software.

A norma propõe que os seguintes documentos seja utilizados:

Plano de Teste;
Especificação de teste;
    – Projeto de teste;
    – Casos de teste;
    – Procedimentos de teste;
Relatórios de Teste
   –Relatório de Passagem de Itens de Teste;
   –Relatório de Log de Teste;
   – Relatório de Incidentes de Teste;
   – Relatório de Sumário de Teste.

Para quem quiser "Ver" realmente alguns deste templates, o  Fábio Martinho compatilhou alguns deles no link abaixo:
http://www.testexpert.com.br/?q=node/1666

Bibliografia:
RIOS, Emerson. Dissecando o Padrão IEEE 829. ITeste
Wikipedia. IEEE_829. Disponível em <http://pt.wikipedia.org/wiki/IEEE_829>

Educação para Testers

O The Testing Planet publicou o seguinte infográfico sobre a Educação dos Testers pelo mundo a fora:

Fonte: The Testing Planet

tirinha

Porque documentar seus testes?

Fonte

Documentar? Para que eu vou gastar mais horas para gerar um monte de documento que ninguém vai lê? Essa é a primeira pregunta que muitos testadores ouvem quando vem com a ideia de começar a documentar os teste. E logo em seguida vem a outra: Mas o que eu ganho documentando?

Examinenos alguns benefícios:

* Controle sobre o que está sendo testado, o que já foi testado e o que ainda falta para testar.

* Forma de comunicação entre a equipe de teste

* Abriga o conhecimento adquirido durante a fase de teste

* As inforações não estatão presas na cabeça de um ou utro.

* Fica evidenciado o quando foi testado

* Melhora, até mesmo, a qualidade das atividades relacionadas ao teste.

E principalmente:

Fornece aos clientes evidência da qualidade do software.

Uma boa prática é evitar o uso de papeis que ficarão empilhados nas mesas, ou presos em armários e não serão útil. O ideal seria armazena-los na intranet ou em uma solução Wiki.

Vale lembrar também que os documentos tem um ciclo de vida, sendo necessário atualiza-los sempre que houver alguma modificação.

frases teste

Evite casos de teste descartáveis, a menos que o programa seja também descartável. MYERS

Um breve olhar sobre: Teste de segurança durante o desenvolvimento

Leitura resumida de: Teste de Segurança Durante o Desenvolvimento

Imagem de  tecnofagia.com

Justificativa

Porque não desenvolver sistemas com um nível maiso de segurança e baixa probabilidade de falahas?

Obejtivo
O desenvolvimento de um sistema seguro

Rquesitos de Segurança
*Aspectos de Segurança em Metodologias
ISO/IEC 17799 (Code of Practice for Information Security Management) e ISO/IEC 15408 (Evaluation Criteria for Information Technology on Technology Security Evaluation)

* Boas Práticas de Programação
 – Testar o retorno de funções
- Documentar funções corretamente
- Tratar as entradas de dados
- Ter uma política de versão consistente
- Evitar informações sensíveis em arquivos temporários
- Não armazenar senhas e chaves criptográficas no código
- Operar com o privilégio necessário

*Testes de segurança
"Os testes de segurança tem como finalidade auxiliar a garantir a integridade e confiabilidade do software contra possíveis falhas que possam surgir durante a sua implementação e posteriormente durante a sua utilização. Uma forma de garantia de segurança é através de testes realizados e comprovados pelo cliente em laboratórios independentes." (ISO/IEC 15408-1:1999)

Processo:
• Especificar a segurança de forma clara e objetiva;
• Construir conforme a especificação;
• Testar para verificar o atendimento da especificação original;
• Alteração do ambiente;
• Acréscimos e/ou exclusões desautorizadas;
• Negligência humana;
• Entre outras falhas.

Concluindo:
É necessário lembrar que um ambiente seguro e estável sempre pode ser alvo de falha, por isso não podemos deixar de lado a segurança.


Referência:
ISO/IEC 15408-1:1999 Information Technology – Security Techniques - Evaluation Criteria for IT Security - Part 2: Security Functional Requirements, ISO Online Catalogue, 1999.

Introdução ao Teste de Software - Uma abordagem prática

O Fabrício dono do excelente QualidadeBR  criou um excelente matérial sobre o assunto:

Introdução ao Teste de Software - Uma abordagem prática

View more presentations from Fabrício Campos

Caixa Branca x Caixa Petra

Imagem: Amarelo Morango

Saber diferenciar estes dois conceitos é uma das necessidades dos profissionais de teste de software, neste post, eiremos examinar mais detalhes a respeito destas duas "caixas".


"Técnicas de caixa preta são uma forma de derivar e selecionar as condições e casos de testes baseados na análise da documentação seja funcional ou não-funcional, para um componente ou sistema sem levar em consideração a sua estrutura interna"

Então, a caixa preta se refere aos testes que não envolvem o código do software em teste, não envolve a estrutura interna do sistema foca em suas funcionalidades, seus requesitos.

"Técnicas de caixa branca (também chamadas de técnicas estruturais ou baseadas em estrutura) são baseadas na estrutura interna de um componente ou sistema."

São os famosos testes onde o testador tem acesso ao código fonte da aplicação e pode fazer códigos para efetuar a ligação de bibliotecas e componentes para verificar o funcioanmento de uma unidade do software (classe, método, função).


Simplificando:

Caixa branca --> Verifica o comportamento INTERNO do Software
Caixa preta --> Verifica o comportamento EXTERNO do Software



As partes em itálico foram retiradas de:  http://www.bstqb.org.br/uploads/docs/syllabus_2007br.pdf

Princípios Gerais do Teste

Uma das partes do Syllabus, Base de Conhecimento para Certificação em Teste Foundation Level, que mais chama minha atenção é esta: Princípios Gerais do Teste.

Segundo nos apresenta o Syllabus,  os princípios surgiram ao longo dos últimos 40 anos e oferecem um guia para o processo de teste como um todo.  Vejamos os princípios:

Princípio 1 – Teste demonstra a presença de defeitos


Teste pode demonstrar a presença de defeitos, mas não pode provar que eles não existem. O Teste reduz a probabilidade que os defeitos permaneçam em um software, mas mesmo se nenhum defeito for encontrado, não prova que ele esteja perfeito.

Princípio 2 – Teste exaustivo é impossível


Testar tudo (todas as combinações de entradas e pré-condições) não é viável, exceto para casos triviais. Em vez do teste exaustivo, riscos e prioridades são levados em consideração para dar foco aos esforços de teste.

Princípio 3 – Teste antecipado


A atividade de teste deve começar o mais breve possível no ciclo de desenvolvimento do software ou sistema e deve ser focado em objetivos definidos.

Princípio 4 – Agrupamento de defeitos


Um número pequeno de módulos contém a maioria dos defeitos descobertos durante o teste antes de sua entrega ou exibe a maioria das falhas operacionais. 

Princípio 5 – Paradoxo do Pesticida


Pode ocorrer de um mesmo conjunto de testes que são repetidos várias vezes não encontrarem novos defeitos após um determinado momento. Para superar este “paradoxo do pesticida”, os casos de testes necessitam ser freqüentemente revisado e atualizado. Um conjunto de testes novo e diferente precisa ser escrito para exercitar diferentes partes do software ou sistema com objetivo de aumentar a possibilidade de encontrar mais erros. Princípio

6 – Teste depende do contexto


Testes são realizados de forma diferente conforme o contexto. Por exemplo, softwares de segurança crítica (por exemplo, software do computador de bordo de aeronaves) são testados diferentemente de um software de comércio eletrônico.

Princípio 7 – A ilusão da ausência de erros


Encontrar e consertar defeitos não ajuda se o sistema construído não atende às expectativas e necessidades dos usuários.
 

Pecisa testar seu site no Ipad e não tem um Ipad?

Seus problemas acabaram! O http://ipadpeek.com/ simula um para você!

Se a Pheobe Buffay fosse uma Tester

Lembra da Pheobe de Friends?  E da sua famosa  música  Smelly Cat?
Então, o Albert Gareev fez uma versão para ela do seguinte ângulo:  E se a Phoebe fosse uma tester?

Buggy Code, Buggy Code,
How they are building you?
Buggy Code, Buggy Code,
It’s not your fault.


Did they unit test you?
Have they done the code review?
Buggy Code, Buggy Code,
It’s not your fault.

You might be a bed of bugs,
I can’t see a single “pass”.
Buggy Code, Buggy Code,
It’s not your fault.

You’re a tangle of knots,
You’re a maze to get lost.
Buggy Code, Buggy Code,
It’s not your fault.

Buggy Code, Buggy Code,
Meant to be favourite…
Buggy Code, Buggy Code,
It’s not your fault.

Quero entrar para área de teste de software. E agora?

Iniciar em uma área é sempre uma questão delicada. Quase sempres questões como o que eu preciso saber? como conseguir um emprego? são as maiores dúvidas de um profissional inciante. Caso a segunda pergunta já tenha sido respondida, o testador com emprego, certamente já terá mais algumas perguntinhas cruciais a serem respondidas. Mas vamos voltar a primeira pergunta: O que eu preciso saber?

Bom, tem um monte de conceitos básicos que são primordiais para todo testador. Comecar absorvando-os é uma ótima pedida. Leia o conceito, cerfique-se de ter compreendido e passe para o próximo. Conhecer é sempre preciso!

Tá, mas onde eu encontro esses conceitos? Eu mesmo já estou perguntado isso. Começando com uma busca no google, já dá para ter uma ideia de quais são exatamentes estes conceito. Explorando a pesquisa começa-se a enxergar a luz no fim do túneo. Experimente!

Ok, fiz a pesquisa, comecei a compreender tudo, mas eu gosto de livros! Gosto de fundamentar tudo. Tem algum livro que ajude nessa área? Sim, caro leitor, e olha bem o título dele:

Base de Conhecimento em Teste de Software, Emerson Rios

Pode ser considerado a obra referência pra os proficionais da nossa área e é indicado para para todo inciante por conter conceitos e informações que auxiliam no desenvolvimento das tarefas de nosso dia-a-dia.

Certo, vou comprar o livro. Mas eu quero aprender uma ferramenta. Todo mundo usa!!
Eu preciso aprender uma também!! Esse é o tipo de informação que me amedronta. E infelizmente, é o que mais ouço. E eis o que sempre respondo:
Vai aprender a ferramenta pra que? Você vai usa-la como? Você já tem um processo de testes definido?
E aí, rebatem: Que processo? Estou começando agora!
Então, aprenda o básico. Concentre seu esforço nisso: leia, aprenda, acesse forúns, tire dúvidas. Só depois... bem depois... comece a se preocuparar com ferramentas.


Ah, treinamentos também são sempre bem vindos:

http://www.iterasys.com.br/

http://www.cps.softex.br/agenda.php

http://www.testexpert.com.br/?q=forum/58

Se você ainda está pensando na segunda pergunta: como conseguir um emprego?, não se desespere. Esse, certamente, será um assunto para próximos posts.

Teste de Software - Deinições

“O teste de programas pode ser usado para mostrar a presença de defeitos,

mas nunca para mostrar a sua ausência.” (Dijkstra)

Caiu de paraquedas nesta página e ainda está se perguntando: mas que raios é esse tal de teste de software?

Pois bem, vamos pedir uma ajuda para os universitários:


A Wikipédia nos diz o seguinte:

"O teste do software é a investigação do software a fim de fornecer informações sobre sua qualidade em relação ao contexto em que ele deve operar. Isso inclui o processo de utilizar o produto para encontrar seus defeitos.O teste é um processo realizado pelo testador de software, que permeia outros processos da engenharia de software, e que envolve ações que vão do levantamento de requisitos até a execução do teste propriamente dito."


Já Myers, do famoso The Art of Software Testing diz que: "É o processo de executar um programa com o objetivo de encontrar defeitos"


Para Hetzel: "o teste é uma atividade cujo objetivo é avaliar um atributo ou capacidade de um programa ou sistema e determinar se este atende aos requisitos "

Bach acredita que "Teste é um processo através do qual exploramos e entendemos o status dos benefícios e os riscos associados com a liberação de um software ou sistema"

E aí, subindo no ombro de gigantes deu para ter uma ideia?



Fontes:

Bach, James, “Test Automation Snake Oil”. Windows Technical Journal, p. 40-44,

out. 1996.

Hetzel, William, “Guia Completo ao Teste de Software”. Campus, 1987.

Myers, G.J., The Art of Software Testing, 2nd edition, John Wiley & Sons, 2004.

História do Teste de Software

 

 

 

Uma das coisas que sempre me chamam atenção nas áereas que estudo é a História. Tenho curiosidade de saber o que aconteceu, como aconteceu, o que surgiu primeiro, quando Fulano fez aquela coisa...E é movida a essa curiosidade que comecei a pesquisar a história do teste de software. O Emerson Rios tem um artigo muito abrangente sobre o tema. Neste post, irei listar alguns dos fatos mais mportantes.

Nos anos 40, quando o Mark II foi lançado, foi datado, em 1947, o aparecimento do termo Bug para caracterizar um defeito.
Nos anos 50, época em que as Tabelas matemáticas auxiliavam a computação, em 1957, Charles L. Baker estudando sobre o livro Digital Computer Programming (Dan McCracken) estabelece a diferença entre tirar defeitos e testar software.

Na década de 60,os progressos começam a se tornarem mais significativos: em 61, O livro Computer Programming Fundamentals apresenta um capítulo sobre teste de software. Em 67, Num trabalho publicado pela IBM William Elmendorf fala numa abordagem para os testes funcionais. Logo em seguida, em 1968, Um relatório publicado numa conferência sobre Engenharia de Software e patrocinado pela OTAN fala sobre qualidade de software.

Jà na década de 70, em 1973, é publicado o livro: Métodos de teste de programas de William Hetzel. Nesse mesmo ano, William Elmendorf desenvolve o gráfico de causa e efeito. Outro fato importante: em 1975,Gilb publica as suas leis da falta de confiabilidade na revista Datamation. A lei dizia o seguinte: "A capacidade de encontrarmos e manusearmos defeitos de qualquer sistema serve como base para entendermos os defeitos que nós não iremos nunca encontrar.”

Em 1976, Thomas McCabe introduz o conceito de complexidade ciclomática como uma métrica de software num artigo para a IEEE e Glenford Myers no seu livro Software Confiável discute conceitos de teste de software e afirma que o objetivo do testador é fazer o programa falhar. Em 77, é publicado o livro Métricas de Software de Tom Gilbs que é considerado o livro base para um grande número de métricas de software.

Ano de 1979 "A arte de testar software" Glenford Myers publica o primeiro livro somente sobre teste de software. Nesse mesmo ano, Phillip Crosby descreve os seus famosos 14 passos para a melhoria da qualidade de softwares.

Década de 80: no seu famoso livro Software Engineering Economics Barry Boehm introduz o conceito que o custo de fixar um defeito cresce exponencialmente no tempo, isso em 1981. Em 1982, Gerald Weinberg descreve, no livro Repensando a análise e o projeto de sistemas, o desenvolvimento e o teste iterativo.

A norma IEEE 829, primeira versão do padrão de documentação de teste de software é pulbicada em 1983. James Martim publica em 1984, um manifesto sobre distribuição de defeitos onde afirma que metade dos defeitos tem a sua origem em requisitos mal definidos. E em 1986 é publicado o famoso Modelo em V.

Em 1988, Cem Kaner, Cem Kaner, Jack Falk e Hung Nguyen no seu livro Teste de Software introduzem pela primeira vez a terminologia teste exploratório. Este livro é também famoso pela abordagem pragmática dada ao teste de software. No mesmo ano, num artigo publicado na revista da ACM David Gelperin e William Hetzel discutem quatro modelos de teste e a evolução do teste de software e a empresa Qualtrak desenvolve o software DDTS (sistema de monitoramento distribuído de defeitos) para gestão de defeitos em ambiente Unix.
A década de 90 já se inicia com Boris Beizer definindo a taxonomia de defeitos no seu livro Técnicas de Teste de Software. Neste mesmo livro, Beizer demonstra o efeito do pesticida Paradox onde afirma quanto mais você testa tanto mais imune os defeitos ficam para os seus testes.

Em 1991 é publicada a ISO 9126, norma lista as seis características de qualidade que todo software deveria ter. Em 1992 é realizada a primeira conferência STAR (software testing análise e revisão) e em 93 a a primeira conferência EuroSTAR, o maior evento mundial em teste de software. Nesse mesmo ano, 93, Daniel Mosley aplica pela primeira vez o conceito de tabelas de decisão em teste de software.

Já no ano de 1995, Martin Pol, Ruud Teunissen e Erik van Veenendaal publicam o seu modelo de gerência estruturada de teste: TMap. Neste mesmo ano a Mercury lança a primeira versão da ferramenta de teste Winrunner.

Em 1998, a British Information System Examinations Board cria a primeira certificação européia em teste de software: ISEB. No ano de 1999 Martin Pol e Koomen lançam o modelo Test Process Impromement (TPI) voltado para melhoria de processos de teste de software.

Anos 200! Em 2002 acontece a fundação da ISTQB, e atualmente com sede na Bélgica o International Software Testing Qualifications Board órgão responsável pelo exame de certificação ISTQB Certified Tester. Neste mesmo ano, a IBM lança o famoso IBM Rational Functional Tester.
No Brasil, ainda em 2002, é criada a ALATS – Associação Latino Americana de Teste de Software com sede no Brasil.

Em 2003, é lançado o primeiro livro sobre teste de software em português: lançado por Emerson Rios e Trayahu Moreira o livro Teste de Software. Em 2005, é publicado a primeira versão do modelo TMMi voltado para melhoria de processo de teste de software.

Outra marca brasileira: em 2006 é realizado no Brasil o primeiro exame CBTS – Certificação Brasileira em Teste de Software. E em, 2008 é lançada a primeira primeira versão do modelo MPT (Melhoria de Processo em Teste de Software) voltado para melhoria do processo de teste de software.
Claro que desde 2008 até os dias atuais ainda ocorreram mais alguns eventos super importantes, mas isso já é assunto para outro post.

Fonte: RIOS Emersom, Historória resumida em fatos do Teste de Softwate, disponível em
<http://www.iteste.com.br/LinkClick.aspx?fileticket=FI3CvtavRpk%3d&tabid=249&mid=440>