Ideias óbvias que acabamos esquecendo de usar:
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Fonte:
Python 2.7.6 (default, Dec 3 2014, 13:49:35)
[GCC 4.4.6 20120305 (Red Hat 4.4.6-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
sexta-feira, 19 de junho de 2015
segunda-feira, 1 de junho de 2015
Agile Testing in Growing Agile
Conheci hoje um livro excelente que está sendo desenvolvido em: https://leanpub.com/AgileTesting/read
Preciso ler e vou comentar algo sobre ele.
Dica de hj.
Preciso ler e vou comentar algo sobre ele.
Dica de hj.
quarta-feira, 8 de abril de 2015
Referência de emulação do Chrome no Selenium WebDriver
Encontrei na documentação do ChromeDriver como usar o painel de emulação.
Fonte: https://sites.google.com/a/chromium.org/chromedriver/mobile-emulation
Requisitos:
Selenium 2.45
ChromeDriver 2.14
Criei um test Junit para testar
A partir dessa referência é possível isolar as configurações para que abra um site com a emulação de alguns dispositivos que deseja suportar.
Acredito que seja possível fazer coisas interessantes para testes responsivos.
Fonte: https://sites.google.com/a/chromium.org/chromedriver/mobile-emulation
Requisitos:
Selenium 2.45
ChromeDriver 2.14
Criei um test Junit para testar
A partir dessa referência é possível isolar as configurações para que abra um site com a emulação de alguns dispositivos que deseja suportar.
Acredito que seja possível fazer coisas interessantes para testes responsivos.
terça-feira, 7 de abril de 2015
Esquema tático, futebol versus desenvolvimento
Esquema tático de futebol ⚽
Compactação
Triangulação
Contra ataques
Cruzamentos
No desenvolvimento de software
Compactação => kanban swarming
Triangulação => Code review
Contra ataques => Homologação
Cruzamentos => Mapeamento de trade off (adicionar colunas no quadro Kanban)
Compactação
Triangulação
Contra ataques
Cruzamentos
No desenvolvimento de software
Compactação => kanban swarming
Triangulação => Code review
Contra ataques => Homologação
Cruzamentos => Mapeamento de trade off (adicionar colunas no quadro Kanban)
sábado, 7 de março de 2015
Qualidade e a relação com quantidade de trabalho
Foco é um dos elementos principais para ter um trabalho de qualidade.
O método Kanban ajuda a diminuir o trabalho em andamento e como efeito direto traz foco e consequentemente qualidade.
O método Kanban ajuda a diminuir o trabalho em andamento e como efeito direto traz foco e consequentemente qualidade.
quinta-feira, 5 de fevereiro de 2015
Princípio da incerteza de Heisenberg
“Quanto maior o esforço de um lote mais tempo levará para ser feito...” Isso é verdade somente se a eficiência é alta. (geralmente não é!)
Eficiência do fluxo = Touch Time / Lead Time (%)
Lotes grandes, médios e pequenos param em filas igualmente!
Esforço não é determinante para a previsibilidade!
Para um processo com 25% de Eficiência do fluxo, temos umas variabilidade de uma historia de 2 pontos e outra de 12 pontos, isso resulta em 600% de variação, mas no fluxo ficam igualmente esperando na fila e o tempo total até chegar no cliente (lead time) tem variação de 35% entre 29 e 28 dias.
Limitar o trabalho em progresso é importante. Pra que? O sistema de trabalho fica mais previsível e estável. Com eficiência do fluxo estável, terá um sistema previsível.
Cost of Delay A pergunta mais fundamental sobre orçamento e portfólio é aquela menos perguntada: “Quanto dinheiro nós perdemos por mês sem esse projeto/feature?”
Fontes:
http://pt.wikipedia.org/wiki/Princ%C3%ADpio_da_incerteza_de_Heisenberg
http://pt.slideshare.net/rodrigoy/
segunda-feira, 2 de fevereiro de 2015
Links
Boa tarde galera! Segue alguns links sobre testes, vale apena dar uma olhada.
http://context-driven-testing.com/
http://www.geraldmweinberg.com/Site/Home.html
http://www.teatimewithtesters.com/#!magazines/galleryPage
http://www.utest.com/
http://www.satisfice.com/
http://katrinatester.blogspot.co.nz/
http://martinfowler.com/
http://www.softwaretestingclub.com/
http://www.ministryoftesting.com/
http://www.womentesters.com/
http://eviltester.com
http://keeptesting.com.br
http://lazytester.com
https://azevedorafaela.wordpress.com
http://www.thoughtworks.com/insights/software-testing
http://googletesting.blogspot.com.br/
http://www.ministryoftesting.com/
http://www.utest.com/
http://blog.utest.com/
http://eviltester.com
http://www.guru99.com/software-testing.html
http://www.stickyminds.com/
http://www.dextra.com.br/page-objects-padrao-de-projeto-para-organizacao-de-testes-funcionais/
http://pt.slideshare.net/kyrios/especificao-por-meio-de-exemplos-bdd-testes-de-aceitao
http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/
Abraços.
Assinar:
Postagens (Atom)