No post de hoje compartilho com vocês um vídeo da Selenium conference 2014. Na apresentação, Dave Haeffner, um dos profissionais mais atuantes no trabalho com Selenium e autor do livro guia Selenium GuideBook, indica diversas fontes interessantes onde podemos encontrar materiais sobre automação com Selenium para testadores iniciantes, intermediários e avançados.
Vídeo da apresentação
Slides da apresentação
As etapas continentais da STWC-2014 chegaram ao fim e já foram divulgados os vencedores de cada continente, que terão a oportunidade de disputar o título da primeira edição da copa do mundo de testes de software. As finais ocorrerão entre os dias 10 e 13 de novembro em Potsdam, na Alemanha, durante a conferência Agile Testing Days 2014.
Como havia mencionando no post anterior sobre a copa do mundo, estávamos na expectativa dos resultados da etapa da América do Sul e felizmente o resultado foi maravilhoso, a minha equipe, CESAR Brazil, conseguiu o primeiro lugar e nesse momento já estamos em ritmo acelerado de preparação para as finais na Alemanha!
Para a etapa final teremos as 6 equipes já anunciadas:
A final deve seguir as mesmas regras das etapas continentais, porém não podemos descartar eventuais surpresas. Quando voltarmos da Alemanha completarei a série de posts sobre o evento compartilhando como foi a experiência de participar da etapa final =)
Entre os dias 11 e 13 de Agosto aconteceu em Nova York a nona edição do CAST 2014(Conference of the Association of Software Testing). A conferência voltada inteiramente para a área de Testes de Software contou com a participação de diversos palestrantes discutindo e compartilhando informações e experiências referentes aos mais diversos tipos de problemas e práticas aplicadas na indústria.
Os vídeos das palestras já estão disponíveis no canal da associação no youtube. Na lista de palestras várias me parecem bem interessantes, particularmente, optei por começar pelo Keynote realizado pelo James Bach, autor de diversos livros na área, com tema Test Cases are Not Testing: Toward a Performance Culture. Apesar de não ser um tema novo, debater sobre como devemos usar os casos de teste ou mesmo se devemos usá-los, ainda é algo que rende muitas discussões. No vídeo, James faz diversas comparações bem interessantes e que reforçam o erro que é tratar testes de software como uma simples aplicação de passos de um caso de teste.
“We’ve got to stop thinking of testing as a thing and start thinking about testing as a performance, like an actor in a play, in order to get management to appreciate what we do.”
Divirtam-se!
Capturar um screenshot é uma das ações frequentemente desejadas, quando automatizamos um teste com selenium.
A aplicação do screenshot, pode ser útil de diferentes maneiras, como provendo evidências de um problema encontrado ou servindo para análise e comparação do estado da interface, etc.
Abaixo, disponibilizo um exemplo, extremamente simples, utilizando o Selenium WebDriver com Java.
import java.io.File;
import java.io.IOException;
import java.util.Date;
import org.apache.commons.io.FileUtils;
import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;
import org.openqa.selenium.OutputType;
import org.openqa.selenium.TakesScreenshot;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
public class SimpleScreenshot {
private static WebDriver driver;
/**
* Inicialização do driver do firefox
*/
@BeforeClass
public static void beforeClass() {
driver = new FirefoxDriver();
}
/**
* Navega para url do bytes don't bite
* Captura o Screenshot
*/
@Test
public void testScreenshot() {
driver.get("http://www.bytesdontbite.com");
takeScreenshot("teste");
}
/**
* Método para capturar screenshot
* @param fileName - Nome do arquivo
*/
public static void takeScreenshot(String fileName){
File scrFile = ((TakesScreenshot)driver).getScreenshotAs(OutputType.FILE);
Date data = new Date();
try {
FileUtils.copyFile(scrFile, new File("D:\\SeleniumScreenShots\\"+fileName+ data.getTime()+".jpeg"),true);
} catch (IOException e) {
e.printStackTrace();
}
}
/**
* Encerra o driver
*/
@AfterClass
public static void afterClass() {
driver.quit();
}
}
Como pudemos ver no código acima, a única coisa que precisamos fazer é implementar o método takesScreenshot, e utilizá-lo nos pontos em que julgarmos necessário. No exemplo, simplesmente iniciamos um FirefoxDriver e o nosso “teste” se resumiu a navegar para a url do bytes don’t bite e em seguida chamar a captura do screenshot.
Ainda não conhece o Selenium?
Uma das mais utilizadas ferramentas para automação de testes em aplicações web. Permite interagir com o navegador e simular as operações comumente encontradas nas páginas web.
Deseja conhecer mais sobre o Selenium?
— UPDATE —
Inscrições abertas
O curso de Automação de Testes Para Web com Selenium está disponível na modalidade de Ensino à distância. Contaremos com um material de vídeo-aulas, apostilas e exercícios, além do acompanhamento de um professor/tutor.
Valor: R$250,00 (Pode ser parcelado no cartão de crédito)
No mês passado apresentamos a Copa do Mundo de Testes aqui no blog. E hoje, recebi a notícia que as inscrições para a primeira copa do mundo de testes de software estão oficialmente abertas. Abaixo, segue o resumo das principais informações.
Equipes:
Podem possuir de 1 a 4 integrantes. Não há limite de equipes por empresa.
Fase de Qualificação Continental:
Na primeira etapa, as disputas serão realizadas online. E apenas uma equipe será classificada por continente.
Fase Final:
Realizada presencialmente, durante o evento Agile Testing Days.
Critérios de Pontuação:
Os critérios não foram modificados, mantendo as informações do post anterior:
Diferentes aspectos levados em consideração, como: melhor bug report, melhor report de testes, bug mais valioso, etc.
O foco principal será o aspecto funcional de determinadas aplicações indicadas pelos avaliadores no início de cada etapa, podendo existir um tempo adicional alocado para aspectos não-funcionais.
O tempo para validação da aplicação sugerida será de aproximadamente 3 horas, podendo haver tempo adicional para aspectos não-funcionais.
Premiação:
Na etapa de classificação os vencedores continentais receberão:
– Entradas para os 3 dias do Agile Testing Days
– Passagens aéreas
– Shuttle aeroporto/hotel
– Hospedagem de 5 diárias
– Cópias autografadas do novo livro de Lisa Crispin e Janet Gregory
Por fim, os grandes vencedores da etapa final receberão:
Validação de layout nos diferentes browsers é um problema comum em diversos projetos de desenvolvimento de software. Afinal, assegurar comportamento e aspectos visuais adequados em diversas combinações de browser/SO é algo que demanda bastante tempo.
Durante essa apresentação na SeleniumConf 2013, Frank O’Hara apresenta um solução, que em conjunto com o Selenium, permite de maneira automatizada indicar erros de layout na aplicação.
Ainda não tive a oportunidade de utilizar a solução, mas parece bem simples associá-la ao Selenium.
Links do projeto:
O que o motiva no seu trabalho como testador? Stephen Janaway, profissional de testes há 12 anos, tenta nos ajudar a entender nossas necessidades profissionais e a determinar como você pode deixar de sentir que trata-se apenas de um trabalho para um estado de “auto-atualização”.
A seguir, apontamos alguns dos principais aspectos discutidos por ele.
Stephen inicia fazendo uma relação com a pirâmide das necessidades de Maslow, tentando entender como as principais necessidades dos seres humanos são atendidas. Considerando, que de maneira geral as pessoas tem um grande desejo de atingir seu potencial, de progredir. Para Maslow, as pessoas que alcançaram o ponto de auto-atualização tinham características comuns, como: criatividade, espontaneidade, visão clara do certo e errado, etc.
Em seguida, ele monta a pirâmide associando cada um dos grupos as necessidades dos testadores, tentando esquecer descrições de cargo e funções, mas considerando o que nos satisfaz como testadores.
Stephen aborda que no nível mais básico (aceitação) a função é vista como algo que qualquer um pode fazer e que não é respeitado ou apoiado pelos superiores. No nível seguinte os testes passam a um nível de aprendizado, onde os mesmos são incluídos, mas vistos como algo irritante. No terceiro nível começa a existir o respeito e os testers são vistos como parte do time, consultados e respeitados. Já no nível de interação o negócio depende e percebe o valor adicionado pelos testes. Por fim, chegamos ao grupo onde há o reconhecimento interno e externo da comunidade, onde ele cita Maslow “O que um homem pode ser, ele deve ser.”.
Por fim, o palestrante pergunta: Em que nível você acredita estar? O que pode fazer para subir ou se manter no topo ?
Segue, abaixo, o vídeo da palestra, são apenas 15 minutos, bem objetivo e vale a reflexão.
TestBash 2.0 – A Tester’s Hierarchy of Needs – Stephen Janaway from Software Testing Club on Vimeo.
Muitas vezes uma imagem diz mais do que mil palavras. No blog Cartoon tester, Andy Glover faz uso de imagens extremamente simples, mas que transmitem de maneira objetiva conceitos e práticas interessantes relacionadas com as atividades do engenheiro de testes.
A imagem abaixo é do post do blog, que fala de maneira correta sobre algumas atitudes que devemos ter no nosso dia a dia quando encontramos bugs. Abaixo, uma breve explicação dos pontos mencionados.
Se você encontrar um bug:
1 – Reporte-o, bugs não gostam de ser esquecidos.
Diversos motivos podem levar um testador a esquecer de reportar algum defeito encontrado, prazos apertados, tarefas acumuladas, desorganização ou simplesmente o fato de que algumas vezes os defeitos são encontrados antes mesmo dos testes, em conversas informais, treinamentos, etc.. e nem sempre os envolvidos tomam as devidas ações nessas situações.
2 – Conheça-o melhor, bugs gostam de ser compreendidos.
Antes de reportar um defeito, devemos entender por completo seu comportamento, sua abrangência e quais são seus impactos.
3 – Tire uma foto, bugs gostam de guardar recordações das ocasiões.
Screenshots, fotos e inclusive vídeos ajudam a evidenciar melhor a reportagem de um defeito, facilitando o entendimento do desenvolvedor e evitando CRs reabertas.
4 – Conheça seus companheiros, bugs são socialites.
Ao encontrar um defeito é comum que outros bugs estejam localizados nas suas redondezas, por isso é importante a varredura nas funcionalidades relacionadas para rapidamente detectar novas falhas.
5 – Reporte rapidamente, do contrário os bugs se estabelecem e fazem moradia.
Agilidade na reportagem permite que sua correção também seja antecipada, evitando que outros bugs causados pela falha já existente sejam revelados.
6 – Seja honesto, bugs não gostam de fofocas.
Classificação de severidade e prioridade supervalorizadas, melhorias registradas como defeitos, entre outros problemas frequentes, causam problemas na comunicação da equipe e atrapalham o andamento das atividades.
7 – Guarde como o conheceu, bugs são românticos.
Ao encontrar um defeito, a primeira tarefa é sempre de verificar quais foram os passos prévios para detecção do problema, reportar como podemos reproduzir o issue é essencial para os desenvolvedores durante a correção e também para os testadores no momento da verificação das correções.
8 – Não o ignore, bugs podem morder quando não apreciados.
Em meio a tantos bugs, normalmente encontrados durante os testes, é comum que em alguns momentos desprezemos alguns defeitos encontrados, por acreditarmos que os mesmos são irrelevantes ou nunca serão corrigidos. Porém, já cansei de ver defeitos ignorados sendo reportados posteriormente por clientes ou quando vistos por outros ângulos gerando consequências graves para o sistema.
Adicionaria a lista de atitudes a verificação dos defeitos já existentes, prática bastante simples, mas que muitas vezes é relegada, e que pode evitar trabalho desnecessário de diversas pessoas.
E vocês concordam com os tópicos? Sentiram falta de mais alguma atitude?
…………………………………………………………………………………………………………………………………………..
Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.
Os últimos dias que antecedem a uma entrega, com frequência, são repletos de correria, stress, pressão e claro bugs e mais bugs, que parecem intermináveis.
O que pode nos levar a pensar, que estamos cometendo os mesmos erros. Pensamos, refletimos, avaliamos e discutimos durante reuniões de Sprint Retrospective, que as vezes parecem intermináveis, o porquê de, mais uma vez, termos feito diversas horas extras nos últimos dias que antecederam a entrega.
Abaixo, listamos alguns dos fatores, que podem contribuir para esse número de bugs elevado, os quais podemos combater e assim, pelo menos, reduzir sua probabilidade de ocorrência.
Ausência de testes durante a sprint
Um dos problemas mais comuns que econtramos está relacionado a ausência de testes intermediários durante a sprint, sobrecarregando os testes de sistema realizados nos últimos dias e consequentemente proporcionando um número maior de CRs graves nos últimos dias.
Testes mal priorizados
Durante a execução do ciclo de testes de sistema, a priorização da ordem de execução também tem se mostrado um elemento fundamental para permitir que a maior parte dos defeitos graves sejam encontrados nos primeiros dias de execução.
Prazos irreais para testes
Sistemas gigantescos, com diversos requisitos de hardware, contando apenas com alguns dias para testes. Mais um grande motivo, para que o planejamento seja mal feito, a execução corrida e, desse modo, defeitos graves acabem não sendo antecipados ou até mesmo escapando.
Prazos irreais para correção
Desenvolvedores pressionados pelo “dia da entrega” implementando soluções, que nem sempre são a “melhor” solução, podendo, também, gerar novos bugs no sistema.
Especificação Deficiente
Estórias ou requisitos mal descritos, ausência de Product Owner ou Engenheiro de Requisitos, proporcionam dificuldades para desenvolvedores e testadores, o que acaba significando um maior número de defeitos.
Testes mal realizados
Diversos pontos da estratégia de testes podem precisar de uma boa revisão, é comum a ausência dos testes estáticos na documentação, a precariedade dos testes unitários, e a falta dos de componente. Criando, dessa forma, um enorme gargalo nos testes de sistema ou de regressão.
Porém, ledo engano nosso, achar que ao identificar e corrigir todos os possíveis problemas, nenhum bug grave será encontrado nos últimos dias. Na verdade, isso apenas minimiza o problema (o que é fundamental) e, hoje, não temos como garantir, que iremos conseguir antecipar todos os defeitos graves.
Enquanto houver tempo para testar, e o time possuir qualidade e disposição, devem haver bugs, inclusive graves…
E se adiarmos a entrega por mais alguns dias… continuaremos a encontrar bugs…
E você o que acha? Que outras medidas podem ser tomadas?
Acompanhe as novidades do BdB pelo Facebook, acesse e curta nossa página.
Por esses dias, estive relendo os posts sobre como são conduzidas as atividades de testes no google, entre outras coisas eles falam sobre os papéis, funções e de que maneira a qualidade de software é conduzida dentro da empresa.
No terceiro post da série, diversas afirmações chamaram a minha atenção e valem a nossa reflexão:
“Who better to do all that testing than the people doing the actual coding? Who better to find the bug than the person who wrote it? Who is more incentivized to avoid writing the bug in the first place?”
A partir dessa afirmação podemos ver que estamos passando por uma grande transição na engenharia de software. Onde há vários anos as empresas dão uma ênfase cada vez maior aos aspectos relacionados à qualidade de software e diversas estratégias surgiram e vêm sendo utilizadas para a organização das equipes e divisão das tarefas.
Porém, o que mais me chama atenção nessa primeira afirmação é como a idéia a que estava acostumado, de que precisamos de pessoas com dois perfis diferentes para testar e desenvolver um software está ficando ultrapassada.
Cada vez mais precisamos unir as duas disciplinas que se completam para assim entregar produtos de maior qualidade.
Claro, que para que isso aconteça é necessária uma mudança cultural e comportamental. Abandonarmos os antigos conceitos de que desenvolvedores não conseguem enxergar as falhas em seu próprio código, não gostam e não querem testar e tornar tudo em uma única tarefa.
Diversos benefícios podem emergir dessa tendência, como: detecção de defeitos cada vez mais cedo, maior liberdade para o engenheiro de teste focar em aspectos não funcionais, fluxos de integração e outros pontos que fogem a unidade do desenvolvedor, etc.
“quality is more an act of prevention than it is detection”
Desse modo, técnicas como o TDD podem ser excelentes caminhos para eliminar essa separação entre testes e desenvolvimento. Ajudando a tornar a qualidade cada vez mais um ato de prevenção do que detecção.
” Testing must be an unavoidable aspect of development and the marriage of development and testing is where quality is achieved”
É óbvio, que existem diferenças entre os diversos tipos de projetos e na realidade de cada uma das empresas, onde cada um possui necessidades diferentes as quais precisam ser avaliadas e planejadas.
Está cada vez mais claro o caminho para produzirmos softwares de maior qualidade, testes e desenvolvimento como uma só tarefa, apresentando um grau de automação cada vez maior. Para seguirmos esse caminho várias mudanças são necessárias tanto nas pessoas, como nos processos e ferramentas.
E vocês o que acham? É esse o caminho a ser seguido?
Bytes don't Bite! 