Testing before release

KStars is pretty mature but we still see bugs with each release. What can be done to improve the quality of releases ?

I know on the Mac side of things Rob has been good at posting early versions for testing. But the uptake on people downloading and getting the opportunity (clear night) to test is pretty low. I often download the early release to test, but didn't really get a chance to test until 3.1.1 came out.

But I absolutely agree. There are so many novices trying out EKOS for the first time, and almost every point release has had show stopping bugs in some part of the application. Whether it was plate solving, scheduler, focusing, guiding, etc. Something minor creeps in and causes an issue. With all the new people, getting a first opportunity to check out KStars/EKOS for the first time, there is a high probability that they will not get it to work and opt to use a different set of applications instead.

First impressions are huge, and the less technically inclined will easily overlook the benefits of the program if their first impression is that it doesn't work, or is difficult to get going. If there were a systematic approach to releases that involves some quality testing, I think it would improve things. But we have to have people willing to download and test.

Speaking of which - one of the blatant bugs is the graphic hand controller available from the mount panel. "Mount control - KStars".
I OFTEN 50/50 see discrepancies between the mount (and even KStars top buttons) and this HC panel. For example. Clicking PARK
button will often PARK and the HC will say Unparked. Or Visa Versa. Also the same for TRACKING. (IDLE). the graphic HC is often
opposite of what is really set.

This little HC panel (with target search) is often the flag ship window... (new people use) and having it be so blatantly wrong 50% of
the time isn't comforting when trying the software. I've learned to live with it and use it as a "STOP" motion control and tend to ignore
or accept it's errored display.

But considering multiple authors and the vast comprehensive feature list, I tend to look past bugs that can be worked around.
I need functionality (so guiding, and no crashes) are a priority for me. I can live with a buggy hand control window.

In my opinion there should be a suite of automated test cases to run before a new version is released. Testing scripts should be created for any scenario. This doesn't need to be a big bang implementation but rather a work in progress: starting with a few but essential test cases but then add more as time goes...
I think something similar was proposed a couple of years ago but I guess it didn't happen:
indilib.org/forum/general/1315-indi-testing-framework.html

But isn't nightly the testbed? If you want after testing then we wait for the stable release?

Yes I agree. I don’t know how software is tested but in chip design it’s put through rigorous simulation testing.

I love Kstars but the récurrence of bugs is beginning to make me look at other options. It’s so cool when it works but totally sucks when it doesn’t.