Upgrade to Pro — share decks privately, control downloads, hide ads and more …

[AmsterdamJS] Tales from the QA Crypt

[AmsterdamJS] Tales from the QA Crypt

Jennifer Voss

June 01, 2018
Tweet

More Decks by Jennifer Voss

Other Decks in Technology

Transcript

  1. View Slide

  2. View Slide

  3. View Slide

  4. Valid inputs
    https://blogs.msdn.microsoft.com/testing123/2009/02/06/email-address-test-cases/
    [email protected] Valid email
    [email protected] Email contains dot in the address field
    [email protected] Email contains dot with subdomain
    [email protected] Plus sign is considered valid character
    [email protected] Domain is valid IP address
    [email protected][123.123.123.123] Square bracket around IP address is considered valid
    "email"@domain.com Quotes around email is considered valid
    [email protected] Digits in address are valid
    [email protected] Dash in domain name is valid
    [email protected] Underscore in the address field is valid
    [email protected] .name is valid Top Level Domain name
    [email protected] Dot in Top Level Domain name also considered valid (use co.jp as example here)
    [email protected] Dash in address field is valid

    View Slide

  5. Invalid inputs
    https://blogs.msdn.microsoft.com/testing123/2009/02/06/email-address-test-cases/
    plainaddress Missing @ sign and domain
    #@%^%#[email protected]#[email protected]#.com Garbage
    @domain.com Missing username
    Joe Smith Encoded html within email is invalid
    email.domain.com Missing @
    [email protected]@domain.com Two @ sign
    [email protected] Leading dot in address is not allowed
    [email protected] Trailing dot in address is not allowed
    [email protected] Multiple dots
    [email protected] Missing top level domain (.com/.net/.org/etc)
    [email protected] Leading dash in front of domain is invalid
    [email protected] .web is not a valid top level domain
    [email protected] Invalid IP format
    [email protected] Multiple dot in the domain portion is invalid

    View Slide

  6. DEV
    DEV
    DEV
    QA
    Traditional QA
    ● Dev team
    ● QA lead

    View Slide

  7. DEV
    DEV
    DEV
    OFFSHORE
    ? ? ? ? ? ?
    QA
    Traditional QA
    ● Dev team
    ● QA lead
    ● Offshore

    View Slide

  8. Stuck in a repetitive
    workflow
    Tester: tests feature, reports a defect
    QA Lead: validates the defect
    Developer: validates the defect, fixes
    Repeat

    View Slide

  9. View Slide

  10. The undead legion of JS testing tools

    View Slide

  11. The undead legion of JS testing tools

    View Slide

  12. cypress.io
    https://www.cypress.io/how-it-works/

    View Slide

  13. Install cypress
    npm install cypress --save-dev
    npx cypress open

    View Slide

  14. Simple page load test
    describe('Home Page', () => {
    before(() => {
    cy.visit('http://localhost:3000' );
    });
    it('should load without error' , () => {
    cy.get('.App').should('exist');
    });
    });

    View Slide

  15. Demo
    http://localhost:3000/

    View Slide

  16. Dead simple testing
    ● No servers, drivers, or any other dependencies
    to install or configure
    ● Readable errors and stack traces
    ● Automatic waiting - no more async hell
    ● Control, stub, and test network traffic without
    involving your server
    ● Auto reload on changes
    ● Test responsive layouts by changing your app’s
    viewport size
    ● Active community & documentation

    View Slide

  17. Let testers do what
    they do best
    ● Represent your site users
    ● Find unexpected functionality or errors
    ● Let machines handle the boring, repetitive stuff
    REGRESSION
    SANITY
    SMOKE
    TESTS

    View Slide

  18. View Slide

  19. Traditional workflow

    View Slide

  20. Traditional workflow

    View Slide

  21. Traditional workflow (throwing it over the fence)
    ● What exactly is being tested?
    ● Where do those tests live?
    ● Can developers access and run tests?
    ● How long do test runs take?
    ● Context is lost by the time the defect
    reaches the developer

    View Slide

  22. Shift testing left

    View Slide

  23. Hold on...
    Won’t this approach take longer?
    How will we release on schedule?

    View Slide

  24. Releases
    https://blogs.technet.microsoft.com/devops/2016/06/21/a-git-workflow-for-continuous-delivery/

    View Slide

  25. View Slide

  26. How does this happen?
    ● Requirements were unclear/incorrect

    View Slide

  27. How does this happen?
    ● Requirements were unclear/incorrect
    ● Was your work even in the testing environment to begin with?

    View Slide

  28. How does this happen?
    ● Requirements were unclear/incorrect
    ● Was your work even in the testing environment to begin with?
    ● Environment disparity
    ○ Dependencies
    ○ User settings
    ○ Environment specific changes (production vs development)

    View Slide

  29. How does this happen?
    ✓ Requirements were unclear/incorrect
    ✓ Was your work even in the testing environment to begin with?
    ☠ Environment disparity
    ○ Dependencies
    ○ User settings
    ○ Environment specific changes (production vs development)

    View Slide

  30. Dive into containers
    ● Small & lightweight
    ● Easily configurable
    ● Open source

    View Slide

  31. Demo
    http://localhost:3000/

    View Slide

  32. Necessary changes
    ● Tooling
    ● Workflow
    ● Infrastructure

    View Slide

  33. See eye to eye with
    your team
    ● Write automated tests
    ● Make them available to everyone
    ● Keep testing close to development
    ● Use Docker for environment parity
    ● Do what works for your team

    View Slide

  34. Thank you!
    https://github.com/jennvoss/tales-from-the-qa-crypt
    @vossjenn
    https://www.elsevier.com/careers

    View Slide