Translate

segunda-feira, 12 de março de 2018

Técnica de Inspeção: Leitura Baseada em Perspectiva - PBR

Perspective-Base Reading (PBR) é uma técnica de inspeção de software para detectar defeitos em todos os artefatos durante um processo de desenvolvimento, desde a documentação até o código.

Com PBR, um mesmo artefato pode ser inspecionado em diferentes perspectivas, ou seja, na visão de cada papel envolvido no processo de desenvolvimento. Por exemplo, nos papéis do cliente, do analista, do desenvolvedor, do testador, do usuário, etc.

Para cada perspectiva o inspetor é orientado com um conjunto de questões, que relacionam o artefato inspecionado com a visão de cada papel.

Em PBR, os tipos de defeitos podem ser classificados em [1]:

1. Omissão: qualquer requisito, atributo ou classe, que não tenha sido definido.
2. Fato incorreto: um requisito que não poderia existir nas condições especificadas para o sistema.
3. Ambiguidade: múltiplas interpretações para uma mesma característica de um artefato.
4. Inconsistência: dois ou mais requisitos que conflitam com outro.
5. Informação extra: informação desnecessária ou que não está sendo utilizada, a qual pode confundir a leitura.

Uma das principais vantagens desta técnica é que o mesmo questionário de inspeção pode ser utilizado em diferentes projetos. Com isso, o tempo preparação é praticamente nulo.

No entanto, quando o inspetor não tem muita experiência, reutilizar o mesmo questionário em diferentes projetos, pode ser uma desvantagem. Pois, as questões às vezes são abstratas e gerais, o que pode fazer com que o inspetor não identifique todos os defeitos que realmente existem.

Um exemplo prático desta PBR, técnica para Inspeção de Software, pode ser verificada no documento abaixo:

Obs.: Este modelo é apenas um exemplo, ele deve ser completado com outras perspectivas, caso queira usar na prática.

Fonte:

[1] F. Shull, I. Rus, and V. Basili. How perspective based reading can improve requirements inspections. IEEE, 2000.
https://pdfs.semanticscholar.org/6eee/96d7b35917d06e4e8485acdeee0b80059f26.pdf 

sexta-feira, 9 de março de 2018

O processo para realizar uma Inspeção de Software

Inspeção de Software é uma técnica de revisão da documentação de um software, que tem a finalidade de verificar a consistência de cada documento em diferentes fases de desenvolvimento.

A principal vantagem desta técnica é que ela não depende que exista uma primeira versão do código do sistema para que sejam iniciadas as atividade de qualidade de software.

Em alguns livros, a técnica de inspeção é conhecida como "Teste Estático". Logo, o teste de software, que é a verificação feita no sistema em execução, seria o "Teste Dinâmico".

O processo de inspeção de software tradicional [1] define as atividades para 3 diferentes papéis, que são: 

1. Moderador: é responsável por gerenciar a equipe de inspeção e por orientar os inspetores. Por exemplo, Gerente de Qualidade.
2. Inspetor: são os responsáveis por inspecionar a documentação do sistema durante todo o processo de desenvolvimento.  Por exemplo, Engenheiros de Qualidade ou Testadores de Software.
3. Autor: são os responsáveis por produzir a documentação do sistema durante todo o processo de desenvolvimento. Por exemplo, Analistas de Sistema, clientes ou Desenvolvedores de Software.

O processo de inspeção é composto por 5 atividades principais, que são:



1. Planejamento: nesta etapa o moderador define a equipe de inspeção e também organiza os documentos a serem inspecionados. 
2. Preparação individual: os inspetores analisam cada artefato de software, individualmente e produzem um relatório com cada defeito encontrado. 
3. Reunião de inspeção: é feita uma reunião entre o moderador, o inspetor e o autor do artefato, a fim de avaliar se as divergências encontradas são defeitos realmente ou são falsos positivos. 
4. Retrabalho: o autor corrige os defeitos encontrados. 
5. Continuação: a documentação do software corrigida é passada para o moderador, que decide se aquele artefato deve ou não ser novamente inspecionado.

Dentre as técnicas de inspeção de software mais comuns, temos:

1. Inspeção Ad hoc: que não segue nenhum padrão para realizar a inspeção, mas apenas o conhecimento do inspetor. 
2. Inspeção com Checklist: que é composto por uma lista de questões que guiam o inspetor sobre o que deve e o que não deve estar nos artefatos.

Um exemplo sobre uma técnica que usa Checklist é a PBR (Perspective-Base Reading)

Fonte:
[1] M.E. Fagan. Design and code inspections to reduce errors in program development. In IBM Systems Journal, pages 182–211, 1976.

terça-feira, 20 de dezembro de 2016

Melhor Momento para Automação dos Testes de Software

Existem muitas maneiras de automatizar o teste de software, a primeira e mais comum é através do teste de caixa-branca, onde muitas vezes é utilizado o teste unitário (p.ex. JUnit). Este tipo de teste é realizado pelo desenvolvedor e é bastante útil para garantir que um novo componente do sistema não parou de funcionar quando uma nova parte do sistema foi desenvolvida.

No entanto, é possível automatizar os testes de caixa-preta também, ou seja, os testes funcionais, que verificam se o sistema, do ponto de vista do usuário final ao interagir com a interface do sistema, não apresenta nenhum erro em seu funcionamento. Assim, esse tipo de teste é realizado a partir das telas, campos e botões do sistema.

Imaginamos um mundo ideal e perfeito, quando pensamos em um sistema que tenha todos os seus testes automáticos prontos, então o trabalho de realizar testes se resumirá apenas à máquina. Mas, na realidade, é necessário planejar o momento certo de realizar esses testes funcionais automáticos

Se imaginarmos um cenário em que o sistema está sendo desenvolvido e possui algumas versões em produção, mas o cliente está sempre trazendo novas funcionalidades, melhorias na interface, retirando outras funcionalidades, então este não será o melhor momento para automatizar os testes funcionais. Pois, neste caso, a interface do sistema, estará sofrendo bastante alteração, logo os testes terão que ser atualizados constantemente, gerando um grande retrabalho em manter os testes. Neste cenário, é recomendável os testes de caixa-branca automáticos feitos pelos desenvolvedores e os testes caixa-preta manuais feitos pelos testadores.

Assim, o melhor momento para realizar os testes funcionais automáticos é como teste de regressão, quando se tem um sistema que já está em produção, com várias versões estáveis e com poucos defeitos, ou seja, que precisa fazer pequenos ajustes no sistema raramente. Pois, neste caso, a interface do sistema irá sofrer poucas alterações, então o custo de manter os testes automáticos será baixo e a eficiência dos testes será alta. Existem algumas ferramentas para realizar os testes funcionais automáticos, neste caso é necessário verificar quais as tecnologias e as linguagens utilizadas no sistema a ser testado.


quarta-feira, 21 de setembro de 2016

Aplicativos para Celular: Nativo x Híbrido

Para quem quer realizar testes automáticos em uma aplicação para celular precisa, primeiramente, conhecer os termos utilizados no desenvolvimento destes sistemas. Saber se o aplicativo será feito para as plataformas Android, iOS ou Windows Phone é o primeiro passo e geralmente o mais simples. 

Outros termos que aparecem bastante na documentação das ferramentas de teste são sobre o desenvolvimento destes aplicativos, ou seja, se eles são Aplicativo Nativo ou Aplicativo Híbrido.

Quando um aplicativo é nativo, isto quer dizer que ele foi desenvolvido para utilização em apenas uma plataforma, seja Android ou iOS ou Windows Phone. Com isso, este aplicativo poderá ter acesso direto aos recursos do aparelho, onde ele está instalado, como: GPS, câmera, calendário, contatos, etc. Uma característica desse aplicativo é que nem sempre precisa de internet.

O aplicativo híbrido é desenvolvido utilizando códigos da web (HTML5 e JavaScript) juntamente com frameworks de linguagem nativa, que permitem que eles sejam instalados nos aparelhos celulares. Assim, eles geralmente utilizam recursos do aparelho de forma indireta, através desses frameworks e alguns desses aplicativos precisam de internet para funcionar.

Uma das vantagens do aplicativo híbrido é que ele poderá ser executado em diferentes plataformas, no entanto terá algumas limitações de recursos com relação ao aplicativo nativo.

A diferença entre um Aplicativo Híbrido e uma aplicação para Web Mobile é que o primeiro poderá ser instalado no aparelho celular e o segundo é apenas um site que possui uma interface adaptada para o navegador do celular. Com isso, o Web Mobile não tem acesso aos recursos do celular, mas tem a vantagem de não precisar obter a aprovação da App Store.

Assim, só conhecendo como o aplicativo foi desenvolvido, é que será possível decidir qual ferramenta será mais indicada para realizar os testes automáticos no celular.

quarta-feira, 6 de agosto de 2014

Ferramentas de Testes em Aplicativos para Celular

De acordo com o artigo anterior sobre Automação dos Testes em Aplicativos para Celular que relata sobre a importância de realizar testes automáticos em aplicativos para celular, segue abaixo uma lista das principais ferramentas com este propósito. Algumas das ferramentas são pagas, mas possuem a versão trial e outras são open source.

Ferramentas Open Source:

  1. Appium: é uma ferramenta que permite realizar testes funcionais automáticos em Mobile Web (navegador), Android App ou iOS App. O seu diferencial é que os testes podem ser escritos independentes da plataforma do sistema a ser testado, seja ele Android ou iOS.
  2. Selendroid: com esta ferramenta é possível realizar testes em Android App (nativo ou híbrido) e Mobile Web. O celular deve estar conectado ao computador durante os testes.
  3. TestingWithFrank: é basicamente uma ferramenta equivalente ao Selenium, só que para aplicativos de iOS. Ela reúne várias ferramentas open source, como: UISpecCocoahttpserver Cucumber. O objetivo dela é automatizar os testes de aceitação através da interface gráfica para um aplicativo de iPhone ou iPad.
  4. Monkey Talk: esta ferramenta pode ser usada para automatizar testes funcionais para iOS e Android. Ela dá suporte a JavaScript e pode ser integrado ao Eclipse. Em 2015, esta ferramenta se tornou um produto da Oracle.
  5. NativeDriver: é uma implementação da API de WebDriver e está trabalhando em drivers para Android, iOS e Windows Mobile / Windows Phone. Em 2016, não encontrei mais o repositório do GitHub para esta ferramenta.

Ferramentas Pagas:

  1. Robotium: é uma ferramenta poderosa para escrever testes automáticos confiáveis ​​em um mínimo de tempo. Os testes são escritos em Java e há projetos para escrevê-los em outras linguagens como Python. Os testes não podem ser executados nos celulares, apenas no emulador.
  2. EggPlant: suporta várias plataformas de desenvolvimento móvel, tais como iOS, Android e Windows Mobile / Phone.
  3. Ranorex: ela pode ser usada para testar automaticamente aplicações para celular em iOS, Android e Windows 8. Ela permite gravar diretamente os seus testes no celular para construir seus testes.
  4. SilkMobile: ferramenta de automação de teste para web, iOS, Android, Blackberry e Windows Phone, que permite criar e executar os testes automatizados.
  5. SeeTest: ferramenta para iOS, Android, Blackberry e Windows Phone. Ela permite que você grave seus testes em dispositivos reais e pode ser usada para construir multi-plataforma de automação de teste suites.
  6. T-Plan Robot: é uma ferramenta para várias plataformas como Windows, Linux ou Mac. Realiza testes através de uma simulação da interface gráfica do aplicativo para celular, gravando em scripts os testes para que possam ser executados posteriormente. 

Atualização em 21/09/2016

sábado, 28 de junho de 2014

Sobre Automação dos Testes em Aplicativos para Celular

 Cada vez mais aplicativos para celular são criados e utilizados por muitas pessoas em seus tablets e smartphones. Desenvolver e realizar testes nestes aplicativos de forma ágil para que eles sejam lançados de forma satisfatória e rápida não é fácil.

Para que uma empresa de aplicativos se mantenha no mercado, é importante que ela possua boas avaliações de seus usuários. Pois, caso contrário, poucos irão se interessar pelos produtos com baixa avaliação e pesquisarão pelos mais bem avaliados.

O que pode influenciar nas avaliações destes aplicativos, além da sua utilidade e facilidade de uso, é o número de falhas que ocorrem para os seus usuários. Se o número de falhas for muito alto, os usuários vão desinstalar o aplicativo e fazer um comentário negativo sobre aquele produto.

Com isso, testes funcionais são bem relevantes para que as empresas consigam se manter no mercado, lançando novos aplicativos e mantendo nele os que já produziram. Os testes funcionais ajudam a equipe a identificar o quanto antes se o aplicativo se comporta conforme o esperado e se não produz nenhuma falha durante o seu uso.

Desta forma, quando se inicia um projeto de desenvolvimento de aplicativos para celular é importante fazer um planejamento de quais tipos de testes serão realizados, como e quando serão testados e até mesmo se será necessário automatizar algum teste.

Realizar teste em um aplicativo é equivalente a fazer testes em uma aplicação web. No entanto, a frequência em que os aplicativos são atualizados é muito maior do que as aplicações web. Isto indica, que frequentemente uma versão daquele aplicativo foi lançada, logo, novos testes tiveram que ser realizados, a fim de verificar se houve alguma falha naquela nova versão.

Diante de tantas atualizações nos aplicativos, é mais indicado que sejam realizados testes automáticos, já que o teste manual demanda muito tempo. Devido a isto, seria inviável realizar testes de regressão diariamente, antes que cada versão fosse lançada.
Alguns desafios também são enfrentados durante os testes automáticos, como por exemplo, testar funções que utilizam o GPS, testar o comportamento do aplicativo quando a bateria está com carga baixa, entre outros.

Vale ressaltar que há aplicações que são simples o suficiente para não necessitarem de testes automáticos. Pois, os testes manuais podem ser realizados em pouco tempo. Outro cenário importante a ser considerado é a realização de testes automáticos de forma parcial, apenas nas partes do aplicativo que demandem rotinas repetitivas e com alto custo para realização dos testes.
Fonte: Schladebeck, A., Tiede, M. Automated Acceptance Tests for Mobile Applications: Thoughts on Test Strategy. Artigo publicado na revista Testing Experience, Pág. 34-38, Edição nº 26, Alemanha, Junho 2014.

segunda-feira, 6 de fevereiro de 2012

Pontos importantes sobre testes de aplicativos para celular ou tablet (mobile)

Atualmente, está bem comum o uso de celulares ou tablets com muitos aplicativos (mini-computadores). Geralmente, quem desenvolve aplicativos para estes aparelhos querem que eles sejam um sucesso, mas para isso é necessário testar muito. Pois, caso a aplicação possua muitos bugs, ninguém vai querer baixar, já que a nota de avaliação irá lá para baixo.

Antes de pensar em testar estes aplicativos, é importante ter em mente as categorias de aplicações para celular, que são: Aplicações baseadas em navegador; aplicações pré-instaladas e Aplicações instaláveis.

Se a aplicação do celular for para ser acessada em um navegador, é necessário verificar se a página não foi criada com uma grande quantidade de dados, por exemplo, com imagens em alta resolução. Isto é importante pois se o usuário estiver usando a internet disponível no celular, geralmente ela é lenta e algumas vezes o custo da internet é de acordo com a transferência de dados. Além disso, os dados geralmente não são armazenados em cache, isso significa que a cada acesso o usuário terá que esperar novamente o carregamento da página, a não ser que o usuário configure isso no navegador. Ainda para aplicações para navegador, verificar se a página se adapta à tela do celular, que geralmente é pequena.

As aplicações de celular que já vêm instaladas, geralmente são aplicações de configuração do aparelho, elas não podem ser desinstaladas, nem removidas e também não precisam de atualizações. Estas aplicações precisam ser muito bem testadas pelo fabricante do aparelho, porque qualquer erro poder ser crítico para o funcionamento do celular.

No caso de uma aplicação que é instalada pelo usuário, às vezes elas requerem internet ou atualizações constantes para um bom funcionamento. Geralmente, estas aplicações estão disponíveis em uma loja de aplicativos (App Store or Market) ou podem ser transferidas via cabo USB diretamente de um computador. Elas podem também ser transferidas via Bluetooth, Infra-vermelho ou via Rede Wireless (usando outros aplicativos).

Alguns dos aparelhos possuem touch screen (o toque na tela) como entrada de dados, seja para passar a página de um livro ou para clicar em um link de uma página WEB. Há muitas dúvidas de como realizar testes para estes tipos de aplicativos com touch screen. Pode-se dizer que muitos dos testes realizados para sistemas WEB ou Desktop podem ser utilizados nestes aplicativos, por exemplo, validação de campos, ortografia, etc.

Entretanto, para aplicativos em celular ou tablet, algumas preocupações a mais são necessárias, como por exemplo o processamento, o consumo de bateria, a quantidade de armazenamento de dados, entre outros. O processamento é um item bem importante, já que muitos aparelhos de celular não possuem processadores velozes e ninguém vai querer usar um aplicativo que deixe o celular lento, não é?

sábado, 21 de janeiro de 2012

10 dicas para o sucesso do teste de software

1) Comece cedo e esteja preparado

O processo de teste deve iniciar o quanto antes com a revisão dos requisitos e dos documentos de design. Isso pode diminuir bastante o custo do projeto final, evitando bugs futuros. Além disso, preparar os roteiros de teste antes do software estar pronto pode economizar tempo valioso no final do projeto.

2) Escolha a técnica de teste que melhor atende às suas necessidades

O processo de teste deve se adaptar ao processo de desenvolvimento. A escolha do melhor processo vai depender de diferentes aspectos, como: tamanho do sistema, quantidade de desenvolvedores, o risco para o negócio, o tempo, etc.

3) Seja prático

Se não há uma equipe de teste na sua empresa para garantir a qualidade do software ou mesmo você percebe que o gerente de projeto acha que não será necessário testar o sistema por falta de tempo. Neste caso, pode ser melhor contratar uma equipe externa para realizar os testes e manter sua equipe focada apenas no desenvolvimento e correção de bugs.

4) Revise, revise e revise

Garanta logo no início do projeto que os documentos de requisitos estão corretos e sem ambiguidades. Esta garantia pode ser conseguida através da revisão dos documentos. Desta forma, provavelmente 65% dos defeitos na fase de desenvolvimento serão evitados. O revisor deve estar bem concentrado na tarefa e não deve ser interrompido, uma boa dica é fechar janelas de e-mail, bate-papo etc para não desviar a atenção. Usar algum método de revisão é bastante importante, como um simples checklist sobre o que deverá ser revisado.


5) Priorize

Às vezes não é possível testar tudo de um software quando ele possui muitas funcionalidades, então é importante criar alguma regra de prioridade para as funcionalidades a serem testadas. Análise de risco e a frequência do uso das funcionalidades é uma boa maneira de priorizar os requisitos.


6) Meça

Às vezes é importante saber qual o custo e quão eficiente é a equipe de teste ao encontrar defeitos no sistema? A chave para conseguir responder estas perguntas é começar a medir.
Métricas são informações que podem ser colhidas durante o desenvolvimento do projeto, como: número de cenários, número de defeitos encontrados, tempo gasto para executar um roteiro de teste, etc. Quanto antes for iniciada a medição dos dados melhor será a avaliação dos resultados.

7) Saiba quando deve parar de testar

Uma forma de saber quando deve parar de testar é quando o custo para encontrar um novo defeito é maior que o risco que aquele defeito no sistema pode causar para o usuário final.
Além disso, pode-se definir um critério de parada dos testes, por exemplo, quando 90% dos scripts de teste tiverem sido executados.
Se nenhum critério tiver sido definido, os testadores irão testar até não encontrar mais defeitos e todos os bugs tiverem sido resolvidos.

8) Preserve

Organize bem os roteiros de teste e guarde-os com cuidado, pois é bem provável que eles serão reutilizados na fase de manutenção e evolução do software. Isto poderá economizar cerca de 30% a 50% do esforço de realizar o teste de regressão.

9) Comunique

Assegure-se que a comunicação entre os membros das equipes de desenvolvimento e teste de software é clara e objetiva. Pois, caso contrário muitos erros podem ser causados por esta falta de comunicação. Utilize padrões de linguagem e ferramentas para difundir melhor as informações, por exemplo, uma ferramenta de gerenciamento de bugs.

10) Seja simples

Muitos gerentes de qualidade de software não sabem qual o melhor processo de teste e técnica deverá ser utilizada num projeto. Uma forma fácil de escolher é garantir a simplicidade do processo, sem burocracia. Além disso, o processo não poder ser cansativo para a equipe. Escolher a melhor abordagem é essencial para garantir a qualidade dos sistemas desenvolvidos.




Fonte: Revista Testing Experience. Test Techiniques in Practice. pág. 52-53, Germany, Setembro 2008.