Os 7 princípios do teste de software

No post – Os bons testes falham – falamos sobre um dos princípios de teste definidos no livro “Fundamentos de testes de software”. Hoje, compartilho com vocês dois vídeos, bem curtos, que resumem os 7 princípios definidos no livro. Os mesmos servem como referência, principalmente para aqueles que estão iniciando na área de testes.

O primeiro vídeo, exibido acima, aborda os 4 primeiros princípios, são eles:

1 – Teste demonstra a presença de defeitos.

Os testes reduzem a probabilidade que erros desconhecidos permaneçam no sistema, mas mesmo que nenhum defeito seja encontrado isso não é prova de conformidade.

2 – Teste exaustivo é impossível.

Mesmo com auxílio da automação, o número de combinações possíveis de cenários de teste numa aplicação é gigantesco, inviabilizando a possibilidade de se afirmar que TUDO foi testado.

3 – Testes devem iniciar o quanto antes e erros encontrados tarde custam mais para corrigir.

Iniciando o mais cedo possível no ciclo de vida do desenvolvimento do software, diminuímos o custo das correções e possibilitamos que erros de design, requisitos e arquitetura sejam encontrados no momento ideal. (Link para vídeo que aborda o assunto)

4 – Agrupamento de defeitos 

80% dos defeitos são causados por 20% do código. Ao identificar essas áreas sensíveis, os testes podem prioriza-las, enquanto ainda procuram por erros nas demais regiões.

O segundo vídeo, exemplifica os princípios anteriores e apresenta os 3 últimos pontos:

5 -Paradoxo do Pesticida

Caso os mesmos testes sejam aplicados repetidamente, em determinado momento eles deixam de ser úteis, ou seja, não conseguem encontrar nenhum novo defeito. Por isso, os testes precisam ser revisitados com frequência.

6 – Teste é dependente do contexto

Diferentes tipos de aplicações exigem a aplicação de técnicas diferentes de teste.
7 – A ilusão da ausência de defeitos

De nada adianta o sistema estar correto funcionalmente, porém não atender a real  necessidade do usuário.

O Cliente

Entre todos os princípios listados, acredito que os números 3 e 7 representam os principais aspectos da nossa atividade. A busca constante por antecipar cada vez mais as possíveis falhas da aplicação e assegurar que o sistema entregue atenda as reais necessidades do cliente, agregando valor ao seu negócio.

E vocês que aspectos consideram mais importantes nos testes de software?

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Perfis de Twitter sobre testes que merecem ser seguidos

No post de hoje indico alguns perfis relacionados a área de testes de software, os quais frequentemente indicam conteúdos interessantes para o nosso aprimoramento. Abaixo, seguem os perfis e suas bios.

 

Entre os brasileiros, os seguintes perfis se destacam na minha timeline:

@c_caetano – Author, Speaker, Consultant, Entrepreneur and Director@qualister ccristiano.caetano@gmail.com
@CamiloribeiroCellist, Senior QA Consultant at ThoughtWorks, Passionate Tester, a lover of good music, books and movies –http://www.bugbang.com.br
@eliasnogueiraSoftware Test Architect and ALM Tech Consultant at Hewlett Packard, almost a bass / guitar player and spending a little time at Rio.

Já entre os perfis internacionais, os quais recomendo estão:

@testingclub – An online community of professional software testers, by@rosiesherry & @rob_lambert / Community Managers@pkirkham @stephen_j_hill.
@uTest – uTest provides in-the-wild testing services that span the entire software development lifecycle: 50,000+ testers in 180 countries.
@SoftwareTestProServing the global software testing & quality assurance community, providing information, education & professional networking.
@michaelbolton – I solve testing problems that other people can’t solve, and I teach people how they can do it too.
@googletesting – Official place for Google Testing news and updates.
@testrepublicKnowledge Network for Software Testing Professionals.

E vocês? Que perfis indicam sobre o assunto?

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Entendendo os testes de performance

Todos já enfrentamos diferentes problemas de performance ao acessar nossos serviços favoritos na web. Lentidão e até mesmo indisponibilidade por longos períodos são problemas que ainda afetam a maioria das aplicações web.

Desse modo, podemos apontar que a Performance é um requisito não-funcional CHAVE para as aplicações web. E menosprezá-la pode causar grandes consequências.

Podemos definir os testes de performance, como:

Através dos testes de performance podemos simular o ambiente de produção, que a aplicação será submetida e avaliar como a mesma irá se comportar.

Lembrando que….

…de forma, que através da correta execução dos testes de performance, em conjunto com um monitoramento eficiente, podemos submeter diversos pontos da aplicação aos níveis de carga esperados e avaliar o seu comportamento.

No contexto das aplicações web: “Se um usuário tem de esperar muito (para acesso, processamento do lado do servidor, para formatação ou exibição do lado do cliente), ele ou ela pode decidir ir para outro lugar.” (Pressman, 2005)

Logo, desprezar esse requisito não-funcional pode gerar perdas irrecuperáveis para um negócio.

Do ponto de vista conceitual, fala-se sempre em três tipos de teste:

Performance: Avalia se a aplicação em teste atinge os requisitos em relação a questões como: tempo de resposta, throughput e utilização sob um nível de carga esperado.

Carga: Submete a aplicação a diferentes níveis de carga, com o objetivo de identificar a capacidade máxima de operação, além de gargalos, memory leaks, etc…

Stress: Avalia a robustez, disponibilidade e confiabilidade da aplicação em condições extremas (cargas muito elevadas, escassez de recursos)

Os três são comumente confundidos, porém como descrito cada um tem sem objetivo específico e a correta utilização dos mesmos durante o desenvolvimento poderá proporcionar um nível completo de informações sobre o comportamento da aplicação.

Por fim, é importante enfatizarmos que: “Caso não sejam executados da maneira correta, os resultados são, na melhor das hipóteses, inúteis e, na pior das hipóteses, enganosos, fazendo com que uma empresa menospreze ou superestime a capacidade de sua aplicação.” (Savoia, 2000)

Logo, é fundamental que, desde o início do ciclo de vida da aplicação, o RNF relacionado a performance seja priorizado, para que todo um ambiente de testes seja preparado de maneira adequada para simular o ambiente de produção e desse modo auxiliar o desenvolvimento a atingir o nível de qualidade desejado.

Gostou do assunto testes de performance? Participe, deixando seu comentário no post.

Em breve, voltaremos ao assunto falando do Apache JMeter.

E não esqueça de nos seguir no Twitter e juntar-se a nós no Facebook para ser informado das novas atualizações do blog!

BdB Recomenda – Data Generator

BdB Recomenda – É a mais nova seção do blog, que tem como objetivo apresentar sugestões de aplicativos, ferramentas, livros, jogos, cursos, palestras, eventos, etc. que possam contribuir com as suas tarefas diárias ou apenas com boas dicas para seu tempo livre.

Frequentemente encontramos nos projetos que participamos cenários em que precisamos simular grandes volumes de informações na base de dados.

Diversas são as alternativas para solucionar o problema: podemos realizar manualmente a operação desejada diversas vezes ou criar um arquivo de comandos SQL no editor de texto e executar o mesmo na base de dados ou ainda partirmos para a utilização de ferramentas que possam nos auxiliar na tarefa.

O Data Generator, trata-se de uma ferramenta web, que recomendo, devido a sua simplicidade e capacidade de resolver o nosso problema rapidamente, além de se tratar de um projeto open source. Através da mesma podemos gerar dados em diversos formatos: XLS, HTML, XML, CSV e principalmente SQL.

Data Generator Screenshot

De uma maneira extremamente simples podemos utilizar dados: variáveis ou fixos; pré-carregados na ferramenta ou customizados. A figura abaixo, exibe como para cada coluna de um tabela podemos facilmente definir diferentes tipos de dados de acordo com a natureza do campo.

Customizando Dados no Data Generator

O melhor de tudo é que você pode testar a ferramenta sem precisar instalar nada, pois na página do projeto existe uma versão disponível para testes.

Caso você se interesse em continuar usando a aplicação, recomendamos a instalação na sua própria máquina, pois a versão demo possui a limitação de gerar no máximo 200 registros. Mas, não se preocupe, a instalação é extremamente simples, possui apenas 5 passos. E caso ainda tenha dificuldades, encontrei no youtube um vídeo do processo de instalação feito pelo Elias Nogueira do blog SemBugs.

Para mais detalhes na utilização da ferramenta, existe ainda um artigo, que publiquei na revista Testing Experience, com informações mais detalhadas sobre a utilização do Data Generator.

E vocês recomendam outras ferramentas para popular base de dados?

Como Automatizar Testes de aplicações Android – Parte 4 (Final)

Olá pessoal, estou de volta pra mais post da série. No último post falamos como implementar um teste automático para verificar a nossa aplicação calculadora fajuta usando as classes que a API do android nos fornece que é principalmente a a classe  ActivityInstrumentationTestCase2 . E agora vamos dar um exemplo do mesmo teste automático utilizando o robotium e vamos ver a diferença e o quão prático fica implementar um teste utilizando este framework de teste, principalmente quando usamos uma aplicação com mais de uma activity ou quando não temos acesso ao código fonte da mesma.

Primeiramente vamos baixar o arquivo .jar no site do robotium neste link. A versão que estou usando é a mais recente robotium-solo-3.1.jar. Vamos criar o projeto de teste da mesma forma que criamos o projeto de teste do post anterior.  Depois clicamos com o botão direito em cima do projeto e vamos na propriedade do mesmo. Na nova janela selecionamos Java Build Path e na aba Libraries adicionamos o jar que acabamos de baixar no projeto através do botão Add External JARs…

Depois apenas criamos a classe de teste da mesma forma que criamos no projeto anterior, ou seja, fazendo com que esta classe estenda de ActivityInstrumentationTestCase2 e no seu construtor também chamamos o super passando por parâmetro o pacote e a class da activity principal do projeto que vamos testar, no nosso caso “br.cesar.edu” e CalculatorActivity.class. A mudança em relação a projeto anterior começa a partir de agora. Primeiro criamos um atributo da classe do tipo Solo que é um classe que o framework Robotium nos prover e com esta classe nós praticamente resolvemos tudo no nossos testes. Depois vamos para os metodos setUp() e tearDown(), no qual respectivamente  inicializamos e finalizamos este atributo para garantir que o teste vai ser rodado corretamente. E o código fica assim:

public class TestMain extends ActivityInstrumentationTestCase2<CalculatorActivity>{

private Solo solo;

public TestMain() {
super(“br.edu.cesar”, CalculatorActivity.class);
}

protected void setUp() throws Exception {
super.setUp();
solo = new Solo(getInstrumentation(), getActivity());
}

protected void tearDown() throws Exception {
try {
solo.finalize();
} catch (Throwable e) {
e.printStackTrace();
}
getActivity().finish();
super.tearDown();
}

Pronto, a partir deste momente estamos praticamente com 90% do projeto de teste finalizado. Agora vamos apenas para a implementação do teste em si. Se observarem o código do projeto de teste anterior já podemos perceber o quanto de código deixamos de escrever no método setUp(). Antes tínhamos que pegar a instâncias de todos os views que iríamos interagir no teste, além de ter que criar um Monitor para monitorar a próxima tela que iria exibir o resultado da operação. No caso do projeto usando o robotium, não precisamos nos preocupar com isso, apenas deixamos que a classe Solo se encarrega de pegar as instâncias dos view e interagir com eles.

Vamos reproduzir os mesmo dois testes que criamos no projeto anterior da mesma forma que é criando os métodos começando com a string test na frente do nome do mesmo. No primeiro teste vamos passar os valores 2 e 8 e esperemos que o resultado da soma seja 10 e no segundo teste vamos passar o valores 2 e 81 e vamos esperar que o valor da soma seja um erro “Número Inválido”. O código dos teste vai simples assim :

public void testSomar001(){
solo.enterText(0, “2”);
solo.enterText(1, “8”);
solo.clickOnButton(“Somar”);
assertTrue(solo.searchText(“10”));
solo.goBack();
}

public void testSomar002(){
solo.enterText(0, “2”);
solo.enterText(1, “81”);
solo.clickOnButton(“Somar”);
assertTrue(solo.searchText(“Número Inválido”));
solo.goBack();
}

Apenas pegamos a intância de solo e usamos o métodos triviais como enterText no qual passamos o index do componente, no nosso caso para o primeiro editText é o valor 0 e o segundo editText o valor do indice é 1, e no segundo parâmetro  e passamos o texto em si , no nosso projeto seria os números a serem somados. Não podemos esquecer que nesta aplicação o resultado aparece numa nova tela e para que o teste seja finalizado precisamos voltar para a tela inicial para que o próximo teste seja executado a partir daquela tela inicial e por isso chamamos o método goBack().

Bem pessoal, basicamente é isso que temos que ver em relação a automação de testes para aplicações Android  e aqui neste link vocês podem baixar o código do nosso projeto de teste utilizando o robotium. Não adicionarei o vídeo de dos testes rodando pois visualmente o teste roda da mesma forma como o projeto de teste anterior roda, apenas o código é mais simples.

Ahh, antes que eu me esqueca, se você tiverem apenas o arquivo .apk de alguma aplicação Android, lembre-se que com o robotium também é possível testa-lo, pois como podem perceber não precisamos ter conhecimento detalhado do código da aplicação que vamos testar, apenas precisamos saber quais as view que esta aplicação tem em cada tela e ter uma noção prévia da navegação das telas dessa aplicação. Para ser sincero ainda não fiz nenhum teste utilizando apenas o apk de uma aplicação. Por isso não vou detalhar como se faz aqui. Apenas posso passar o link do tutorial e prometer que no futuro volto a postar algo relacionado a este processo. Abraços e até a próxima.

Como Automatizar Testes de aplicações Android – Parte 3

Estamos de volta em mais um post da série de como automatizar testes para aplicações em Android. E agora vamos para a parte que mais interessa à todos que é como automatizar testes para aplicações Android.

No eclipse vamos em File-> New -> Other e dentro da tela de New, selecionamos a opção Android Test Project e clicamos em Next (Passo 1 da imagem). Colocamos um nome no projeto de teste, por recomendação o nome do testes geralmente é o nome do projeto a ser testado concatenado com a palavra “Test”, no nosso caso o projeto a ser testado se chama Calculadora então o nome do projeto de teste será CalculadoraTest (Passo 2 da imagem) , colocando o nome do projeto então clicamos em Next. O nosso terceiro passo para criação do projeto de teste é selecionar o projeto que será testado, no nosso caso será Calculadora (Passo 3 da imagem) e clicamos em Finish. No final o eclipse criou um projeto de teste com boa parte já configurada como podemos observar no ultimo passo da imagem abaixo, onde percebemos que o projeto de teste foi criado com o pacote quase igual ao projeto que vai ser testado, exceto pela adição de um novo pacote chamado test.

 

Clique na imagem para ampliar

Em um projeto de teste para android podemos definir diversos objetivos e criar diversas classes de teste, no post atual a classe que estamos criando tem o objetivo de testar as funcionalidades básicas da calculadora utilizando a interface da mesma. Para isso criamos uma classe de teste que estende de ActivityInstrumentationTestCase2 ficando assim:

package br.edu.cesar.test;
import android.test.ActivityInstrumentationTestCase2;
import br.edu.cesar.CalculatorActivity;
public class CalculatorActivityTest extends ActivityInstrumentationTestCase2<CalculatorActivity> {

public CalculatorActivityTest() {
super(“br.edu.cesar”, CalculatorActivity.class);
}

}

Depois de criarmos a classe de teste, precisamos implementar o construtor desta classe que deve fica como no código acima. A classe de teste deve dizer para o framework de teste do android qual aplicação deve ser testada, passando por parâmetro do super construtor o pacote e o .class da activity a ser testada. Logo após a criação do construtor podemos passar pra alguns métodos “genéricos” que podem ajudar nos testes em si. São eles: setUp() – Este método herda do método setUp() do JUnit, portanto tem a mesma característica de ser usado para preparar o ambiente antes de cada teste ser executado. tearDown – Este método também herda do JUnit e também tem a mesma característica de ser usado para finalizar o ambiente corretamente quando necessário após cada teste executado. Utilizando o método setUp(), primeiramente pegamos a instancia da activity que vai ser testada e inicializamos alguns views da mesma para interegir a aplicação calculadora.  Outra coisa importante que precisamos fazer no teste para que o mesmo possa utilizar aplicação para interagir é desabilitar o modo touch da activity, fazendo isso temos o seguinte código para o método setUp():

@Override protected void setUp() throws Exception {
super.setUp();
setActivityInitialTouchMode(false);
mActivity = getActivity();
mMonitor = mIntrumentation.addMonitor(ResultActivity.class.getName(), null, false);
e1 = (EditText) mActivity.findViewById(br.edu.cesar.R.id.editText1);
e2 = (EditText) mActivity.findViewById(br.edu.cesar.R.id.editText2);
bSomar = (Button) mActivity.findViewById(br.edu.cesar.R.id.btnSomar);
bSubtrair = (Button) mActivity.findViewById(br.edu.cesar.R.id.btnSubtrair);
bMultiplicar = (Button) mActivity.findViewById(br.edu.cesar.R.id.btnMultiplicar);
bDividir = (Button) mActivity.findViewById(br.edu.cesar.R.id.btnDividir);

}

É importante lembrar que no inicio da classe estou declarando todos os objetos que estamos utilizando nos códigos dos métodos, como por exemplo mActivity que é um objeto do tipo activity e a mesma esta declarada no inicio da classe como voces podem ver no código do projeto de teste que esta disponivel neste link.

Para entender melhor de onde estou pegando os editText e os botões, deem uma olhada no código do projeto Calculadora, no qual disponibilizei no post anterior.  Após criar a classe e implementar o metódo setUp() podemos partir para a implementação do teste em si. Para criar um teste que interaja com a aplicação e analise o resultado esperado, basta criar um método que comece com a palavra “test” no inicio do nome do teste que o framework de teste do android reconhece o mesmo como teste para ser executado. No nosso exemplos demos o nome de testCalculadoraSoma001.  Neste teste vamos pegar as instâncias das views carregadas no método setUp() e vamos interagir com a mesma, mas para tal, precisamos criar uma thread especifica de UI para que essa interação ocorra. Pegamos a instancia da activity que temos e chamamos o método runOnUiThread() e dentro do run da nova runnable, a gente interage com as views, como por exemplo pegamos os editText da aplicação e populamos com os valores desejados e depois colocamos o foco no botão somar. O código do teste fica assim:

public void testCalculatorSoma001() {
mActivity.runOnUiThread(new Runnable() {

@Override
public void run() {
e1.setText(“2”);
e2.setText(“8”);
bSomar.requestFocus();
}

});
this.sendKeys(KeyEvent.KEYCODE_DPAD_CENTER);
oActivity = mIntrumentation.waitForMonitor(mMonitor);
assertNotNull(oActivity);
result = (TextView) oActivity.findViewById(br.edu.cesar.R.id.textview_result2);
assertEquals(“10”, result.getText());
this.sendKeys(KeyEvent.KEYCODE_BACK);
}

Após interagirmos com as view apenas enviamos o evento de pressionamento do center key do teclado com com método sendKey, e como o resultado da operação vem numa nova activity, temos que pegar a instancia da nova activity que vai ser exibida  com o método waitForMonitor() passando por parâmetro uma classe que fica monitorando o sistema aguardando que a nova activity que definimos para que o mesmo monitore la no método setUp. Após conseguirmos pegar a instancia da nova activity que vai mostrar o resultado,  pegamos o valor que está no TextView result  e verificamos se o valor é o mesmo do esperado com o método assertEquals que tem a mesma características dos asserts do JUnit. Por fim apenas precisamos executar o projeto, e para isto basta clicarmos com o botao direito em cima da classe de teste, no nosso caso CalculadoraActivityTest e selecionar a opção Run as-> Android JUnit Test. A execução do teste você pode conferir no video abaixo.

No vídeo acima podemos ver que temos dois testes, o primeiro esta relacionado ao código que coloquei acima testCalculatorSoma001() no qual passamos o valores 2 e 8 para os editTexts e esperamos que o resultado seja igual a 10. O segundo teste vamos deixar por sua conta para praticarem. O valores passados para os editText são 2 e 81 respectivamente e o resultado esperado é uma mensagem de erro que esta dentro do arquivo string.xml (dentro de res/values) do projeto da calculadora que passamos o código no post anterior. A mensagem de erro é  a string “Número Inválido”.

Por enquanto é isso pessoal, após utilizar este framework que o android prover eu tirei algumas conclusões, principalmente em algumas situações como por exemplo que dei na qual  a aplicação a ser testada possui mais de uma activity e as mesma utilizam intents entre si e  quando queremos testar aplicações dos quais não temos acesso ao código mas apenas ao .apk . Nesses casos implementar teste utilizando apenas o framework de teste do google se torna muito trabalhoso e complicado. No próximo post eu vou mostrar um exemplo da diferença de um teste implementado da forma que é recomendado pelo google e implementado utilizando uma biblioteca chamada robotium.

Como Automatizar Testes de aplicações Android – Parte 2

Olá pessoal.  Estou de volta para dar continuidade a meu último post sobre automação de testes para aplicações Android e neste post vou detalhar como implementei a nossa calculadora fajuta do Bdb para que possamos entender os conceitos básicos de Android e depois conseguirmos automatizar o testes para esta plataforma.

Primeiramente, como falei no post anterior temos que alinhar o ambiente de desenvolvimento que estamos usando. No meu caso eu uso o Eclipse Classic 3.6.2  instalei o plugin ADT. Para mais detalhes de como configurar seu ambiente, veja aqui.

Como todo começo de projeto, vamos no menu principal do eclipse: File->New->Other… e la na janela wizard temos a opção Android Project que nos leva a seguinte tela que devemos colocar o nome do projeto (Calculadora). Depois de colocar o nome do projeto e clicarmos em Next, vamos para a tela que devemos selecionar o Build Target. Como todos devem saber o Android já evoluiu bastante desde do seu surgimento no mercado  com a versão 1.5 mais conhecida como Cupcake até o mais recente e famosa versão 4.o ou Ice Cream Sandwich que promete integrar todo o ecosistema entre smartphones e tablets, mas isso não vem ao caso aqui. No caso da nossa calculadora, ela foi implementada para a versão 2.3.1 (API Level 9)  e é o que eu recomendo para que todos usem no momento para que possamos ter um alinhamento das atividades aqui no post.

Depois que escolhermos o Build Target, vamos para a seguinte tela na qual definimos o nome do pacote no qual nossa activity principal ficará disponível  e também já vamos ter uma sugestão do nome da activity principal que é o nome do projeto + a palavra Activity no final. Nesta última tela você verá também a opção de criar um projeto de teste para este projeto que você esta criando no momento, mas vamos deixar esta opção desmarcada e no próximo post vou mostrar como criamos um projeto de teste para esta aplicação.

Assim que o  nome do projeto, o Build Target, nome do pacote e o nome da activity principal são definidos, o projeto Calculadora vai ser criado com a seguinte estrutura:

Nosso primeiro passo vai ser no arquivo main.xml dentro de res/layout que é o arquivo responsável pela interface visual da activity que vamos implementar. No Android a estrutura da aplicação é dividida em algumas camadas e a camada de interface com o usuário é mais comumente definida no xml. O primeiro passo é selecionar o layout que vamos trabalhar na nossa aplicação, no nosso projeto a layout definido não vai fazer muita diferença, portando fica de livre escolha de vocês qual usar, no nosso código, definimos o relative layout. Para mais detalhe de cada layout suportando no Android, leiam aqui. No nosso projeto de calculadora vamos trabalhar com duas activities e dois xml de layout o primeiro xml (main.xml) temos um TextView (Nome da aplicação),  dois editText (Campos para usuario digitar os operandos) e 4 buttons (um botão para cada operador básico). O segundo xml (result.xml) de layout temos apenas um textView que é para exibir o resultado da operação selecionada pelo usuário na tela anterior.Obviamente poderíamos exibir o resultado na mesma tela mas fizemos dessa forma com um próposito que veremos no próximo post quando formos falar das 2 maneiras de automatizar os testes dessa calculadora.

Para ver como ficou os arquivos xml  e também os arquivos .java que vou explicar nos parágrafos seguintes, baixe o código da nossa aplicação neste link .

Depois de definido o layout vamos para a implementação em si. Primeiramente, vamos ao básico e criamos uma classe chamada Operators.java com todos os métodos de cada operação básica da nossa calculadora, esta classe será instanciada pela activity principal e seus métodos serão chamados de acordo com os eventos que a nossa activity principal tratar.

Na primeira activity, que é a nossa activity principal (CalculadoraActivity.java) definimos qual layout vamos usar (main.xml) e definimos também alguns atributos que vamos utilizar para pegar as instancias dos Views (componentes visuais, Ex: Buttons) que definimos no main.xml e no qual vamos tratar os eventos que serão gerados pelos usuários ao interagir com estes views,  como por exemplo o clique no botão (OnClick). A nossa segunda activity (ResultActivity.java) é a tela que simplesmente pega o resultado “empacotado” pela primeira activity e exibe no textview que esta definida pelo layout result.xml.

Um último detalhe e não menos importante é o arquivo strings.xml que fica dentro da pasta res/values. Nesse arquivo definimos algumas “variáveis” no qual podemos ter acesso de várias parte do cógido, como nos arquivos de layout, no código das activities, etc…
No nosso caso definimos o o valores para todos os views utilizados pela aplicação, como por exemplo o nome na aplicação que é definido no arquivo mais.xml para o TextView esta setado no arquivo strings.xml como app_name e seu respectivo valor é Calculadora.

Após todo esse trabalho a nossa calculadora fajuta do Bdb vai ficar com essa cara como na imagem aqui abaixo:

Bem, por enquanto já temos o suficiente para nos divertimos um pouco durante a semana e no nosso próximo post eu vou finalmente revelar como podemos fazer alguns testes automáticos para esta nossa calculadora fajuta. Aproveitem o restante da semana para por em prática os conceitos básicos  passados aqui e brinquem de alterar o código para entender um pouco mais como a coisa toda funciona. Uma ótima semana para todos e até o próximo post.

Como Automatizar Testes de aplicações Android – Parte 1 (O desafio)

Olá pessoal,  este ano vou começar com uma pequena série de posts e um pouco DIFERENTE dos posts habituais para falar mais uma vez de teste na prática. Obviamente para ser diferente eu vou deixar este primeiro post um desafio para todos assim como eu tive um desafio no final do ano passado para  preparar e ministrar uma disciplina de teste de software para uma turma de desenvolvedores que estava participando de um curso de desenvolvimento para Android. Preocupado em deixar as aulas de teste mais interessantes,  eu arrisquei adaptar meu material para algo que fosse bastante prático e relevante para essa turma e por isso dei uma estudada no Android e como desenvolver aplicações e criar testes automáticos para o mesmo e acabei descobrindo algumas coisas que o SDK disponibiliza que gostaria de compartilhar com vocês.

Antes de começarmos a desenvolver testes para o Android, preciso passar  algumas informações relevantes para que todos possam conseguir ter um entendimento completo de como automatizar alguns testes para aplicações em Android e também consigam completar o desafio que deixarei neste post.

Para podermos automatizar testes para aplicações Android, precisamos entender alguns de seus componentes básicos, que são: Activities, Services, Content Providers e Broadcast Receivers.

Activities – Uma activity é um dos componentes do Android mais usados nas aplicações pois ele é que  fornece uma tela com a qual os usuários podem interagir. Por exemplo dicar um número de telefone, escrever uma sms, ou visualizar um mapa. Para cada activity é dada uma “janela” na qual “desenhamos” uma  interface de usuário. As “janelas” normalmente preenche toda a tela, mas também podem ser menores do que a tela e flutuar em cima de outras “janelas”.

Services – São componentes de aplicação que podem executar operações de longa duração em segundo plano, portanto não fornecem uma interface de usuário. Um serviço pode ser iniciado por uma aplicação e ele continuará a ser executado em segundo plano, mesmo se o usuário trocar para outra aplicação.

Content Providers – Como o nome já explica, Content Providers é componente responsável por armazenar e recuperar os dados e torna-los acessível para todas as aplicações, ou seja são os provedores de conteúdo. A única forma de compartilhar dados entre aplicações no Android é através de content providers, pois não existe área de armazenamento comum que todos os pacotes Android podem acessar.

Broadcast Receivers – É um componente que responde a anúncios de todo o sistema de broadcast. Muitos brodcast provenientes do sistema, como um broadcast anunciando que a bateria está fraca ou uma sms foi recebida. As aplicações também podem iniciar os broadcast, por exemplo, para permitir que outras aplicações saibam que alguns dados foram disponibilizados para eles usarem. Os broadcast receivers também não possuem interface de usuário, mas eles podem criar uma notificação de barra de status para alertar o usuário quando um evento de broadcast ocorreu.

Bem , depois desta uma breve introdução, vamos por a mão na massa e desenvolver uma calculadora bem simples para que depois possamos automatizar alguns testes para essa aplicação. Quem quiser se aprofundar um pouco mais sobre como desenvolver aplicações para Android pode dar uma olhada neste site para desenvolvedor da Google.
Essa calculadora que desenvolvi possui algumas restrições para cada uma das operações básicas (somar, subtrair, multiplicar e dividir) com o objetivo de exemplificar o uso de algumas técnicas de criação de teste para os alunos da turma e essas técnicas de criação de testes não vem ao caso neste post nem nos seguintes que virão, o nosso objetivo aqui é explicar como desenvolver e automatizar testes para aplicações Android. Outro fator relevante que devo deixar claro é que eu utilizei o eclipse com o plugin ADT para desenvolver meu projeto em Android. Para saber como configurar seu ambiente, veja aqui.
Após configurar o ambiente vamos ao nosso desafio:
Vou deixar alguns requisitos básicos da nossa calculadora para que você possam tentar desenvolver e no próximos post  disponibilizarei o nosso código e explicarei passo a passo como o desenvolvi.  Logo abaixo segue os requisitos da aplicação que vamos automatizar os testes mais na frente:

Nome: Aplicativo Calculadora Fajuta 

[REQ001] Tela principal deve possuir dois campos (EditTexts) para inserir valores e um botão (Button) de cada  funcionalidade da calculadora, que são:
– SOMAR
– SUBTRAIR
– MULTIPLICAR
– DIVIDIR

[REQ002] A operação SOMAR  só efetua soma de números entre 0 e 10, pois a calculadora é fajuta. O resultado deve ser mostrado em um texto (TextView) no canto inferior da tela.

[REQ003] A operação SUBTRAIR é um pouco mais evoluída e consegue efetuar a subtração de números entre 0 e 50. O resultado deve ser mostrado em um texto no canto inferior da tela e caso seja um resultado negativo, o mesmo deve estar na cor vermelha.

[REQ004]  A operação MULTIPLICAR  deve multiplicar  apenas números pares.

[REQ005] A operação DIVIDIR, da mesma forma da operação Somar, só efetua a divisão de números entre 0 e 10.

E claro que qualquer dúvida por mais simples que seja, podem comentar aqui neste post e terei o prazer de responder o mais rápido possível. Para os mais tímidos, podem me mandar um email que tem no meu perfil aqui do Bdb.  Boa sorte a todos !!! 🙂

Teste está morto parte 2

Como havia prometido, volto hoje ao tema abordado na semana passada. Tentarei destacar os principais pontos abordados no vídeo recomendado na parte 1. E antes de tudo, obrigado a todos pela participação no blog, na DFTestes e no Linkedin. A colaboração de vocês é fundamental para o enriquecimento da discussão.

A primeira grande contribuição do vídeo trata-se da abordagem inicial a evolução das metodologias de desenvolvimento e consequentemente as diferentes formas de atuação dos testadores. O palestrante, Alberto Savoia, a divide em dois grandes momentos: Old Testmentality e New Testmentality. Partindo da dependência completa dos documentos de requisitos, aos ciclos mais curtos das metodologias ágeis associados a uma maior integração entre desenvolvedores e testadores.

Durante a chamada Old Testmentality, as aplicações só eram entregues quando estivessem completamente “prontas”. Enquanto, que na New Testmentality, as entregas passaram a ser frequentes, exigindo uma participação constante do cliente na construção do “produto correto”.

Em seguida, Savoia começa a destacar os pontos que o levam a pensar que o teste tradicional está morto. Começando pelo o que ele chama de Post-Agile, a qual tem como diferencial o fato de apresentar uma postura mais casual e descuidada em relação aos testes ágeis tradicionais.

Segundo Savoia, a questão central cada vez mais é a construção do “produto correto” e não o simples desenvolvimento correto do produto ou das funcionalidades, ou seja, o objetivo é entregar um produto, que em primeiro lugar, atenda às necessidades dos usuários. Não basta ser apenas perfeito funcionalmente.

O palestrante nos lembra que de fato existem diversas aplicações fabulosas construídas utilizando os conceitos tradicionais, mas que a estrutura existente nos dias atuais, como a computação nas nuvens, permitem diminuir o foco da qualidade de software e transferi-lo para garantir que estamos construindo o produto CORRETO.

Um grande exemplo citado é o twitter, que tornou famosa sua baleia com a enormidade de vezes que deixava os usuários na mão, mas mesmo assim eles continuavam voltando, pois o produto era o desejado.

Nesse novo cenário, que se desenha, segundo Savoia, precisamos nos voltar para outro tipo de bug, o chamado idea bug, que podemos traduzir como bugs de conceito ou de idéia do produto.

Um produto errado é muito pior do que um produto com o comportamento errado.

A chave é testar a idéia, ou seja, garantir que estamos desenvolvendo o produto certo.

E como podemos testar a idéia?

A sugestão de Savoia é começarmos utilizando protótipos iniciais (pretotype), os quais ele diferencia dos protótipos tradicionais, por serem desenvolvidos e aplicados em curtos espaços de tempo. É fundamental testar cedo e falhar rápido, segundo o mesmo Bons testes falham rápido, diminuindo o tempo e o capital investido. (BdB – Os bons testes falham)

Alberto cita ainda alguns dos sinais observados, que o levam a crer no fim dos testes tradicionais.

Sinais do Testpocalypse:

– Diminuição no numero de contratações
– Comoditização dos testadores
– Saída dos antigos líderes e ausência de novos
– Mais e mais empresas partindo para o Post-Agile

Acompanhado essa corrente de mudanças existem enormes oportunidades. Savoia enfatiza a crescente necessidade do surgimento de novos líderes na área de testes, com uma mentalidade diferente, e que possam conduzir essa etapa de transição. Onde, como o mesmo aponta, ainda conviveremos por um longo tempo com as diversas formas de teste. (BdB – Imagine um mundo sem Bugs no Software)

Por fim, um dos slides afirma “Test is dead. Don’t take it literally, but take it seriously.”, traduzindo, “Teste está morto. Não leve isso literalmente, mas leve a sério.”. Logo, a palestra é uma alerta e não uma simples afirmação arrogante, que se julga acima de todos nós. Uma apresentação, que vale a pena ser vista com atenção, e que nos deve levar a refletir sobre os caminhos, que estamos seguindo, as oportunidades de aprendizado e de mudança que podemos levar a nossa área. Sejamos o agente dessas mudanças.

P.S. Todas as imagens utilizadas estão nos slides da apresentação, disponível aqui.

Teste está morto parte 1

Não restam dúvidas de que automação de testes é uma atividade fundamental no desenvolvimento de sistemas. Desde os testes unitários até os de aceitação precisamos cada vez mais de uma estrutura que permita a entrega de aplicações de maior qualidade num menor espaço de tempo.

Na internet existem diversos materiais e vídeos, que podem nos ajudar a progredir nesse caminho. A indicação de hoje são os vídeos do Google Testing Automation Conference, conferência do google, que reúne os mais respeitados profissionais. Na página da conferência você encontra os vídeos e os slides das palestras realizadas. Buscando um pouco mais você pode encontrar também os vídeos das edições anteriores.

GTAC 2011 - Logo

A palestra de abertura da edição de 2011, apresentada por Alberto Savoia, têm como título Test is Dead (Teste está morto), ficou curioso? De forma brilhante, o mesmo passeia pelas metodologias de desenvolvimento de software, finalizando com os motivos que o levam a crer que o teste está morto.

São 35 minutos de palestra, somados a 15 minutos de perguntas. Logo, caso não possa parar agora, guarde o link e assista numa melhor oportunidade, vale bastante a pena.

Quer saber mais sobre como o pessoal testa as aplicações no google? Acesse o blog mantido por eles.

Outros vídeos interessantes do pessoal do google podem ser encontrados na página do youtube – Google Tech Talks.

Na próxima semana, publico a parte dois do post, onde comentarei sobre alguns dos pontos discutidos na palestra acima.