quinta-feira, 5 de fevereiro de 2015

Princípio da incerteza de Heisenberg


\Delta x_i \Delta p_i \geq \frac{\hbar}{2}

“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?” 

 http://cdn.tshirtonomy.com/wp-content/uploads/He-Heisenberg-T-Shirt.jpg


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.

sexta-feira, 26 de dezembro de 2014

BDD + Smoke Test combina?

Atualmente estou trabalhando muito com BDD e Smoke Test Automatizado. Vou descrever o que eu conheço de intersecção dessas ferramentas de testes de software.

BDD um dos conceitos do Behavior Development Driven é: "Suficiente é suficiente"

Isso implica que o BDD só vai abranger aquilo que é importante para o momento.

Nos meus teste eu vou fazer todas as variações, mas será em outro momento, durante a criação e automação do BDD vamos nos concentrar em fazer funcionar o que precisa funcionar primeiro. Depois eu faço todas as variações e vou aprendendo com os testes exploratórios manuais.

E esse conceito é o Smoke Test, criar testes de fumaça que passa pelas principais funcionalidades para ver se tudo que deveria estar funcionando está. Nesse caso, alguns ciclos de BDD pode já deixar esse smoke test iniciado.

sexta-feira, 10 de outubro de 2014

Test Driven Development e o esforço para ter isso

Test Driven Development é uma pratica sugerida pela metodologia ágil XP. A ideia é fazer testes automatizados antes de desenvolver a implementação. Essa inversão traz diversos beneficios para o projeto como uma suite de teste maior, cobrindo mais casos e garantindo maior qualidade externa. Para escrever testes de boa qualidade, exige que o código também seja escrito com qualidade, usando boa orientação a objetos e talvez padrões de projeto para soluções.
Mas TDD não garante o código de boa qualidade se os testes não forem de boa qualidade. Para isso é necessário um esforço para manter o código sempre melhor e estudar praticas a fim de aumentar a qualidade. A pratica do TDD bem usada torna o produto melhor e a equipe produtiva.


TDD, XP, testes antes da implementação, qualidade externa, bons testes de unidade, orientação a objetos, codigo melhor, aumentar a qualidade deve ser estudada, pratica do TDD bem usada, produtiva

segunda-feira, 22 de setembro de 2014

É prioridade?

Se testar é uma prioridade,
Então vamos testar toda hora.

Se integrar é uma prioridade,
Então vamos integrar com frequência.

Se interações curtas é uma prioridade,
Entao vamos deixar as interações realmente curtas.

Se entregas constantes são prioridades,
Então vamos entregar todos os dias.

Autor: Rogério Figueiredo (https://github.com/rogersmuk)

segunda-feira, 7 de julho de 2014

Testes de unidade, integração ou sistema? Você já fez cada um deles?

Nas equipes de desenvolvimento é comum a discussão de que os testes de sistemas devem ser abrangentes, ou devemos aumentar a cobertura dos teste de unidade. Será que o entendimento de cada nomenclatura dos testes é igual para todos?

Na equipe que trabalho tivemos essas discussões e foi preciso igualar o conhecimento das nomenclaturas para que ter uma comunicação eficaz.

Um dos artigos usados como referência foi do Mauricio Aniche: http://blog.caelum.com.br/unidade-integracao-ou-sistema-qual-teste-fazer/

Texto coloca com precisão o que é cada teste. Também explica um pouco que cada um tem um contexto para ser usado.

sexta-feira, 20 de junho de 2014

Sessão de design colaborativo

Existem decisões que podem ser adiadas e outras que precisam ser tomadas o mais cedo possível.

Sessão de design colaborativo é uma forma de alinhar o entendimento do que vai trabalhado. É também usada para criar produtos diante de uma necessidade.

Glauber tem uma sugestão bacana em como a equipe pode conduzir essa reunião: http://glauberramos.com/sessao-design-colaborativo.html