Replies: 3 comments
-
I think this is a great idea for all the reasons mentioned above, but mainly: Introducing testing from user perspective is something we seem to be missing the most. To expand a little, from my QA experience elsewhere, I think it would be best to provide users with form / testing scenarios which they could execute / check all the boxes, and to give them some accountability (i.e. it's not vague As an example, to label features at RMRK as tested, this could be the bare minimum user should do:
Obviously, there are more features to be tested, some of them take a lot of time to process (I've tried emotes, and it takes a while until it shows up in app):
And then there are tests which would require the tester to have multiple wallets, such as
Couple more ideas:
Actionable steps from here to get this started:
Last thought: PRs will probably require various levels of testing given the complexity of the code added/changed (i.e., simple CSS changes won't require as much testing as adding new /route etc.) We could perhaps differentiate this with the reward amount, and the dev responsible for the PR could select in PR template what kind of tests would he/she consider sufficient for given code. (some scale could be here, which would be also reflected/described in |
Beta Was this translation helpful? Give feedback.
-
I haven't read the upper comment yet, will fetch it soon, just wanted post this here, keep discussion on hey, quick update about qa-guild, it's still in testing so let's see how it's plays out I've added qa-guild to codeowners, so goal is to be for pull request, there will be Goal of This would help us offload When someone from QA-Guild tests the stuff, it can add there label works-for-me which we have at least one data point that it has worked for someone and it's good to go for release. Current members to QA-Guild I've added @petersopko#3803 and @clairee | #6505 |
Beta Was this translation helpful? Give feedback.
-
@petersopko can help make the dev-tools manual if it's not already in a comment, probably adding recorded video how-to tools into our documentation, so it's easily for new qa-guild members for future cases |
Beta Was this translation helpful? Give feedback.
-
Yesterday as I was observing that's reviewing PR can get quite complex, especially we are heading to multichain world with more integrations.
Seems to me, sometimes happened that code might look ok, happened few times functionality wasn't much there or thing wasn't working well or knocked off something elsewhere.
In first, we don't have much tests, except one major which tells you this code builds without errors, so this is quite bearable and comes naturally this is happening.
I was thinking to create separate guild
for those who would like help us going through functionality on QA basis who would bit add label it was tested and all good.
Of course it's experimental
so I can't tell if we will stick with is it or it will change something else, but I have high hopes that it could take off load from usual code review guild, which could focus on code quality and mitigate upcoming technical debt.
Who can be part of QA guild?
I bet anyone who previously reported some bug issue to our repository, is part of our KodaDot ambassadors program or would like to participate in our development cycle in long-term as knowing overview our functionality requires bit of general knowledge of feature sets and brief overview of upcoming issues, reported bugs and what's already reported, be gonna fixed &c
What's would be payroll for this?
I was thinking to start something on $20 ber PR and we can go from here to see if it's working for you.
Let me know thoughts and opinions, how we can raise our product quality within our current process, adjustments we should take &c, happy to explore and incorporate some good verified flows, I'm learning on this page as well and can tell this would helps us even of costs bit slows our dev cycle.
Why?
I sense that's when we start putting attention to some component, often happened that's at same code block we had 3 PRs, One fixed bug. Other breaks fix. Third fixed it tho. Thus I would be happy have dedicated pair of eyes or perspective which can in terms of context switching helps mitigate us this burden as I realizing code complexity we have and we are still iterating without traditional structure in place.
Label
I've created a dedicated QA guild team
I've created a label when the user has tested PR can add this label to PR
Beta Was this translation helpful? Give feedback.
All reactions