Beta Features - What am I testing for?

[influxx]

Is there a list of new features I missed that I should be testing for?

Been using Beta 2.6.3 for a few weeks now and its just fine, no different to my release version installed. Be good to know what I should be trying to break

[Old Bruce]

1 hour ago, influxx said:

Been using Beta 2.6.3 for a few weeks now

And it has been superseded by the release version 2.6.3 for about a week. Time to stop using the beta.

[walt.farrell]

1 hour ago, influxx said:

Is there a list of new features I missed that I should be testing for?

If this were a beta you should be testing (which, as Old Bruce mentioned, it isn't), you would see the list of any features to test and any fixed-bugs to test in:

1. https://forum.affinity.serif.com/index.php?/forum/138-new-features-and-improvements-in-26-beta/ for features, e.g. in this topic:
2. And for bug fixes, in https://forum.affinity.serif.com/index.php?/forum/139-other-new-bugs-and-issues-in-the-betas/ e.g. in this topic:

Note that since this is a 2.6.3 beta not a 2.6.0 beta, there usually would not be any new features in it; only bug fixes.

[influxx]

1 hour ago, Old Bruce said:

And it has been superseded by the release version 2.6.3 for about a week. Time to stop using the beta.

Missed the memo.

So I take it the beta version doesnt prompt you for an update as the release version does?

[MikeTO]

45 minutes ago, influxx said:

So I take it the beta version doesnt prompt you for an update as the release version does?

The beta and retail installations are completely separate. Your retail installation will prompt you to install a retail update, and your beta installation will prompt you to install a beta update.

[GarryP]

14 hours ago, influxx said:

Be good to know what I should be trying to break

I think it’s worth mentioning that the beta programme is not just for testing the ‘new stuff’, but it’s also for testing that the ‘old stuff’ hasn’t been broken.

Finding that things still work as expected is just as important as, and sometimes more important than, finding something that is wrong, especially if the thing being tested is something that a lot of people use often.

And it’s better to find a problem with the ‘old stuff’ in the beta than it is for that problem to be carried over to the next commercial release.

So the answer to the question: “What should I be testing?” is, in my opinion, basically: “Whatever you can, and as much as you can.”

[Bound by Beans]

On 5/21/2025 at 8:53 PM, influxx said:

Is there a list of new features I missed that I should be testing for?

As mentioned... regression test everything you hold dear first if you use Affinity regularly – especially in commercial work.

But also remember: when a fundamental flaw or bug makes it into a release of a new feature, it becomes part of the CanvaFinitiy family. A feature. For year or forever.

You might also want to ask yourself whether you really need to act as free labor for a massive commercial operation like Canva. They have billions. You don’t — you’re a customer. Right? So let them prove their worth. Just like we do in our own work, every day of the week.

[GarryP]

50 minutes ago, juliacartes said:

A clear changelog would really help so we know what to test and where to poke around.

Each new functionality or major change has its own thread in the “New Features and Improvements in X.Y Beta” section of the forums, with extra information being posted in the pinned threads in that section.

The “Other New Bugs and Issues in the Betas” contains other issues that have arisen from testing and other things that testers might want to know about.

Unfortunately however, there isn’t always much information for testers about how new functionalities should be used or what testers should expect by using them. If testers don’t know what should happen then it’s difficult to know if what’s happening should be happening, or whether they’re just not using it correctly.

If this information were to be improved then the testing could be improved as people would know what they should be doing/seeing rather than guessing/assuming.

[Alfred]

17 minutes ago, GarryP said:

Unfortunately however, there isn’t always much information for testers about how new functionalities should be used or what testers should expect by using them. If testers don’t know what should happen then it’s difficult to know if what’s happening should be happening, or whether they’re just not using it correctly.

Well put, Garry! During other beta tests that I’ve been involved in, we were encouraged to test freely so as to simulate ‘real world’ scenarios, but we also did some focused testing where we were asked to look at a particular area within the program and told what we should expect when using the new or improved functionality there.

[GarryP]

28 minutes ago, Alfred said:

we also did some focused testing where we were asked to look at a particular area within the program and told what we should expect

It doesn’t hurt to have many different ways to test things, but having some kind of ‘test plan’, as you say, would be useful on occasion.

I would expect Serif to have these for their own testing purposes, so this isn’t the first time that I’m wondering if these could be made available in some (possibly cut-down) form for external testers to use.

The information for beta testers has improved over time but there’s still not enough ‘meat on the bones’ in my opinion.

Testers are getting more information about what can be done with new functionalities but there’s still not enough information about how they should be testing it or, just as importantly, what should/shouldn’t be happening under testing.

Also, simply testing whether doing the right thing works as expected isn’t ‘proper’ testing in my opinion. Testers should have enough information to be able to know where the ‘fraying edges’ are so they can try and break things before commercial-release users get their hands on it.

(I used to work somewhere – a large multi-national organisation – where the official ‘testing’ methodology consisted of running a sub-set copy of the live data through the modified system, and if the modified system didn’t break then it was good to release. This, of course, led to a somewhat sub-optimal experience for the users.)

[Alfred]

32 minutes ago, GarryP said:

Also, simply testing whether doing the right thing works as expected isn’t ‘proper’ testing in my opinion.

I couldn’t agree more! There are always going to be users who get unexpected results because they’re doing the ‘wrong’ thing.

[JpLaf]

Je pense également, tout comme GarryP, qu'il n'y a pas assez de communication, d'une manière générale !

Et je constate que depuis quelque temps, on a plus signe de vie de l'équipe de développement !

[Patrick Connor]

13 hours ago, juliacartes said:

Totally get you—if it feels the same, it's hard to know what's new. A clear changelog would really help so we know what to test and where to poke around.

There is no beta currently. The release version is in sync with the beta build so there's no beta changelog to consider until we release the next beta.

[Affinityconfusesme]

On 6/2/2025 at 12:25 AM, Patrick Connor said:

until we release the next beta.

Are you able to share with us the ETA for the next beta?

[Alfred]

44 minutes ago, Affinityconfusesme said:

Are you able to share with us the ETA for the next beta?

What purpose would that serve?

[Affinityconfusesme]

To know what is going to be fixed in 2.6.4 before the next update cycle.

[Alfred]

26 minutes ago, Alfred said:

What purpose would be served [by knowing the ETA for the next beta]?

 

13 minutes ago, Affinityconfusesme said:

To know what is going to be fixed in 2.6.4 before the next update cycle.

At the risk of stating the obvious, knowing what is going to be fixed and knowing when we should expect to be able to test it are completely different questions.

[Affinityconfusesme]

Thats true. All I wanted to get was some more information about it. Thats all.