Drupal Testing: Testing Types & Who Does Them

QA must have autonomy from DEV org management in order to foster TESTING best practices & proper system analysis. The whole point to QA is to have specialists leverage unique skill sets under a continually improving 'Testing Program' without becoming 'developer clones testing their own product'. Test professionals are not developers who test. Security is a great metaphor to invoke here. GREAT Developers & Testers haven't the slightest clue on how to account for cyber-security... the field moves too fast & is too complex to casually approach the undertaking. Likewise, Test professionals that hone their craft don't have the headroom a Developer does to simultaneously stay abreast of software development evolution & cutting edge language updates & usage.

 

Unit Testing [D]

http://toolsqa.com/software-testing/unit-testing/

  • Smallest testable part of an application
  • whitebox testing
  • test framework can make calls to system methods and APIs 'by any means necessary' to isolate and verify components work as designed
  • for components that have inputs from other components, 'stubs' or 'mocks' are usually employed to simply 'provide' inputs to the target of the test then EXPECTED data output/results are validated.

Integration Testing [D,Q]

http://toolsqa.com/software-testing/integration-testing/

  • Partial sections or Complete solution is tested
  • Various components are now interdependent so 'boundaries' are now scrutinized
  • BDD seems to address as it focuses on application behavior rather than system functions
  • QA could also create BDD counterparts, but regression should be picking up holistic test suites as features are added/modified
    • it is more efficient to TAG regression tests with BDD feature ids rather than DUPLICATE Dev's BDD Integration Tests

Smoke Testing [D,Q]

http://toolsqa.com/software-testing/smoke-testing/

  • A build tool to catch catastrophic failures immediately after a build
  • Prevents QA testing costs by catching basic/fundamental flaws before time spent on further review
  • Dev should do as part of Exit Criteria out of Dev
  • Test should do as Entrance Criteria into Test

Sanity Testing [Q,P]

http://toolsqa.com/software-testing/sanity-testing/

  • AFTER Regression Testing
  • BEFORE Production Release
    • Are the major release components present & working
    • Did these changes break anything in the
  • Best done by human
    • main app functions
    • bugfixes in release
    • probing newly touched areas

 

System Testing [Q]

http://toolsqa.com/software-testing/system-testing/

  • entire scope of QA testing AFTER Dev has released a build
  • AFTER unit & integration testing ( Dev )
  • AFTER Post-Build Smoke Test
  • AFTER Sanity Test? ( By Human )
  •  

Regression Testing [Q]

http://toolsqa.com/software-testing/regression-testing/

 

User Acceptance Testing ( UAT ) [Q,P,User]

http://toolsqa.com/software-testing/user-acceptance-testing-uat/

  • By QA, Product Owner, Client, End Users
  • "Did Thing Right" not "Right Thing"

End-To-End ( E2E ) [Q,P,User]

http://toolsqa.com/software-testing/what-does-end-to-end-test-mean/

  • AFTER Functional & System Testing
  • Actual production data
  • Same environment as production
  • Tests should
    • exercise system component boundaries
    • have WELL DEFINED input/output data
    • be diagrammed to illustrate coverage
  •  

 

Exhausive List of Testing Types

Adhoc
Acceptance
Accessibility
Agile
API
Automated
All Pairs
Beta
Black Box
Backward Compatibility
Boundary Values
Big Bang Integration
Bottom Up Integration
Integration Testing in Large
Integration Testing in Small
Branch Testing
Browser Compatibility
Compatibility
Component
Condition Coverage
Dynamic
Decision Coverage
End-to-End
Exploratory
Equivalence Partitioning
Functional
Fuzz
GUI
Glass Box
Gorilla
Happy Path
Integration
Interface
Internationalization
Keyword Driven
Load
Localization
Negative
Non-Functional
Pair Testing
Performance
Penetration
Regression
Retesting
Risk-based
Smoke
Security
Sanity
Scalability
Stability
Static
Stress
System
Soak
System Integration
Unit
Usability
UAT
Volume
Vulnerability
WhiteBox