Bozzy

Quality Assurance Presentation

Brought to you by the team

Erica D.      |      Ian G.      |      Sophie L.P.      |  Ted M.

         KWRAERBG    AO*EUPB            SOEUF                TED

Stenography—What is it?

Written Shorthand → Machine Shorthand

Type Syllables, Words, Phrases instead of letters

200+ words per minute, fast as you can speak, think.

Less stress, better ergonomics

Open Source ♥︎ Steno

  • Steno was traditionally very proprietary
  • Hardware, software, and education were very expensive
  • But, wait! Open Steno Project is founded
    • Plover, first free steno engine 
    • Hardware is open and more affordable
    • Free educational resources (texts, games)
  • Our customer Mirabai Knight, founded the Open Steno Project, and our team member is currently the lead developer of Plover

Stenographic Dictionaries

  • Stenographers work with multiple dictionaries
    • One large dictionary
      • covers English (~150,000 entries)
      • oft-called "theory" dictionary
    • Several smaller dictionaries
      • Personal dictionaries
      • Job-specific and specialized dictionaries
  • Dictionaries have a configurable order
  • A dictionary entry consists of machine input to
    emulated keyboard output.

Enter… Bozzy

  • First free standalone stenographic dictionary editor
  • Named, by our customer, after James Boswell, right hand man of Samuel Johnson, who published the first comprehensive English dictionary.
  • Make editing stenographic dictionaries easier (vs manual editing)
  • Ease the conversion between Plover's JSON and RTF/CRE
  • Allow users of stenography systems to edit their dictionaries for free

Objectives

Sample Use Case: Open Dictionary

Sample Use Case: Convert Dictionary

Sample Use Case: Edit & Save

Architecture

  • JVM Desktop App, on Windows and OSX
  • Model View Controller architectural pattern
    • UI built using JavaFX and FXML
    • Controllers written using Scala 
    • Data models used to hold dictionaries, user settings, and data in memory, no database
  • Use the operating system's native file system     
    • Read and write dictionary files and user settings files

QA Strategy & Process

  • High internal standards
    • Unit test all new features
    • Mandatory code reviews
    • Code style
  • Highly engaged customer with personal interest
    • Incremental releases
    • Reviews against requirements
  • Large, willing-to-test community

Test Plan

  • Continuously...         (everyone)
    • unit test every feature
      • low-level
      • black and clear box testing
    • code review
    • "full-regression" suite, verify all core features still work
      • high-level tests
      • black box
  • Milestones...              (Ted, Sophie)
    • basic feature complete (interview with customer)
    • first public beta (Obs. session, design review, public feedback)
    • release candidate (Obs. session, public feedback) 
  // You are so jelly of our beautiful test cases.
  "The DictionaryEntry class" should "load a simple JSON entry" in {
    var entry = new DictionaryEntry("\"KOPB/SREPBGS\": \"convention\",",
                                    DictionaryFormat.JSON, "name")
    entry.stroke.raw should equal ("KOPB/SREPBGS")
    entry.translation.raw should equal ("convention")
    entry = new DictionaryEntry(
      "\"TRAOEU/SER/TOPS\": \"Triceratops\",",
      DictionaryFormat.JSON,
      "name"
    )
    entry.stroke.raw should equal ("TRAOEU/SER/TOPS")
    entry.translation.raw should equal ("Triceratops")
  }

Test Environment

Travis CI running tests on every push, building on release

SBT, build tool for Scala & Java applications

Test Data

  • The dictionaries to test and verify the system:
    • StenEd (RTF)
      • Simple theory dictionary in RTF
    • Magnum (RTF)
      • Complex proprietary dictionary
    • Plover Main (JSON)
      • GPL theory dictionary, default with Plover
  • Our tests are based off of data from these dictionaries, as well as custom entries made to test edge cases.
{
"#*E": "{>}{&e}",
"#*EU": "{>}{&i}",
"#*U": "{>}{&u}",
"#-D": "{^ed}",
"#-Z": "00",
"#240": "240",
"#45/TK-PL": "$45",
"#EUD/KWROPL": "idiom",
"#K*": "{>}{&k}",
"#KR*": "{>}{&c}",
"#KW*": "{>}{&q}",
"#KWR*": "{>}{&y}",
"#R*": "{>}{&r}",
"#W*": "{>}{&w}",
"*B": "B",
"*BG": "{^k}",
"*BGS": "action",
"*BS": "action",
"*D": "{^'d}",
"*E": "{>}{&e}",
"*E/KHREUPS": "Eclipse"
}

Core Regression Suite

The aim is to cover all functional requirements

Scripts should be executable manually,

or through automated testing.

Dictionary Management

  • Create a blank dictionary ("new")
  • Open an existing dictionary
  • Define a stroke for "new" dictionary
  • Move stroke between dictionaries
  • View diff
  • Save changes
  • Close "new" dictionary
  • Reopen "new" dictionary, verify priority
  • Reorder "new" and existing dictionary
  • Add same-chord stroke to "new" dictionary,
    verify that priority is handled.
  • 1.4
  • 1.1, 1.2, 1.3
  • 5.1
  • 5.2
  • 5.3
  • 5.4
  • 2.1
  • 3.1, 3.3
  • 3.2

Searching (Filtering, Sorting)

  • Load two dictionaries with data
    • One RTF/CRE, one JSON
  • Filter dictionaries:
    • By Stroke
    • By Definition
    • By Word Count
    • By Dictionary
    • By Stroke, Definition, Dictionary
  • Sort results by word count
  • Clear filter, sort by translation
  • FR 1, 4.1
    •  
  • FR 4.2
    •  
    •  
    •  
    •  
    •  
  • FR 4.3
  • FR 4.3

Backup / Conversion

  • Load two dictionaries with data
    • One RTF/CRE, one JSON
  • Add two backup directories
  • Run backup
  • Convert JSON dictionary to RTF
  • Verify unconvertables
  • Remove JSON dictionary
  • Add new RTF conversion
  • Convert new RTF back to JSON
  • View diff since backup
  • Restore from backup
  • FR 1
    •  
  • 6.2
  • 6.1
  • 7.2
  • 7.3
  • 2.1
  • FR 1
  • 7.1
  • 5.3
  • 6.3

Merge

  • Load two dictionaries with data
    • One RTF/CRE, one JSON
  • Merge RTF/CRE and JSON dictionary
  • Verify unmergeables
  • FR 1
    •  
  • 8.1
  • 8.2

Build

  • Load Plover `main.json`
  • "Build" with text that contains words
    not in `main.json`
  • Verify diff after build task
  • FR 1
  • 9.2
     
  • 9.3

Conclusion

  • Exciting new product type
  • Exciting new language for our team
    • Easy to test
  • Excited customer
    • Valuable, frequent feedback
  • Open Source means that all is up for scrutiny.
  • Test Plan is designed to give us more
    information than we need
  • Reiteration is key
  • Without quality, the software is useless
Made with Slides.com