No primeiro post de 2014, compartilho com vocês uma lista com alguns dos blogs/sites, perfis do twitter e canais do You Tube, que acompanho (ou tento acompanhar) para me manter atualizado sobre testes de software.
Blogs/Sites:
Outros:
Sentiu falta de algum? Pode adicionar nos comentários =D
Quando falamos de automação de testes um dos principais benefícios citados é a possibilidade de obtermos a execução de um ciclo completo de execução num espaço de tempo bem inferior aos testes manuais. No entanto, quando começamos a nos aprofundar no assunto vemos que existem diversas práticas que podem ser utilizadas na codificação dos testes para permitir uma eficiência ainda maior.
Uma das possibilidades para o aumento da velocidade de execução é a utilização dos Headless Browsers, tema que inclusive foi abordado pelo Elias Nogueira, do excelente blog Sem Bugs, em sua apresentação sobre CasperJS. Resumindo numa única frase o Headless Browser é um navegador sem a interface gráfica.
Estudando sobre o assunto vi que já existe uma implementação do WebDriver para Selenium, que utiliza o PhantomJS e de maneira bem simples permite que possamos nos beneficiar da utilização de um headless browser. O projeto chamado Ghost Driver funciona perfeitamente e sua integração ao seu projeto é extremamente fácil utilizando o Maven.
Para adicioná-lo ao seu projeto basta seguir as orientações do projeto no github e se ainda tiver dúvidas basta seguir as orientações do post no blog Assert Selenium do Manoj Kumar. Além disso, a excelente apresentação abaixo, realizada pelo Ivan de Marino, um dos responsáveis pelo projeto, resume bem os benefícios da utilização e as orientações básicas.
Fiz um teste rápido num dos meus projetos e o ganho de velocidade foi significativo, como exemplificado pela imagem abaixo:
Ainda não conhece o Selenium? Em outubro estarei ministrando um curso presencial no CESAR.EDU, onde abordaremos os conceitos básicos para utilização do Selenium WebDriver apoiado por diversas práticas em sala, segue o link para mais informações:
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:
Contribuir para o aumento do nível de confiança, prevenir e encontrar defeitos estão entre os principais objetivos que queremos alcançar quando testamos um software. Porém, para atingirmos essas metas não existe uma simples receita de bolo e precisamos estar sempre atentos para maximizar as nossas chances de entregarmos constantemente software de qualidade e que atenda às necessidades dos clientes.
Apesar de nossos esforços, invariavelmente temos que lidar com os defeitos escapados, que normalmente implicam em stress, re-trabalho e desgaste na relação com o cliente. Em meio ao problema, uma das primeiras ações que temos é a análise da causa raiz, ou seja, identificar o porquê do defeito ter ocorrido e consequentemente do mesmo não ter sido identificado nas etapas anteriores de validação.
Diversos podem ser os motivos para a falha na detecção do defeito, por exemplo:
– Cenário de teste não estava coberto.
– Teste existia, mas não foi priorizado para o ciclo de execução.
– Teste existia, foi priorizado, porém não foi executado corretamente.
– Teste existia, foi priorizado, executado corretamente, porém diferenças de ambiente não permitiram a detecção da falha.
– Etc.
Porém, ainda há um outro motivo, que talvez seja um dos mais frustrantes – O teste existe, mas está errado.
Quando isso acontece, independente de planejarmos corretamente, o teste, seja ele manual ou automático, nunca nos trará o resultado correto e a falha inevitavelmente aparecerá em produção. Nesses casos, ainda temos como dificuldade adicional o fato de que a re-execução do nosso teste não ajudará na reprodução do erro, podendo inclusive gerar ruído na comunicação e dificuldades na identificação da causa do problema e consequentemente em sua correção.
Identificar testes com defeito não é algo simples e corremos o risco de executá-lo diversas vezes e confiarmos em resultados enganosos. Para tentar minimizar esse tipo de situação, podemos realizar algumas ações:
– Revisar os testes existentes
– Se forem testes manuais, mudar o responsável pela execução
– Aprofundar-se no funcionamento de mocks e stubs utilizados para teste
– Conhecer as limitações das ferramentas utilizadas
– Revisar as pré-condições e o ambiente de validação
E você já enfrentou o problema de ter falhas escapadas devido a testes defeituosos? Que ações tomou para tentar evitar que o problema se repetisse?
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.
Nos dias 23 e 24 de Abril aconteceu mais uma edição do GTAC – Google Test Automation Conference. Dessa vez também acessível via streaming. Os vídeos das 16 horas de palestras também já estão disponíveis no YouTube, os quais compartilho com vocês no decorrer do post. Ainda não tive tempo de assistir a todas as palestras, mas tenho certeza que o nível do conteúdo é excelente, pois já assisti a vários vídeos dos anos anteriores.
As palestras estão divididas em dois vídeos, referentes a cada um dos dias do evento, porém a partir da agenda você pode saltar para a palestra que mais lhe interessar. Já assisti as 4 primeiras palestras do dia 1 e gostei bastante das duas primeiras.
Segue a lista das palestras e os vídeos.
Dia 1:
| Duração | Palestrante | Empresa | Tema |
| 00:15:00 | Tony Voellm | Opening | |
| 00:45:00 | Ari Shamash | Evolution from Quality Assurance to Test Engineering | |
| 00:45:00 | James Waldrop | Testing Systems at Scale @Twitter | |
| 00:30:00 | Break | ||
| 00:45:00 | David Burns and Malini Das | Mozilla | How Do You Test a Mobile OS? |
| 01:00:00 | Lunch | ||
| 00:45:00 | Igor Dorovskikh and Kaustubh Gawande | Expedia | Mobile Automation in Continuous Delivery Pipeline |
| 00:15:00 | David Röthlisberger | YouView | Automated Set-Top Box Testing with GStreamer and OpenCV |
| 00:15:00 | Ken Kania | Webdriver for Chrome | |
| 00:15:00 | Vojta Jina | Karma – Test Runner for JavaScript | |
| 00:15:00 | Patrik Höglund | Automated Video Quality Measurements | |
| 00:15:00 | Minal Mishra | Netflix | When Bad Things Happen to Good Applications… |
| 00:30:00 | Break | ||
| 00:45:00 | Tao Xie | North Carolina State University | Testing for Educational Gaming and Educational Gaming for Testing |
| 00:45:00 | Simon Stewart | How Facebook Tests Facebook on Android | |
| 00:15:00 |
Dia 2:
| Duração | Palestrante | Empresa | Tema |
| 00:15:00 | Opening | ||
| 00:45:00 | Mark Trostler | Testable JavaScript – Architecting Your Application for Testability | |
| 00:45:00 | Thomas Knych, Stefan Ramsauer, Valera Zakharov | Breaking the Matrix – Android Testing at Scale | |
| 00:30:00 | Break | ||
| 00:45:00 | Guang Zhu (朱光) and Adam Momtaz | Android UI Automation | |
| 01:00:00 | Lunch | ||
| 00:45:00 | Jonathan Lipps | Sauce Labs | Appium: Automation for Mobile Apps |
| 00:15:00 | Eduardo Bravo | Building Scalable Mobile Test Infrastructure for Google+ Mobile | |
| 00:15:00 | Valera Zakharov | Espresso: Fresh Start to Android UI Testing | |
| 00:15:00 | Michael Klepikov | Web Performance Testing with WebDriver | |
| 00:15:00 | Yvette Nameth, Brendan Dhein | Continuous Maps Data Testing | |
| 00:15:00 | Celal Ziftci, Vivek Ramavajjala | University of California, San Diego | Finding Culprits Automatically in Failing Builds – i.e. Who Broke the Build? |
| 00:30:00 | Break | ||
| 00:45:00 | Katerina Goseva-Popstojanova | West Virginia University | Empirical Investigation of Software Product Line Quality |
| 00:30:00 | Kostya Serebryany | AddressSanitizer, ThreadSanitizer and MemorySanitizer — Dynamic Testing Tools for C++. | |
| 00:30:00 | Claudio Criscione | Drinking the Ocean – Finding XSS at Google Scale | |
| 00:05:00 |
No primeiro post de 2013 relacionado a testes, compartilho com vocês uma palestra que encontrei do James Whittaker na conferência StarWest (Software Testing Analysis and Review) 2011. Largamente conhecido por suas contribuições a nossa área, ele questiona de maneira forte qual o verdadeiro papel dos testes.
James aborda diversas questões, que nos levam a refletir a importância de cada uma de nossas tarefas, por exemplo:
– Como ganhar respeito para os testes?
– Os testes são apenas uma disciplina que apoia o desenvolvimento?
– Os softwares estão ficando melhores… Porquê?
– Os bugs que você encontra poderiam ser encontrados pelos usuários?
– A única coisa que se mantém atualizada é o código.
O vídeo tem 55 minutos, mas tenho certeza que é um tempo bem investido. Assista e avalie como você se sente em relação ao seu trabalho com testes e principalmente como você pode torná-lo melhor?
Pessoalmente, concordo com muita coisa dita por ele no vídeo. Se prestarmos bastante atenção, o tom forte utilizado é apenas para chocar e chamar a nossa atenção a um problema visível e que muitos preferem empurrar com a barriga. Cada vez mais precisamos entregar valor, e ficar gastando tempo com atividades que pouco beneficiam o desenvolvimento do produto é um erro grave, do mesmo modo que o tempo perdido com trabalho que poderia ser melhor executado por ferramentas.
Você concorda com o cenário geral descrito por Whittaker? Ele, inclusive, aponta que estávamos enganados e que, sim, usuários e desenvolvedores podem testar melhor que uma equipe de testadores.
Link do post falando das ferramentas que o google tornou open-source para testes, mencionado no vídeo :
No início do vídeo James faz um rápido questionário com a platéia, adicionei as perguntas abaixo em português, compartilhe conosco sua resposta:
Em nosso dia-a-dia, frequentemente, entramos em contato com pessoas e empresas, que até então não conhecíamos. Nesse instante, automaticamente, registramos nossas primeiras impressões sobre as características e comportamentos do outro. Impressões essas, que com o passar do tempo poderão se mostrar verdadeiras ou não, porém, definitivamente, influenciam na maneira como agimos e interagimos.
Nos tempos atuais podemos fazer uma análise parecida da relação das pessoas com os softwares, desde os aplicativos e jogos, que instalamos em nossos dispositivos móveis aos sistemas complexos que utilizamos em nosso ambiente profissional.
Essa primeira impressão de clientes e consumidores em relação a um software pode ser afetada por diversos fatores, entre eles:
– Interface gráfica
– Facilidade de Uso
– Performance (lentidão)
– Falhas (bugs)
No entanto, ao contrário das pessoas, primeiras impressões ruins de um software dificilmente são revertidas, isto acontece porque é muito fácil para o usuário, simplesmente, buscar por outro sistema, que apresente o mesmo serviço, porém com um nível de qualidade satisfatório. Principalmente, no ambiente web e nos dispositivos móveis, onde essa troca é ainda mais simples e menos custosa.
E o que podemos fazer para que nosso software não cause uma má impressão?
Acredito que o aspecto central é conhecermos bem as reais necessidades dos nossos clientes, identificar os aspectos fundamentais tanto do ponto de vista funcional como não-funcional e, definitivamente, nunca relegar a segundo plano a qualidade, afinal há cada vez menos espaço e tolerância com sistemas defeituosos e pouco confiáveis.
Link Adicional – The power of a first Impression
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!
Algum tempo atrás, trouxemos no BdB Recomenda o projeto chamado Codeacademy – Learn to Code, uma maneira extremamente interativa de aprender a programar, através da prática direta da programação.
O post de hoje, faz uma nova indicação, que parece ser uma alternativa ainda melhor para o aprendizado online e sem custos, graças a excelente qualidade do material didático auxiliado pela boa organização das lições no site.
OUdacity foi fundado por três especialistas em robótica, que acreditavam que muito do valor de suas aulas na universidade poderiam ser disponibilizados online e a um custo muito baixo.
Os fundadores acreditam que o ensino universitário pode ser de alta qualidade e de baixo custo. Usando a economia da Internet, eles conectam professores de altíssimo nível a milhares de estudantes em quase todos os países da Terra.
O custo para começar o aprendizado é ZERO. A quantidade de cursos oferecidos já é considerável, entre eles estão disponíveis:
– Introdução a programação com Python
– Desenvolvimento Web – Construindo um Blog
– Introdução ao Teste de Software
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!
Trocar de emprego nem sempre é uma decisão fácil, vários elementos surgem enquanto pesamos as vantagens e desvantagens da mudança na vida profissional.
É fundamental avaliarmos todos os pontos relevantes do ponto de vista profissional e pessoal, tentando não focar apenas na diferença salarial. Oportunidades de crescimento, aprendizado, estabilidade e até a qualidade de vida proporcionada devem ser avaliadas.
Nessa situação é comum consultarmos aos amigos e colegas mais próximos da atual empresa e, quando possível, da “talvez” futura empregadora. Outra fonte bastante utilizada é a internet, desde o site oficial da empresa, a blogs e notícias relacionadas podem apresentar informações interessantes nesse momento de escolha.
O TGIF de hoje indica o site Glassdoor, que se propõe a ser a fonte central para esse tipo de informação, nele os usuários podem fazer reviews sobre as empresas que trabalham, apontando informações nas diversas áreas relevantes, como: oportunidades de carreira, benefícios, cultura e valores, etc.
Na análise de cada empresa, existem ainda, detalhes sobre o processo seletivo, vagas em aberto e informações gerais sobre a companhia.
A imagem abaixo exemplifica o resumo das avaliações da Apple.
Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.
Bytes don't Bite! 