Welcome!

This group exists to raise the quality of the WordPress experience through testing.

We practice monitoring important flows. Bugs and bad experiences encountered while on flow patrolFlow patrol Flow patrol is the regular exercise and monitoring of important flows. Issues found while on flow patrol are kibbled and ticketed. Continuous flow patrol encourages use of our own software and increases awareness of what our users are experiencing day to day. Flow patrol duties are outlined in the flow handbook. are kibbled and ticketed. Continuous integration means it’s especially important to encourages use of our own software as we develop it and increase awareness for what our users are experiencing day to day.

  • Continuously exercise major flows. Publishing a captioned gallery starting from the logged-in front page, for example, is an important flowFlow Flow is the path of screens and interactions taken to accomplish a task. It’s an experience vector. Flow is also a feeling. It’s being unselfconscious and in the zone. Flow is what happens when difficulties are removed and you are freed to pursue an activity without forming intentions. You just do it.
    Flow is the actual user experience, in many ways. If you like, you can think of flow as a really comprehensive set of user stories. When you think about user flow, you’re thinking about exactly how a user will perform the tasks allowed by your product.Flow and Context
     that exercises the toolbar, editor, media modal, and galleries. Regressions anywhere in this flow should be noticed and fixed promptly.
  • Continuously exercise flows through new features as they are developed.
  • Post visual records (vizrecs) of flows to make/test. Show the flow. We must witness what we’re making every step of the way.
  • For features that replace or change existing ui, perform baseline visual records of major flows through the existing interface. These baselines can be used in comparison vizrecs as development proceeds.
  • Test patches and add screenshots to tickets. Screenshots of patched interfaces often do not make it on to tickets, particularly mobile screenshots. Use #needs-screenshots to tag tickets that need screenshots. Making sure tickets have screenshots promotes visual oxygen.
  • Post screenshots of bad, broken ui/ux in new features to the appropriate feature channels on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. Provide a visual heads up to feature teams.
  • Drop screenshots and vizrecs into ui/ux conversations in slack. So many conversations take place without reference to visuals or flow and often in complete ignorance of mobile.
  • Create tickets as needed. Crosslink tickets with any relevant vizrecs on make/test. Always include screenshots in tickets. Awareness requires history. Record what the interface looks like now, before changes.
  • Share your experiences and frustrations on make/test and in #core-test. Storyboard them with visual records.
  • Collect user experiences. Curate examples of real-life flow. Be an Alan Lomax of flow.
  • Do this with every device you have, particularly phones.
  • Be a critical part of a feature team.

The easiest way to continuously test WordPress as it is developed is to set up a site to automatically update to the latest nightly build. After that, consult the triage page.

 

Last updated: