<div dir="ltr"><div dir="ltr"><br></div><div>Hi,</div><div><br></div><div></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 28, 2021 at 11:09 PM Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Isn't the Kiwi user test framework supposed to be directed at<br>
recognising these regressions? Could we get a status update on that<br>
and what needs to be done on pushing that effort forward? (The<br>
<a href="https://github.com/qcooperative/qgis-core-tests" rel="noreferrer" target="_blank">https://github.com/qcooperative/qgis-core-tests</a> repo seems to be all<br>
but abandoned...?)<br>
<br></blockquote><div><b><TL;DR></b><br></div><div>1. Yes, indeed, the goal of the QA testing framework [0] is to catch this kind of anomalies before normal users do.<br></div><div></div><div>2. The mentioned repository represents only a sub-part of the QA infrastructure, the work has continued on the kiwi platform (check a more detailed status below).</div><div>3. Putting it simply, to move forward, we now need, community feedback\buy-in, more tests, more testers, and ofc time.<br></div><div>4. Giovanni's freeze/Release candidate proposal is absolutely necessary if we want to be able to catch issues related to packaging, which includes dependencies bumps or changes. It's hard, if not impossible, to test a moving target. Besides, manual testing is a time-consuming activity, one week would be better than nothing but, very short to run all the (expected) test cases, have time to fix the issues, and re-test the fixes.</div><div><b></TL;DR></b></div><div><br></div><div><b>QEP 180 Status</b><br></div><div>Regarding the status of the work, we have:</div><div>- established/proposed a base methodology for how to run tests <a href="https://github.com/qcooperative/qgis-testing/blob/main/README.md">[0]</a>;</div><div>- implemented a TCMS (Test Case Management System) infrastructure <a href="https://qgis.tenant.kiwitcms.org/">[1]</a> using <a href="https://kiwitcms.org/">https://kiwitcms.org/</a> free instance (available for open source projects);</div><div>- created a limited set of test cases (manual tests) on kiwi <a href="https://qgis.tenant.kiwitcms.org/cases/search/">[2]</a>, to serve as examples and for internal testing (so far);<br></div><div>- revived Boundless's the tester plugin <a href="https://github.com/qcooperative/qgis-tester-plugin">[3]</a>;</div><div>- created a limited set of semi-automated test for the tester plugin <a href="https://github.com/qcooperative/qgis-core-tests">[4]</a> (the repo mentioned above), to serve as examples and for internal testing (so far);</div><div>- organized and executed test plans for the 3.16.4 and 3.18.0 releases, for Ubuntu 20.04 and Windows 10 <a href="https://qgis.tenant.kiwitcms.org/plan/search/">[5]</a>, using several nightlies, in an iterative procedure, to polish the process as much as possible.<br></div><div></div><div><br></div><div><b>Next steps (outside QEP 180 - grant 2020 scope)</b><br></div><div>Until the next release (3.20), my plan is to:</div><div>- Create more test cases. This can't be done without the community buy-in, including the developers, that, better than anyone else, know what has been changed during the release cycle, and what functionalities were not possible to fully cover using unit tests. Alessandro already requested test cases for geopackages and spatialite usage in the browser panel, which is WIP.</div><div>- Attract users to become testers and train them.<br></div><div>- Organize the test plans for 3.20 release, in as many platforms as possible (depending on the number of available testers, ofc)<br></div><div>- Execute the test plans and report the issues. This should be done during the feature freeze period, ideally on a full freeze including from packaging or Release candidate.</div><div><br></div><div>More stuff to do:<br></div><div>- Move testing documentation [0] to official QGIS documentation.</div><div>- Create a testing data set for use in tests (or improve QGIS data sample).<br></div><div><b><br></b></div><div><b>Blockers\annoyances</b></div><div>The fact that we are running kiwi on a free instance of <a href="https://kiwitcms.org/">https://kiwitcms.org/</a> has a few limitations:</div><div>1. A very annoying two-step registry process. People need to register on <a href="http://kiwi.org">kiwi.org</a>, and then request access to the QGIS tenant to someone already accepted.<br></div><div>2. No users and group permissions settings. Meaning that all users that have access to QGIS kiwi instance have read and write access to all test cases, test plans, executions, etc... Anyone can make a mistake and erase a lot of work from others.</div><div>3. No public (unregistered read-only) access to test cases and test plans, to use in GitHub and mailing list links. This is not related to the free instance, it's how kiwi works. <br><br></div><div>I think annoyances 1 and 2 could be solved by hosting our own kiwi instance or paying for one of their subscriptions plan (32€/mo).</div><div><br></div><div>For annoyance 3, a self-hosted instance would allow for a workaround. I have opened a Feature Request <a href="https://github.com/kiwitcms/Kiwi/issues/2229">[6]</a> on kiwi github, but obviously, that does not mean it will ever be implemented. I already asked for a cost estimate.</div><div><b></b></div><div><br></div><div>Best regards,</div><div><br></div><div>Alexandre Neto<br></div><div> </div><div>[0] - <a href="https://github.com/qcooperative/qgis-testing/blob/main/README.md">https://github.com/qcooperative/qgis-testing/blob/main/README.md</a></div><div>[1] - <a href="https://qgis.tenant.kiwitcms.org">https://qgis.tenant.kiwitcms.org</a></div><div>[2] - <a href="https://qgis.tenant.kiwitcms.org/cases/search/">https://qgis.tenant.kiwitcms.org/cases/search/</a></div><div>[3] - <a href="https://github.com/qcooperative/qgis-tester-plugin">https://github.com/qcooperative/qgis-tester-plugin</a></div><div>[4] - <a href="https://github.com/qcooperative/qgis-core-tests">https://github.com/qcooperative/qgis-core-tests</a></div><div>[5] - <a href="https://qgis.tenant.kiwitcms.org/plan/search/">https://qgis.tenant.kiwitcms.org/plan/search/</a></div><div>[6] - <a href="https://github.com/kiwitcms/Kiwi/issues/2229">https://github.com/kiwitcms/Kiwi/issues/2229</a></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Nyall<br>
<br>
<br>
<br>
<br>
<br>
> I like this idea.<br>
><br>
> Would you see that happen during feature freeze or post release?<br>
> How would this work branding wise, i.e. what will be the name of this, something like beta or release candidate?<br>
><br>
> Matthias<br>
> _______________________________________________<br>
> Qgis-psc mailing list<br>
> <a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a><br>
_______________________________________________<br>
Qgis-psc mailing list<br>
<a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a><br>
</blockquote></div></div></div>