Goals for W3C Web Testing
Bryan Sullivan, AT&T
If we believe the "HTML5" hype
(and we do)
- We need to prepare for the developer and user onslaught
- We need to avoid over-selling what it can do
- We need to ensure specs have really been validated
- We need to identify what's important to developers
- We need a system that can inform developers about what works, in what browsers/devices, and let them revalidate it
Defining the Important
- So far this is underway with CoreMob 2012, and 2013 is coming
- Importance is usually a question of detailed priorities
- Feature level priorities focus test development effort
- Importance can also shift, and must be kept up-to-date
Verifying that It Works
- We need a test framework that is:
- Centralized, interoperable across specs, an ingrained part of the W3C process
- Clonable (or at least privacy-enabling), to allow pre-launch device testing
- Automated to the fullest extent possible
- Data-focused, collecting/aggregating/exposing test results
Verifying that It Works
- We need test assets that are:
- Semantically associable to features and development stage
- Developed per feature priorities
- Shepherded through consistent development processes and life-cycle
- In summary
Focusing on CoreMob 2012
- What became clear as I researched a draft analysis of test coverage per CoreMob 2012
- W3C tests are all over the place
- It's unclear what lifecycle stage tests are at
- It's unclear what tests may be duplicated
- It's unclear how test map to coverage of assertions/requirements
- Dependency upon non-W3C tests are even less clear
- There are a lot of specs with 0 tests
2013 Web Testing Priorities
- Shift focus to open-source test suites/frameworks
- Focus initially upon Ringmark
- Get cloned test frameworks running in-house
- Identify CoreMob 2012 coverage & gaps
- Participate actively in W3C Web Testing
- Defining feature priorities thru CoreMob
- Helping organize efforts in W3C
- Taking on skill-matched tasks
