QA

“App did not start” com Calabash-android

por elessandraestevao

Ao iniciar um projeto com Calabash-android para criar testes automatizados com utilização do Cucumber, me deparei com o erro “App did not start” quando tentava executar o Calabash-android.

Como havia atualizado algumas Gems, pensei que fosse algo decorrente dessas atualizações e comecei a buscar a causa desse erro. Depois de constatar que não estava relacionado às minhas atualizações, descobri que o erro decorria do uso de permissões no app que estava testando. Faltava a permissão de acesso à Internet no app (:-) Após adicionar a permissão no arquivo AndroidManifest.xml, problema resolvido!

Mas por que isso aconteceu?

Porque o Calabash-android, para interagir com a aplicação que está sendo testada, utiliza o protocolo HTTP entre o seu servidor (que é instalado no device ou simulador onde serão executados os testes) e a aplicação em teste. Assim, sem essa permissão habilitada, não era possível estabelecer uma conexão entre o servidor do Calabash e a aplicação. O seguinte erro foi mostrado no log da aplicação quando da tentativa do Calabash de estabelecer comunicação com a mesma:

Este log diz que não foi possível abrir um socket para conexão entre a aplicação e o servidor de testes requisitada pelo Calabash devido à permissão negada.

Após adicionar a permissão, gerei um novo apk e foi possível estabelecer a conexão com a aplicação e dar start nela. No log da aplicação no Android Studio vi o seguinte:

Ou seja \o/

Publicidade

Como foi a Trilha Testes no TDC 2016

por elessandraestevao

No TDC SP, a Trilha de Teste é destinada aos profissionais ligados à qualidade e testes de software nas empresas, estudantes e entusiastas da área. A coordenação da trilha foi feita pelo Elias Nogueira, que é QA Engineer, Agile Coach & Trainer na Adaptworks e Professor de Pós Graduação na Unisinos/RS, e pela Tatiane Fukuda, QA Lead na TFG Co, com experiência de mais de dez anos em Qualidade e Testes de Software.

Considerando que comecei a trabalhar nessa área há cerca de seis meses, essa foi a primeira vez que participei da Trilha Testes. Então, a intenção deste post é deixar as minhas impressões como iniciante. Vamos lá?

No total, foram 14 palestras ao longo do dia. A primeira foi “Eu não garanto a qualidade” ministrada por Diego Blond, Analista de qualidade na Vizir Software Studio. Diego mostrou seu ponto de vista sobre o que pode contribuir para a garantia da qualidade num projeto e o que não contribui para tal. Segundo ele, abrir bug, relatórios, discussões, planos de teste, hora extra, equipe maior ou menor, focar na qualidade, entrega com ou sem pressa e teste automatizado, de forma isolada, não garantem a qualidade. Diego acredita que o que realmente garante é A EQUIPE! Como?

  • Sendo uma equipe informada sobre as regras de negócio, fazendo questionamentos, conhecendo bem o cliente, o usuário final e o projeto;
  • sabendo se comunicar com o cliente, propondo melhorias, apresentando argumentos;
  • saindo da zona de conforto, sempre estudar, se aprimorar, não regredir em suas habilidades e conhecimento;
  • sendo uma equipe unida, todos buscarem a qualidade;
  • utilizando o bom senso para todos os itens que, isoladamente, não garantem a qualidade (citados acima), mas que, utilizados em conjunto, pela equipe, funcionam.

Se você quiser ver os slides que ele apresentou, eles estão aqui.

A segunda palestra “Testes exploratórios não são sinônimo de bagunça” foi ministrada pelo Igor Abade V. Leite, um dos sócios da Lambda3 e Microsoft MVP (Most Valuable Professional) de Visual Studio ALM. Igor mostrou na prática como utilizar o plugin XTInstall para o Chrome, que permite fazer a abertura de bugs, criar uma nota a respeito de um bug encontrado, prints da tela durante a navegação na página web, criação de um caso de teste, geração de relatórios HTML, dentre outras características. O plugin é desenvolvido pela Microsoft e pode ser encontrado aqui. . Tem a versão Stand alone (gratuita) e a versão de modo conectado ligado ao TFS. Se você quiser saber mais sobre esse tema, os slides do Igor estão aqui.
A terceira palestra, “10 coisas que não me contaram sobre testes”, foi ministrada pela Katiana Maia, Analista de Testes e Qualidade na Alcis — Softwares para Logística. Segundo ela, o que ela não sabia sobre testes é que o detalhismo é bom; que o profissional de testes precisa atuar muitas vezes como psicólogo e saber “se virar” com programação; que nem todos fazem teste, e por isso é importante falar sobre a importância da prática; que a automatização dos testes é imprescindível e possível para um testador, basta ter paciência e persistência; que no processo tradicional de desenvolvimento de software ou no ágil, o essencial para o sucesso é a comunicação; que tempo é definitivo (infelizmente, uma versão pode ser entregue com ou sem testes, e quando os prazos são apertados a primeira opção de corte é o teste); e, por fim, o mundo dos testes é maior do que pensamos: tudo deveria ter testes! Se você quiser saber mais, pode ver os slides da palestrante aqui.

Depois foi a vez de Jônatas Davi Paganini — full stack engineer na Resultados Digitais, que falou sobre como sua equipe conseguiu diminuir o tempo do build de 12 mil testes de 25 min para 13 min na palestra “Otimizando tempo de build: performance da suíte de testes”. Ele enfatizou o uso da factory Girl, uma biblioteca para a criação de objetos Ruby como dados de teste. Veja os slides dele aqui.

Em seguida, Luiz Augusto dos Santos Lohn, Mobile QA Engineer na Socialbase, falou sobre “Automação de Testes Mobile com Appium“, por meio deste exemplo prático.

Appium é uma ferramenta para a automação de testes no contexto mobile que suporta diferentes tipos de linguagens de programação, atende as plataformas Android e iOS nativas e aplicações híbridas. Os slides da palestra estão aqui.

A palestra “4 dicas valiosas para uma pirâmide de testes saudável” foi ministrada por Taíse Dias da Silva e Ricardo Cavalcanti, ambos da ThoughtWorks. Eles falaram sobre o que é a pirâmide de testes de acordo com as visões de Mike Cohn (livro Succeding with Agile), Sam Newman (livro: Building Microservices) e Lisa Crispin e Janet Gregory (Livro: Agile Testing).

De acordo com o que foi explicado por eles, a maior quantidade de testes em um projeto deve ser na base da pirâmide, os testes unitários, os quais são executados em pouco tempo e podem ter uma bateria ampla sem comprometer o tempo de build do projeto. No meio da pirâmide estão os testes de serviço (API, aceitação) e no topo da pirâmide estão os testes de interface, os quais devem ser em menor quantidade, abrangendo o fluxo funcional da aplicação como um todo, porque são testes mais demorados. Entretanto, eles ressaltaram que os diferentes tipos de testes são complementares, não excludentes entre si.

Por fim, eles sugeriram separar testes unitários dos testes de aceitação para ter feedbacks mais rápidos e não adiar a implementação da jornada do usuário, ou seja, o teste de fluxo da aplicação a partir da UI (evitando o acúmulo de dívidas técnicas).

Claudenir Freitas, desenvolvedor de sistemas na Sensedia, falou sobre “Testes em APIs REST”. O objetivo da utilização de APIs é prover um mecanismo simples, seguro e escalável para que desenvolvedores construam suas aplicações de forma desacoplada e no menor tempo possível. Claudenir mostrou a utilização do Swagger para a documentação de API, a extensão do Chrome ‘Postman’ para fazer requests em APIs, o Newman, um pacote Node utilizado para executar coleções do Postman via linha de comando e falou sobre o Jenkins para a integração contínua. A apresentação dele está aqui.

Danilo Feijó, tester na CI&T e entusiasta Ágil, falou sobre “BrowserSync: Acelerando seus testes manuais na web”. BrowserSync é uma ferramenta assistente para execução de testes manuais na Web, baseada em Node.js. Com esse assistente é possível replicar os testes feitos em um browser em outros de forma simultânea, ou seja, podemos testar um site no Firefox, Chrome e Internet Explorer ao mesmo tempo, interagindo apenas com um desses browsers. Aqui estão os slides dele.

Danilo Torres Porcelani, desenvolvedor na DB1 Global Software, falou sobre “Automação de testes com Docker“. Porcelani pontuou a necessidade de estratégia na hora de refatorar um código ou projeto e, segundo ele, não ter medo de encarar essa necessidade (desafio) e “conteinizar” aos poucos faz parte desta estratégia.

Segundo Porcelani, a “conteinerização” simplifica o desenvolvimento e a execução de testes, elimina inconsistências de ambientes e a necessidade de servidores destinados ao uso de QA exclusivamente, dentre outras características. Veja os slides que ele usou aqui.

Lucas Martins Ramos, desenvolvedor na Geofusion, falou sobre “Programando Testes: uma quebra de paradigmas entre DEV e QA”. Ramos enfatizou a necessidade do “pareamento” entre desenvolvedores e testers na hora de pensar e escrever os testes. Em sua experiência em equipe trabalhando junto com um profissional de qualidade sem experiência em programação, Ramos compartilhou que aprendeu a enxergar diversos cenários de teste e ensinou como programar esses cenários para o tester. Com essa troca de conhecimento, o time se beneficiou com o aumento de qualidade no desenvolvimento do projeto e com o aumento de conhecimento da equipe. Para Ramos, a expressão “Dev x QA” deve ser para a multiplicação, para o aumento de qualidade e conhecimento das esquipes multidisciplinares. Os slides dele estão aqui.

Edlaine Zamora, desenvolvedora Web na DB1 Global Software, falou sobre “Tomada de decisão baseada em testes de carga“. Segundo ela, os testes de carga detectam falhas de segurança e são importantes para a tomada de decisão pois expõem as capacidades e fraquezas de um sistema e coletam dados para fins de escalabilidade, sendo que uma decisão assertiva deve se basear em dados. Veja aqui os slides.

Priscila Formaggio e Jessica Mollo, analistas de Qualidade no UOL Pagseguro, falaram sobre “A transição de um QA tradicional para um Agile Tester”. Elas definem os testers que atuam apenas no final do processo de desenvolvimento como os “tradicionais” ou “Jurassic testers”. No contexto ágil, o tester é parte do processo eatua do início ao fim.

As palestrantes definiram três perfis de profissionais de qualidade:

  1. QA de negócio: aquele que tem uma visão analítica, macro do negócio e suas regras, atua mais próximo do P.O. e do cliente, além de testes funcionais e não funcionais.
  2. QA técnico: aquele com habilidades voltadas para a programação, atuando mais próximo dos desenvolvedores, TDD, Pair Programming, frameworks, etc.
  3. DevQA: aquele com conhecimento no pipeline de implantação e configuração de scripts, que motiva o time nas práticas de entrega e integração contínua.

Para elas, é importante o profissional de qualidade identificar suas habilidades, sair da resistência e adquirir novos conhecimentos, desenvolver novas habilidades e consolidar seu papel no time. Sempre aprender, melhorar e trabalhar em equipe foram as orientações finais. Veja os slides aqui.

Robson Correa, especialista em Qualidade na UOL e na BOLD International, falou sobre como um desempregado pode se recolocar como QA. Correa baseou sua palestra na sua história pessoal. Ele saiu de uma empresa na qual trabalhava há anos e foi para Liverpool, na Inglaterra, onde aprendeu inglês e se aprimorou, estudando diariamente.

Nessa jornada de aperfeiçoamento profissional e recolocação no mercado de trabalho, Correa fez uma análise e compartilhou em sua palestra dados como as cidades com mais vagas disponíveis na área de Qualidade, faixa salarial, processos seletivos, etc. As informações estão disponíveis nesses slides.

Para encerrar, Alan José Nascimento, líder de testes na Raia Drogasil, falou sobre “O que a IOT vai mudar no mundo dos Testes”. Alan acredita que em breve teremos uma nova grande mudança em como trabalhamos com qualidade e testes, assim como foi com a mudança do modelo tradicional de testes de software para testes automatizados. Para ele, em um futuro próximo, os termos como Eletrônica embarcada, sensores, relés, etc, serão familiares para os testadores de software, que também testarão hardware. Veja a apresentação aqui.

Para mim, foi uma trilha ótima que abrangeu diversos assuntos e deu dicas de ferramentas a serem estudadas e que estão sendo utilizadas na comunidade de Testes e Qualidade de software, tratou de assuntos técnicos e não-técnicos como a postura de um profissional de qualidade dentro de times multidisciplinares.

Além de ter tido uma visão sobre o mundo de Qualidade de software por meio de outros profissionais, vi que nosso trabalho vai além de automatizar testes, tem a ver com a postura ativa e focada no bem-estar da equipe e da entrega de resultados com qualidade para o cliente, além de atingir o usuário final de forma a encantá-lo. Em resumo, me identifiquei com essas pessoas e com a área e quero continuar a estudar e me tornar cada vez mais uma profissional de Qualidade com excelência. =)

O que é documentação viva?

por elessandraestevao

Por definição, documentação é o ato ou processo de documentar, ou seja, reunir informações para provar algo. No contexto de desenvolvimento de software, especificamente em ágil, precisamos documentar o sistema de uma forma que seja também ágil. Para isso, usamos o processo de documentação viva. Vamos entender um pouco mais esse conceito?

Uma documentação é viva porque é dinâmica e acompanha o processo de desenvolvimento desde o levantamento de requisitos e de cenários funcionais até a implementação, gerando documentos e sendo utilizada e conhecida por toda a equipe de desenvolvimento, além dos stakeholders. A “vida” da documentação está relacionada a algo que tem suas “funções vitais” ativas, como por exemplo nortear a implementação de features, revelar o status do sistema ou esclarecer interessados sobre como o sistema funciona. Quem dá vida a essa documentação é a equipe de desenvolvimento, testers e demais stakeholders. Não é um monte de papel engavetado, consultado em casos emergenciais e apenas isso. Pelo contrário, é algo que cresce, muda e evolui junto com o desenvolvimento do sistema, com o envolvimento de toda a equipe e interessados.

Parte da documentação viva engloba a especificação das funcionalidades a partir de exemplos, o que chamamos de especificação por exemplo. Com ela, os interessados não-técnicos podem interagir e entender sem dificuldades, uma vez que a especificação é feita em linguagem natural e é voltada para as regras de negócio. Essas especificações descrevem por meio de exemplos os cenários funcionais do sistema, os quais são “traduzidos” em uma validação que verificará periodicamente (isso é configurável) se o sistema faz o que deveria, ou seja, o que está especificado. Além disso, a validação também avalia se essa especificação continua representando com fidelidade o que o sistema faz, ou seja, se está atualizada. Uma especificação traduzida em validação é uma especificação executável, e isso faz parte do que a constitui “viva”, pois o que é vivo tem reações e interações. A especificação reage contra o sistema que está sendo validado. Reagir às especificações contra o sistema é testar, e os testes também são parte de uma documentação viva.

Um dos artefatos da documentação viva é um documento ou relatório resultante da validação do sistema a partir da especificação executável. Este artefato às vezes pode ser confundido como sendo a própria documentação viva, porém uma documentação viva diz mais sobre o processo que gera esse artefato. O documento ou o relatório final é onde culmina todo o processo de documentação realizado.

O que deveríamos ter em processos ágeis se não uma documentação ágil? Um projeto sem documentação fica refém do entendimento técnico principalmente dos desenvolvedores de software e do que está na cabeça dos que estão trabalhando nele de perto. Uma documentação que não reflete o sistema e que não evolui com ele também não atende às necessidades de processos ágeis, afinal nesses processos nada está escrito em pedra. Uma documentação viva pode ser uma aposta e uma prática de equipes ágeis que se preocupam em garantir a qualidade do que fazem ao invés de apenas “entregar” o que o cliente solicitou no prazo estipulado. A documentação viva pode estar incluída nas estimativas de tempo e esforço de desenvolvimento como uma prática de garantia de qualidade do time.

Um sistema de documentação viva é essencial e deveria ser de alta importância para todos os envolvidos no projeto, principalmente pela equipe de desenvolvimento. É algo que deveria ser comprado por todos do time, que por sua vez deveria se comprometer a dar muita importância a essa documentação quanto se dá ao código fonte do sistema. Por quê? Porque quem vai dizer daqui a alguns meses o que o sistema faz ou não faz para um stakeholder? Quem vai poder orientar as decisões sobre as mudanças funcionais, seus impactos e estrutura funcional do sistema quando este for de grande complexidade? Quem pode mostrar o esqueleto funcional do sistema sem ter que rodar a aplicação em uma reunião não-técnica? Quem pode mostrar ao time como está o sistema, se funciona como deveria ou tem algo quebrado? Esta função é da documentação do projeto. Mas uma documentação convencional é difícil de manter e de atualizar, demanda muito esforço e não acompanha a evolução do sistema ou suas mudanças. É uma documentação morta, que não cumpre sua finalidade. Por isso a documentação deve ser viva. Viva porque é atual e acompanha o sistema, sendo seu reflexo traduzido em formato não-técnico, ao qual não apenas desenvolvedores ou testers têm acesso e podem entender, mas qualquer interessado no projeto.

Ficou alguma dúvida ou tem algo a dizer sobre o tema? Aproveite os campos abaixo! Até a próxima.