Consolidate all user facing changes in 6.6 to aid release, blog and testing

[OliverHannan]

To expedite 6.6.0 RC2 can we have a list of all user facing changes?

The reason for this is it, will aid the efficient internal QA testing but also a blog post (to alert DROID community generally) and future user research.

They are neatly summed up here but it'd be good to double check. We can then move to describe, test and screenshot for the reasons given.

This ticket will be done when we have a consolidated list.

[steve-daly]

Yes, https://github.com/digital-preservation/droid/pull/631 has some excellent write up of the command-line changes. It would be useful to look for things like this too https://github.com/digital-preservation/droid/pull/631/commits/16fa95561875af91cc5479d0e8019ecceae7d56f as that's a useful change to 'profile mode' that we'd want to re-test and communicate.

[OliverHannan]

Hi @paulwellsagilej, as part of this tickets getting over the line and getting our RC out can you sense check the testing spreadsheet I shared? This isn't so much the results, more that the testing is sufficient to cover what we now know about the large outstanding PR.

[paulwellsagilej]

I have spent some time looking through the DROID test plan and doing some sample testing of DROID 6.6 on Mac OSX Venture 13.0.1. The wording of the instructions and the expected outcomes are clear in all cases. The DROID desktop user interface is compact, so 81 tests seems extensive enough.

In accordance with the Testing Ice-cream Cone - these manual tests are a validation of the UI itself rather than the functions which UI actions trigger.

6.6 doesn’t have to be perfect, it just has to be an improvement on 6.5. Having looked through the affected UI code:

The export dialog has been revised to include new column options. There are new controls around exporting fields wrapped in quote marks. There are minor tweaks to the layout of the profile form.

These changes have been in use for months now, they are unlikely to have caused any problems for which there is no workaround.

However this change request was intended to target the command line. The command line tests are more sensitive given they can break non-human clients which rely on that interface. The command line module does have some unit tests and for the future we should check the code coverage of those unit tests. However, there is certainly enough information in the test description for manual testing. Again, it is mostly a matter of checking that the command line is interpreted correctly, not that the results are accurate.

There clearly has been a lot of manual testing done already (as recorded in the 6.6 test results spreadsheet). I would think the best course of action would be for an internal team familiar with DROID to proceed one more time through the manual tests around exporting in the GUI (which should take no longer than a few hours). As for CLI testing, certainly manually test the new features and rerun any test profiles which we have against the release candidate. Ideally, if there could be a beta release then that would be the easiest way to check against a bulk of real-world data for any obvious breaks in backwards compatibility.