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

[ForwardJS] Tales from the QA Crypt

[ForwardJS] Tales from the QA Crypt

An anthology of QA horror stories from the past, and how to avoid such situations with TDD. When tests are built in from the beginning and not tacked on after features are built, fewer defects are created and development moves faster. JavaScript has all the tools required to cover your automated testing needs, and writing tests in the same language as your app is a no brainer. We'll cover the tools available today and the logistics of merging your QA and dev teams.

Demo code can be found at https://github.com/jennvoss/tales-from-the-qa-crypt

Jennifer Voss

April 05, 2018
Tweet

More Decks by Jennifer Voss

Other Decks in Programming

Transcript

  1. 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@[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
  2. Invalid inputs https://blogs.msdn.microsoft.com/testing123/2009/02/06/email-address-test-cases/ plainaddress Missing @ sign and domain #@%^%#$@#$@#.com

    Garbage @domain.com Missing username Joe Smith <[email protected]> Encoded html within email is invalid email.domain.com Missing @ email@[email protected] 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@domain 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
  3. DEV DEV DEV OFFSHORE ? ? ? ? ? ?

    QA Traditional QA • Dev team • QA lead • Offshore
  4. Stuck in a repetitive workflow Tester: tests feature, reports a

    defect QA Lead: validates the defect Developer: validates the defect, fixes Repeat
  5. Simple page load test describe('Home Page', () => { before(()

    => { cy.visit('http://localhost:3000' ); }); it('should load without error' , () => { cy.get('.App').should('exist'); }); });
  6. 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
  7. 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
  8. 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
  9. How does this happen? • Requirements were unclear/incorrect • Was

    your work even in the testing environment to begin with?
  10. 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)
  11. 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)
  12. 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