Primeiros passos com Testes de Performance

Pessoal, neste post gostaria de fazer uma pequena introdução sobre testes de performance. Neste caso, não irei falar muita teoria e sim alguns itens essenciais para iniciar os estudos.

Atualmente estou participando de uma célula de estudos referente ao assunto e irei aproveitar pra postar um pouco no blog o aprendizado, pois não é que falam que quando ensinamos aprendemos duas vezes? Acredito que sim.

A minha intenção é criar vários artigos relacionados ao tema, e manter sempre atualizado este post, pois ele será o “start up”, um guia para começarmos os estudos.

Segue abaixo alguns itens que na minha visão é necessário para começar a estudar performance, caso alguém que já atua na área quiser sugerir algo, fique a vontade para colocar nos comentários, será de grande valor a ajuda.

Bom, chega de balela e vamos começar a falar sobre o assunto e conhecer do que precisamos para entrar no mundo dos testes de performance:

Gostar de leitura.

Não há como fugir! Existe muito conceito teórico sobre testes de performance, e se você quer ser um profissional da área, é obrigatório a leitura. Tenho certeza que você não vai querer ficar “boiando” quando conversar com algum profissional da área e discutir alguns conceitos como: load balancer, Throughput, Think Time, entre outros (sentiu o drama né?).

Inglês.

A maioria dos materiais de qualidade sobre o assunto que você encontrar na internet estão em inglês, portanto quanto mais conhecer o idioma melhor. Sem contar que a maioria das ferramentas pelo meu conhecimento estão em inglês. A ferramenta da Rational, Rational Performance Tester, até possui o idioma português, porém mesmo assim o interessante é utiliza-lá em inglês para praticar o idioma.

Conhecimento em programação.

Para executar estes tipos de testes é necessário um bom conhecimento em programação.

Neste caso, é importante saber programação, pois para alguns testes você irá reparar que não basta somente gravar um script de testes.

Há a necessidade de fazer um código, por exemplo, para gerar o CPF para inserir no sistema toda vez que o teste for executado, e você não vai poder colocar sempre o mesmo valor (é ai que entra a programação, você irá criar um código customizado para o seu script fazer esta tarefa).

Se você utilizar a ferramenta Rational Performance Tester (Ferramenta IBM), você utilizará a linguagem Java para codificar e caso utilize o LoadRunner (Ferramenta HP), poderá optar pelas linguagens C, Java ou Visual Basic.

Conhecimento em várias áreas de TI

Existem várias razões que podem impactar a performance de um sistema, seja uma query que foi mal elaborada, um problema na rede, consumo da memória do computador, etc. Portanto, neste caso quando você se deparar com algum determinado problema que ocorre, ficará fácil direcionar sua pesquisa ao foco do problema.

Infra-estrutura:

Diferente do mundo da programação, para os testes de performance instalar a ferramenta não siginifica que você conseguirá estudar e fazer exercícios práticos. Pois precisamos de uma aplicação, onde toda a funcionalidade dela esteja OK (de nada adianta testar performance se ela possui problemas em sua funcionalidade).

Sem contar que envolve toda uma infra-estrutura necessária (hardware potente, boa rede, servidor, etc).

Até o momento da minha jornada, deparei com estes itens para continuar com os meus estudos, porém conforme eu vou descobrindo novidades irei atualizando este post.

No próximo artigo sobre testes de performance irei citar algumas leituras e tentarei abordar o assunto mais para o lado técnico.

Até a próxima!

Abraços.


8 dicas para uma escrita de Casos de Testes

Para as execuções dos testes funcionais, é comum a Criação de um Caso de Teste para a execução de cada condição de teste identificada pela equipe.

Geralmente este documento inicia falando sobre o objetivo do teste, seguido por uma pré-condição, que lista todos os itens ou condições que devem estar disponíveis para realizar o teste.

Em seguida, descrevemos a pós-condição que possui uma breve descrição do que deverá acontecer no término do teste.

Finalmente, partimos para a descrição do passo-a-passo, onde para cada passo descrito deve conter um ponto de verificação citando o resultado do passo executado.

Descrevendo desta maneira, temos a impressão de que tudo parece ser muito simples e fácil, basta seguir os passos descritos e os testes poderá ser executado facilmente.

Muito bom se fosse verdade! Se o Caso de Testes não for bem escrito, poderemos correr o risco de perder uma execução do teste e recomeçar tudo novamente.

Abaixo, cito 8 itens que acho interessante ficar atento quando criamos um Caso de testes:
1. Defina bem a pré-condição do teste:

Na minha opinião, definir muito bem a pré-condição poderá garantir 50 % da execução dos testes. Quando ela é bem descrita não corremos o risco de perdermos o teste, pois é muito desconfortável deparar com um passo pedindo para executar uma ação no sistema que pode não estar preparada, pois não foi citada na pré-condição. (simples exemplo: pedir a exclusão de um usuário específico cadastrado, e na pré-condição não citar a criação de um usuário para excluir).

Escreva de forma clara a pré-condição, se necessário faça como se fosse um passo-a-passo mesmo. Cite em ordem de prioridade as ações que devem ser feitas, como deve ser criada a massa de dados para o testes e o que deve ser feito por primeiro, segundo, etc.

Deste maneira o testador não irá descobrir somente no momento da execução o que devia ter preparado antes de iniciar os testes.

2. Escreva os Casos de Testes conforme citado no Caso de Uso.

O Caso de Uso contém todas as informações necessárias de como o sistema deve funcionar. Portanto, desenvolvedores e testadores não precisam imaginar ou supor como deve funcionar o sistema (salve exceções, em que há necessidade de discustir algumas regras).

Crie os Casos de Testes baseado no Caso de uso, assim a chance do sucesso dos testes será grande.

Um bom ponto de atenção, é que devemos sempre estar atentos com as atualizações dos Casos de Uso, pois muitas vezes as regras são alteradas e consequentemente pode ser necessário atualizar os Casos de Testes.

Nem todo Caso de Uso pode ter sido escrito de forma clara e conter todas as informações necessárias, neste caso não tenha medo de procurar o Analista de Requisitos que escreveu o documento.

3. Defina um bom título para o Caso de Testes.

Sei que não é uma tarefa fácil escrever em poucas palavras um bom título para o caso de Testes. Se possível coloque no Caso de Testes se cenário a ser testado é uma condição positiva ou negativa e o que será feito.

Muitas vezes o sistema a ser testado possui uma grande quantidade de Caso de Testes criados, portanto definir um bom título poderá permitir um acesso fácil para eventuais consultas destes documentos.

4. Cuidado com o português (escrita).

Este é um ponto que não só devemos tomar cuidado com o português na escrita do Caso de Testes, e sim com o nosso dia-a-dia. Muitas vezes, os Casos de testes são revisados por um membro da equipe e chegando até ao cliente do sistema para revisão do mesmo.

5. Numerar os Passos.

Esta é uma boa forma de organizar melhor os passos, auxiliando durante a execução dos testes. A numeração nos passos permite o testador se organizar melhor com os passos e caso ocorra a necessidade de parar os testes por um minuto, ele saberá em qual passo voltar.

6. Escreva os passos na forma imperativa

Use as palavras na forma imperativa, como “Digite um nome no campo”, “Escolha uma opção”, etc. Utilizando estes termos passamos a mensagem de que realmente deve ser feita uma ação e organizamos melhor nossos casos de testes seguindo um padrão na escrita.

7. Seja claro com os pontos de verificação.

Nunca deixe dúvidas com os pontos que devem ser verificados. Troque frases como: “o sistema PODE exibir uma mensagem” por “o sistema DEVE exibir uma mensagem”. Desta maneira não deixamos dúvida do que pode acontecer ao executar aquele passo e se acontecer algo diferente do descrito, teremos um defeito.

8. Atenção ao colocar imagens e nome de Campos.

Se o Caso de Teste não possuir o objetivo de verificar a usabilidade e o layout do sistema, tome muito cuidado ao citar os nomes do campo.
Como já citado, os Casos de Uso podem sofrer por atualizações que são impactadas no sistema, fazendo com que seja necessário mudar algum layout do sistema ou campo fazendo com que fique diferente do citado no Caso de Testes.

Por mais que alguns pontos citados parecem ser óbvios, quem já passou pela execução e criação de Casos de Testes sabe que na realidade é diferente. Sempre busque melhorar os Casos de Testes, pois com certeza todos da equipe tem a ganhar.

Não tenha medo de escrever demais, ou deixar o Caso de Testes comprido, desde que haja a necessidade. É melhor as vezes pecar pelo excesso do que deixar faltando algo!

Caso queiram citar mais algum ponto sintam-se livres para citar nos comentários que será muito bem-vindo!


Aplicando a Técnica 5W1H no processo de abertura de defeitos

Aplicando a técnica 5W1H em abertura de defeitos.

Semana passada participei de uma pequena reunião com a minha líder do projeto, onde ela apresentou a técnica 5W1H e discutiu sobre o processo de abertura de defeitos. Ela nos apresentou uma técnica que surgiu na área de qualidade que pode ser aproveitada em nosso dia-a-dia e achei interessante compartilhar neste artigo.
Primeiramente vamos ver um pouco sobre a importância de abrir um defeito com qualidade e em seguida sobre a técnica 5W1H e como podemos utilizá-la no processo de abertura de defeitos.

A importância de especificar um defeito com qualidade.

De nada adianta o testador realizar um bom teste e na hora de reportar um defeito para o programador não o fazer com eficiência. O defeito a ser aberto deve ser claro e possuir informações realmente necessárias.
Quando o defeito é objetivo e claro, a equipe ganha tempo e evita desgastes desnecessários, pois o defeito é validado com facilidade pela pessoa responsável e é enviado ao programador que compreende logo o defeito e trabalha na solução.
A maneira da escrita do defeito varia de cada profissional e acaba sendo em minha opinião uma espécie de identidade do testador. Identidade? Sim! Pois ao longo do trabalho o programador/gerente de defeito vai conhecendo o trabalho do testador que ao ler a descrição do defeito sabe quem o reportou.
Por outro lado, mesmo que cada um possua sua “identidade” nos defeitos, existem itens essenciais que não podem faltar na descrição do mesmo e para isso podemos utilizar a técnica 5W1H.

A Técnica 5W1H:

Esta técnica é muito conhecida na área de qualidade, marketing, TI, entre outras. O 5W1H ajuda na investigação do problema e com as informações obtidas com as 6 perguntas básicas, oferece uma respota clara e objetiva. Com esta técnica podemos adaptá-la com o processo de abertura de defeitos.

Ela é composta por seis simples perguntas:

What: O que?
When: Quando?
Who: Quem?
Why: Porque?
Where: Onde?
How: Como?

Agora vamos pensar na visão da abertura de um defeito e fazer estas simples perguntas:

What: Qual?

Qual é o problema que aconteceu no sistema?
O que ocorreu?

Ex: Sistema não realiza a venda do produto.

When: Quando?

Quando isto ocorre?
Quando não ocorre?
Este problema já vinha acontecendo?

Ex: Quando o sistema possui muitos produtos no pedido do cliente.

Who: Quem?

Quem é impactado?

Ex: Usuários que possuem um cadastro recente. Usuários finais, etc.

Why? Porque?

Porque o problema ocorre?
Porque deve ser resolvido logo?

Ex: Este problema ocorreu porque era uma grande quantidade de produtos

Where: Onde?

Onde ocorreu o problema?
Qual link/funcionalidade do sistema que ocorreu?
Qual ambiente/hardware?

Ex: Problema ocorreu no aplicativo móbile de celular.

How? Como?

Como aconteceu?
Como chegou a este problema?

Desta maneira, podemos utilizar estas perguntas para nos auxiliar a compor um defeito, tornando-o claro para o desenvolvedor:

Exemplo prático:

Severidade do defeito: 2

Headline:
Usuário final não efetua compra de uma grande quantidade de produtos através do software para móbile.

Descrição:

1. Acessar o aplicativo InfoLoja do Iphone e realizar o login com os seguintes usuários:
Login: vinisabadoti
Senha: as78dj098k
2. Preencher o carrinho de compras com mais de 5 produtos e fechar o pedido.
3. Informar os dados do pagamento com cartão de crédito e confirmar compra.

Resultado esperado: Sistema exibe mensagem da confirmação do pedido informando o número do pedido para futura consulta.

Resultado obtido: Sistema não confirma a compra e direciona o usuário para página inicial.

Verificar passo nº X da evidência em anexo.

Como no exemplo citado acima, fica muito fácil para a pessoa que irá validar o defeito entender e juntamente com uma evidência em anexo, comprova com imagens que o defeito foi encontrado conforme os passos descritos.
Desta maneira, quando o defeito foi validado e chega ao desenvolvedor, ele poderá entender facilmente o defeito. Claro que não são em todos os defeitos que é possível aplicar todas estas perguntas, porém podemos analisar quais se encaixam para reportá-los com maior qualidade.

Espero que tenham gostado e que esta técnica possa ajudar a vocês de alguma maneira, ajudando assim a fazer um trabalho com qualidade.
Afinal, não adianta exigir qualidade do software que testamos se em nosso próprio dia-a-dia não aplicamos qualidade no serviço em que fazemos.
Gostaria de agradecer a Lyamara Bonvechio pelo conhecimento transmitido e por deixar eu escrever um pouco sobre a técnica e compartilhar ela aqui no blog!

Caso queiram saber mais sobre a técnica, segue abaixo alguns links interessantes:

http://nccur.lib.nccu.edu.tw/bitstream/140.119/35210/7/35602807.pdf
http://www.mindmapinspiration.com/using-5w-1h-as-a-90-10-solution-finder/
http://www.canallmarketing.com/uploads/2/7/7/6/2776543/5w1h.pdf


Histórico sobre Testes de Software

Olá pessoal!

Este post faz parte da minha monografia que foi entregue no semestre passado em minha faculdade. Espero que gostem deste artigo, pois não foi fácil fazer!

Durante as pesquisas para a elaboração deste trabalho acadêmico, não foi encontrado nenhum material que descreva claramente o início e a evolução da área de Testes de software. Pode ser que exista algum material, porém em pesquisas feitas em sites especializados, blogs, e consulta a vários profissionais da área, não foi encontrado nenhum artigo que tratasse sobre o assunto. Portanto, este histórico foi criado com uma consulta e resumo de alguns fatos marcantes com uma atenção ao cenário nacional.

Para começar a falar sobre testes, podemos citar sobre a origem do termo bug, que inicialmente não surgiu com os softwares. O termo bug quer dizer inseto, porém na área de informática ele ganhou outro significado, pois quando ocorria um erro de programação, o termo bug era utilizado.

Thomas Edison teve problemas de leitura em seu fonógrafo com um inseto em 1878 e em todos os defeitos industriais passou a denominá-los como bug. Já o primeiro bug em computadores foi encontrado em 1947, os engenheiros que trabalhavam com a máquina Harvard Mark I, encontraram um inseto nos circuitos. Este inseto estava causando um erro nos cálculos da máquina. Ao ser encontrado, o inseto foi retirado e colado no livro de registro com a intenção de registrá-lo como o primeiro bug encontrado.

Com o livro “The art of software testing” Glenford Myers trouxe ao leitor um conhecimento mais avançado sobre testes, abordando sobre as técnicas de software no ano de 1979.

Este livro é muito conhecido pelos profissionais, podendo ser tratado como uma referência teórica, com o ano de 1979 um grande passo para a área. O livro possui uma coletânea de materiais sobre testes de software. Atualmente este livro se encontra em sua 2ª edição e é utilizado até os dias de hoje, onde muitos o consideram como o marco inicial de Testes de Software.

Os modelos prescritivos de desenvolvimento de software surgiram na década de 80. Estes modelos, cascata, espiral, entre outros foram criados para organizar e inserir padrões no processo de desenvolvimento de software. Ele é composto por vários processos genéricos: comunicação, planejamento, modelagem, construção e implantação.

Dentro do processo construção, estão presentes as atividades de desenvolvimento e testes. Foi a partir desta organização que o conceito de testes de softwares tornou-se mais conhecido. Vale lembrar que testes também está presente em outros processos, como planejamento, modelagem e implantação.
Neste ano, surgiram também as primeiras ferramentas para o auxílio de testes funcionais. Com seu sucesso, surgiram novas ferramentas para gerenciamento de testes com a intenção de organizar, manter dados, resultados e apresentar relatórios.

Sendo assim, em 1990 os fornecedores passaram a integrar em uma suíte única, ferramentas para testes funcionais e de gerenciamento.
A partir do ano de 1995 surgiram as primeiras ferramentas para automação de testes de performance para algumas plataformas.
No ano de 2002, surgiu no Brasil a Associação Latino Americana de Teste de Software (ALATS).

A ALATS é uma entidade sem fins lucrativos que foi criada com a finalidade de reunir profissionais das áreas de teste e de qualidade de sistemas com o intuito de servir de apoio a troca constante de informações objetivando a melhoria dos processos de teste, mantendo-se a sua integração como o processo de desenvolvimento de aplicações. (ALATS).

Atualmente a ALATS promove palestras, encontros mensais e seminários. Dentre os eventos, o mais conhecido é o Seminário Brasileiro de Teste de Software (BRATESTE). Este seminário abrange assuntos como processos de testes, técnicas, palestras e tutoriais.

Os profissionais brasileiros podem contar também com instituições internacionais que atuam no país, como o International Software Testing Qualifications Board (ISTQB) fundado em Edinburgh (Reino Unido) em novembro de 2002. O ISTQB chegou ao Brasil em 2006 com o nome de Brazilian Software Testing Qualifications Board (BSTQB). O BSTQB oferece o exame de certificação do ISTQB, treinamentos e download do material em português.

A primeira certificação brasileira de testes foi criada pela ALATS e no ano de 2006 surgiram os primeiros profissionais certificados com a Certificação Brasileira de Testes de Software (CBTS).
Atualmente podemos encontrar uma grande quantidade de certificações, ferramentas e conteúdo sobre testes de software. Livros, blogs, listas de discussões, são alguns exemplos de conteúdos que podem ser facilmente encontrado.

Antes de citar minhas fontes, gostaria de agradecer a algumas pessoas que de alguma forma me ajudaram dando dicas, opiniões ou ao menos se prontificaram a ajudar: Carolina Fontana, Fabrício Ferrari, Camilo Ribeiro, Fernanda Thiesen e Marcelli Barbosa

Abaixo, uma imagem para ilustrar resumidamente os fatos da área:

Fontes:

http://qualidadebr.wordpress.com/2008/06/22/o-que-e-bug/

http://myoldmac.net/FAQ/firstComputerBug.htm

http://blog.prasabermais.com/2010/02/15/histrico-da-evoluo-das-ferramentas-para-testes-e-qualidade-de-software/

http://istqb.dedicated.adaptavist.com/display/ISTQB/Brazilian+Software+Testing+Qualifications+Board+%28BSTQB%29

http://istqb.dedicated.adaptavist.com/display/ISTQB/History?atl_token=XcZn9CV4Ee

Livro Engenharia de Software de Roger S. Pressman.


Pesquisa para trabalho de TCC

Pessoal, atualmente estou em meu último ano de faculdade de Sistemas de Informação e estou desenvolvendo meu trabalho de conclusão de curso na área de Testes de Software. Gostaria de contar com a ajuda das pessoas que trabalham em empresas de desenvolvimento que respondam este pequeno questionário que criei no google docs.

A minha intenção é saber destas empresas quais possuem uma equipe de testes, quais tipos de testes aplicam, etc.

[ 21/08 – com a pesquisa concluída o link foi removido]

Desde já agradeço a ajuda!


Carreiras em TI – Testes de Software III

Pessoal estou postando mais uma entrevista com uma profissional na área de testes de software. O que mais gosto destas entrevistas é que cada profissional tem algo diferente e interessante para contar de experiência. Outro motivo é que um dos termos mais pesquisados que aparece no wordpress é este, portanto acho legal compartilhar mais este assunto.

A entrevista é com a Marcelli, minha amiga que trabalhou comigo no projeto do Santander e que me ajudou com os testes em Mainframe.

1. Como você conheceu e se interessou por testes?

Não conhecia a área de testes até entrar na IBM (Fevereiro de 2006). Eu imaginava que as empresas testavam seus produtos (softwares) mas não tinha noção de quão organizado e estruturado eram esses testes. Me interessei rapidamente por esta área, pois envolve muito a parte de análise, requisitos, leitura de documentos, que eram as áreas que já me chamavam atenção.

2. Quais as atividades de um profissional que trabalha nesta área?
São muitas. Resumindo, para um analista de teste:

• Ler, ler, ler e ler os requisitos do sistema. É o documento principal para seus casos de testes. Não assuma nada, tire todas suas dúvidas com o responsável pelo requisito. E leia também qualquer outra documentação do projeto que possa ajudar no entendimento da nova funcionalidade.
• Com base no que você leu, planeje os cenários de teste, pense na pré e pós condição, resultados esperados, dados específicos etc.
• Crie os casos de teste, e escreva o passo a passo. Vale ressaltar que o passo a passo deve ser escrito não só para você, ou seja, todos precisam entender e conseguir seguir o roteiro feito por você.
• Envie seus casos de teste para revisão e aprovação do cliente quando necessário. E analise as alterações sugeridas pelo mesmos.
• Quando o ambiente de teste estiver liberado, inicie a execução. Tire evidência dos passos de seu caso de teste, e quando o resultado obtido for diferente do resultado esperado, reporte este defeito e reteste assim que corrigido.

Paralelo a todos os itens acima, mantenha a ferramenta de testes que você utiliza atualizada com seus resultados.
Bom, acima é só um resumo de algumas das atividades de um analista de teste, porém dentro da área de Teste de uma empresa, temos vários cargos. Por exemplo, se você for um Líder de Testes terá que acompanhar e coordenar as atividades citadas acima, se for um Analista de teste de performance terá outras atividades adicionais etc..

3. Para trabalhar com testes é necessário saber sobre outras áreas?

É necessário ter um conhecimento de Lógica, raciocínio lógico para criar as situações de teste necessárias, e dependendo da aplicação que você for testar é necessário alguns skills específicos, como por exemplo: Mainframe, SQL etc.

4. Qual foi o defeito mais difícil que você encontrou?

Não me lembro de um em específico, mas defeitos que envolvem processamento batch, jobs em geral que passam dados de um sistema para o outro etc.

5. Alguma vez alguém já falou para você que testar não é preciso?

Os desenvolvedores hahahaha. Brincadeira, nunca ouvi isso diretamente, mas várias vezes já ouvi dos desenvolvedores: “Eu já testei e está tuuuudoo certo”.

6. Quais são os tipos de testes mais complicados?

Mainframe – batch, que eu já testei…mais complicado pois sempre envolve problemas de acesso, precisa ter um skill específico para acessar os diretórios etc. Performance parece ser complicado também, mas não conheço.

7. Dicas para quem está começando (materiais/links/etc).

Fazer um curso de inglês pois a maioria das empresas colocam como pré requisito;
– Para aprender sobre testes o livro BASE DE CONHECIMENTO EM TESTE DE SOFTWARE é muito bom;
– Ter concentração, pois precisamos ler vários documentos, e ter um bom raciocício lógico;
– Estudar algumas ferramentas de teste (Rational por exemplo) pode ser um diferencial;
– Fiz um estudo para minha monografia sobre Testes, especificamente sobre MAPEAR CASOS DE USO EM CASOS DE TESTE, quem tiver interesse sobre o assunto pode me contactar.

Obrigado Marcelli pela colaboração! Muito boa a descrição da atividade de um analista de testes, com certeza dá uma boa idéia sobre o papel deste profissional.

Para quem tiver o interesse em ver a monografia dela ou quer alguma ajuda, pode entrar em contato que ela irá responder com todo prazer: marcellitb@hotmail.com

Abraços a todos.

Vinicius Sabadoti


Scrum em Menos de 10 Minutos

Como estou começando a criar o meu TCC estou pesquisando sobre as metodologias ágeis e no blog do meu amigo André Baltieri encontrei um video muito interessante sobre Scrum.

Este video fala sobre os principais conceitos sobre o tema em menos de dez minutos! Para quem ainda não conhece, vale a pena conferir:

Obrigado André por autorizar a postar aqui também!

Abraços a todos.

Vinicius Sabadoti