Meeting minutes
Current Sprint
July 26 to August 6
Rich: Working test queue
and on Test runner
Need to hookup new backend to test runner
Will probably fall into next sprint too.
Starting work on settings page this sprint. Do not have time for settings page yet.
End of current sprint test queue and most of test render and test run will be wired to new back end.
Some of work on test render hook up to back end may run into next sprint.
August 9 sprint
Finish test run and settings wiring to new back end.
So all pages but reports will be running on new back end.
Will work on deployment/migration plan for moving to staging.
Discussed value of data migration during deployment.
Sharing sandbox with community group
Wiki page about accessing sandbox in bocoup repo
<Rich_Noah> https://
CG members can go in either as tester or admin
Noon Pacific Meeting Starts Here
Community Group Meeting -- Monthly Workstream Roll Up Meeting
App development workstream update
<jesdaigle> Rich: test queque functionality is on sandbox, received feedback from Matt King
<jesdaigle> Rich: next up is backend work on the test run. Test renderer is merged but there is no front end yet.
<jesdaigle> Matt King: Big piece of work for this version of the app is the backend and changing the data model. No big UI changes except for one screen. FE parity between the old and new version. Test runner will no longer have an iFrame.
<jesdaigle> Matt King: wiring backend to FE, test queue, test runner (incluces test rendering), settings page and reports page. Hopefully before the end of the next sprint 8/20 we hope to have the queue, test running, settings and new allow list ready for staging and then to production. Excludes reports.
<jesdaigle> Matt King: Question that is on the table is saving time and money by not migrating any of the existing report data to the new backend. Jes shared that it could be a significant savings of effort which would speed the timeline and save money. Data from last year is checkbox and menu bar. We could re-run all of that. Is there real value to keeping it?
<jesdaigle> James: checkbox has been updated so the data won't correspond to it anyway. Same treatment should be applied to menubar so that it's consistent and then re-run test plan.
<jesdaigle> James: I would be happy to drop the data.
<Rich_Noah> https://
<jesdaigle> Rich: accessing the sandbox. Created a wiki page that provides steps to access. Access is governed by Bocoup group on Github, to get around that there is an environment that allows you to be either tester or admin. Test queque is all that is working. None of the other links will work right now.
<jesdaigle> Matt: Let's send an email with a link to the Wiki.
Automation workstream update
Mike P from Bocoup leading work; out on PTO for 3 weeks.
<jesdaigle> Rich: Automation is continuing. Mike will be out for 3 weeks. Simon will be back in a few weeks. Mike has been exploring how Windows work and getting it vocalized, as well as documentation.
Mike: interested in keeping speech driver as simple as possible.
Discussed how automated testing can utilize speech drivers and problems related to that.
Product version requirements
<Matt_King> Wiki page: https://
Matt_King: this is important to have people running new tests.
Matt_King: gain crystal clarity on running them the first time
Matt_King: new ui when adding new test have to enter browser version and screen reader version. super granular control
Matt_King: when those fields are entered they create heading in the test-queue
Matt_King: can end up with bazillion headings if you type the wrong thing in the edit field
Matt_King: what are the versions we want to require when people run these tests
Matt_King: Final conclusion: the product versions do not matter that much. can achieve same objective if people are running different versions of same software.
Matt_King: when reporting having diversity brings some advantages
Matt_King: if people were running different builds of Jaws people would see that
Matt_King: bugs for old AT software are a no care for screen readers
Matt_King: using the most current version creates the real value
Matt_King: having the strict requirements is not needed to meet our objectives.
James: what are the practical take aways?
James: should we be asking testers for version information?
Matt_King: we need to make it very easy for testers to enter or automatically.
James: we talked about a screen reader protocol
Matt_King: does anyone know if through a plugin you can get operating system information?
James: it is very limited, would have to use a tool running on the host system. Possibly via a web socket
Matt_King: can you access a node script?
James: would have to access an external process for that information
Matt_King: it would be helpful if someone could research this idea. Helpful for reporting.
James: is it acceptable to ask testers to install software?
Matt_King: yes, I think that would be acceptable.
Matt_King: running the test for the purpose of testing the test plan
Matt_King: AT and Browser version not relevant
Matt_King: Second purpose to gather useful data for machine testing, full confidence testing. Exact match to machine test.
Matt_King: we need to do every version of AT and browser combination
James: would it be important to capture this information
Matt_King: yes it is
Third purpose is to generate data to send to AT developers. Use the most recent screen reader.
Matt_King: if you have identical results it does not matter if browser version is different.
Matt_King: this is the net of my analysis. Not sure what people will be entering in version field, i.e. Chrome 91, in version field.
James: will the goal be to have that entered by the user or the test queue administrator?
James: make the test queue version agnostic
Matt_King: this could simplify things
Matt_King: once you have some data out there when do you put it back in the test queue?
Matt_King: maybe the test queue has a way of checking when things are out of date. Possibly a way to enter version.