quarta-feira, 9 de abril de 2014

Referências TDD/BDD

Gostaria de agradecer muito o colega Eduado Lima pelas referências:

ARTIGOS:

*Artigo em que o James Coplien critica fortemente o TDD e outras práticas do XP ( MUITO polêmico, mas vale demais a leitura): http://www.rbcs-us.com/images/documents/User-Stories-and-Test-Driven-Development.pdf

*Definição de TDD do Martin Fowler: http://martinfowler.com/bliki/TestDrivenDevelopment.html

*Comentários sobre BDD do Martin Fowler: http://martinfowler.com/bliki/GivenWhenThen.html

*Diferenças entre BDD e  TDD:

*Paper do Kent Beck (cara que popularizou o aperfeiçou o TDD, praticamente o pai da prática) sobre o SUnit, o primeiro framework em que se usaram as técnicas de TDD
como se usa hoje, e um marco na prática: http://www.xprogramming.com/testfram.htm

*Vídeo-aulas de TDD, ensinadas diretamente pelo Kent Beck:


*Post do Uncle Bob sobre TDD, refatoração de testes e arquitetura: http://blog.8thlight.com/uncle-bob/2014/01/27/TheChickenOrTheRoad.html

*Post sobre as 3 regras do TDD do Uncle Bob: http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd


*Posts do Uncle Bob sobre TDD em Startups: http://blog.8thlight.com/uncle-bob/2013/03/05/TheStartUpTrap.html

*Post sobre BDD do Dave Astels (Se não me engano o artigo que cunhou o termo BDD): http://web.archive.org/web/20090419153557/http://techblog.daveastels.com/2005/07/05/a-new-look-at-test-driven-development


*Post de BDD do Dan North(Um dos pais do BDD): http://dannorth.net/introducing-bdd/
*Debate épico, lendário e monumental entre o Uncle Bob e o James Coplien sobre TDD: http://www.infoq.com/interviews/coplien-martin-tdd

LIVROS:

1)Iniciantes:
- Test-Driven Development By Example (Do Kent Beck, obrigatório pra quem quer estudar TDD) => http://www.amazon.com/Test-Driven-Development-By-Example/dp/0321146530

- Capítulo 4 do livro Agile Software Development: Principles, Patterns and Practices do Uncle Bob (espetacular) => http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445/

- Capítulo 5 do livro The Clean Coder: A Code of Conduct for Professional Programmers, do Uncle Bob (espetacular) => http://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073/

- The Art of Unit Testing: with examples in C# (Passo-a-passo em TDD para programadores .NET) => http://www.amazon.com/Art-Unit-Testing-examples/dp/1617290890


2)Intermediários/Avançados:
- Capítulo 9 do livro The Clean Code: A Handbook of Agile Software Craftsmanship, do Uncle Bob => http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/

- xUnit Test Patterns: Refactoring Test Code (Catalógo de Patterns de testes, para usuários mais avançados) => http://www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054/

- Growing Object-Oriented Software, Guided by Tests (Evolução de sistemas orientados a objeto com o uso de testes) => http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627/


- The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends (Se aplica mais ao Ruby, mas fornece muitas definições sobre BDD, com alguns dos criadores da técnica) =>

-Working Effectively with Legacy Code (Refatorando e lidando com código legado, usa testes como a técnica central para lidar com código legado ) => http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

segunda-feira, 31 de março de 2014

Data Driven Testing (Teste guiado a dados)

Data-driven testing é a criação de scripts de testes para executar juntamente com conjunto de dados.

A estrutura exige uma lógica reutilizável para que as entradas e resultado esperado sejam fornecidas pelos dados e a ação se repete variando os dados.

Esse conceito existe no Junit com a classe Parameterized. doc: http://junit.sourceforge.net/javadoc/org/junit/runners/Parameterized.html

Para utilizar, deve colocar a anotação na classe:
@RunWith(Parameterized.class)
 
Além de colocar anotação no método estático que provê os dados:
@Parameterized.Parameters 


Dessa forma é possível colocar dados em seus scripts do JUnit.

Mas para facilitar criei um método que le de um xls e retorna o matriz de objetos.

Usando a biblioteca jxl, alterar o pom.xml (ou adicionar o jar) com:
        <dependency>
            <groupId>net.sourceforge.jexcelapi</groupId>
            <artifactId>jxl</artifactId>
            <version>2.6.12</version>
        </dependency>

O metodo ficou assim:
public class ReaderXls {
  
    public static Object[][] lerXls(String arquivo) {
        Workbook workbook = null;
        try {
            workbook = Workbook.getWorkbook(new File(arquivo));
        } catch (Exception e) {
            e.printStackTrace();
        }

        Sheet sheet = workbook.getSheet(0);
        int linhas = sheet.getRows();
        int colunas = sheet.getColumns();
        System.out.println(linhas);
        System.out.println(colunas);

        Object[][] retorno = new Object[linhas][colunas];

        for (int i = 0; i < linhas; i++) {
            Object[] linha = new String[colunas];
            for(int j =0; j < colunas; j++)
            {
                linha[j] = sheet.getCell(j, i).getContents();
            }
            retorno[i] = linha;
        }

        return retorno;
    }
}

O metodo de dados na classe de teste ficou assim:
@RunWith(Parameterized.class)
public class CadastroUsuarioTest{

    @Parameterized.Parameters
    public static Collection<Object[]> dados(){
        Collection dados = Arrays.asList(
                ReaderXls.lerXls("C:\\Automacao\\usuario.xls")
        );
        return dados;
    }


Veja exemplos em:
http://examples.javacodegeeks.com/core-java/junit/junit-parameterized-test-example/

http://www.mkyong.com/unittest/junit-4-tutorial-6-parameterized-test/
 
 
 
 

sexta-feira, 21 de fevereiro de 2014

Bugs? Tolerância zero!

Em conversas em grupo de teste é comum alguns falar que existe um limite aceitável para bugs. Alguns até falam que pode ser 5% do total de bugs aceitável ir para produção.

Na minha opinião a tolerância deve ser ZERO!

Se algum bug for para produção deve ser adotado como débito técnico.

terça-feira, 4 de fevereiro de 2014

Analise de vulnerabilidades Cross Site Scipt

Fonte: https://www.owasp.org/index.php/Testing_for_Cross_site_scripting

Ataques de Cross Site Script (XSS) ocorrem quando um invasor usa uma aplicação web para enviar código malicioso, geralmente do lado cliente para um usuário final diferente.

Testes XSS são importantes para que o sistema não seja publicado com uma vulnerabilidade, podendo comprometer a confiabilidade e integridades das informações prestadas.

Nesse artigo referenciado pode ser encontrado algumas técnicas de teste XSS para básicos.

segunda-feira, 6 de janeiro de 2014

Dilema do QA

Segue artigo sobre deploy continuo.

http://www.startuplessonslearned.com/2009/12/continuous-deployment-for-mission.html

boa leitura.

segunda-feira, 23 de dezembro de 2013

Testes de performance - Bate papo com Samanta Cecilia do Elias Nogueira

Entrevista com Samanta Cecilia do Elias Nogueira.

Desse bate papo consegui entender que o trabalho de performance é de responsabilidade que o QA seja persistente, busque métricas e levar para a equipe onde podem ser as melhorias. Também o trabalho é mais de pesquisa do que automatizada, o conceito é mais importante que as ferramentas.

Links passados:
http://gtmetrix.com/
https://developers.google.com/speed/pagespeed/insights/


quarta-feira, 6 de novembro de 2013

As Emoções nos testes

Você consegue identificar quais emoções tem com o projeto que trabalha? ou na equipe que trabalha?

Isso poderia influenciar os testes. Alguns estudos sobre o assunto foi publicado em: http://www.ministryoftesting.com/2013/09/the-emotional-tester/

Não tem um rigor cientifico mas é uma boa idéia para reflexão e melhor entrosamento com a equipe.