Author Topic: QA needed in the GUI deployment process  (Read 3564 times)

0 Members and 1 Guest are viewing this topic.

Offline fav

  • Hero Member
  • *****
  • Posts: 4278
  • No Pain, No Gain
    • View Profile
    • Follow Me!
  • BitShares: fav

Offline svk

I've pushed a fix for this but not sure when Valentine will update the server. The bug is related to a highcharts plugin that's only used in the price chart but tries to also apply itself to the depth chart. To avoid it until the fix is out, don't open the depth chart..
@svk @valzav, please update the server.
This critical bug is still there.
Valentine will push a new version later today. After this update we'll move to a qa process like you suggested where changes will be tested at bitshares.org/wallet before being pushed to OL.
Worker: dev.bitsharesblocks

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
All old version can be accesed via http://decentral.exchange .. let me ping the admin so that he updates the latest master .. there seems to be a manual step involved to initiate a recompile

jakub

  • Guest
I've pushed a fix for this but not sure when Valentine will update the server. The bug is related to a highcharts plugin that's only used in the price chart but tries to also apply itself to the depth chart. To avoid it until the fix is out, don't open the depth chart..
@svk @valzav, please update the server.
This critical bug is still there.

Offline CalabiYau

What I propose is introduce QA (Quality Assurance) in the GUI deployment process by making community testing an integral part of it.
We could implement it in these simple steps:
(1) A new GUI release is announced on the forum and then made available on a dedicated (non-public) URL.
(2) We test the upgraded GUI and give feedback about any new bugs found.
(3) Devs fix those new bugs.
(4) After all bugs are fixed and no new ones are found within the next 24 hours, the new release is deployed on Open Ledger.

 +5%

Offline noisy

Quote
Community testing should become part of the deployment cycle.
100% agree.

Quote
Tbh what we need is a testnet..

This is also true. We should be able to test all kind of scenarios without having to worry, that this will cost us a fee.

Next step would be to automate testing. And do not merge a Pull Request without all unittest pass, and do not release new version without all selenium tests passed. I could help with that.
Take a look on: https://bitsharestalk.org/index.php/topic,19625.msg251894.html - I have a crazy idea - lets convince cryptonomex developers to use livecoding.tv

Offline DestBest

What I propose is introduce QA (Quality Assurance) in the GUI deployment process by making community testing an integral part of it.
We could implement it in these simple steps:
(1) A new GUI release is announced on the forum and then made available on a dedicated (non-public) URL.
(2) We test the upgraded GUI and give feedback about any new bugs found.
(3) Devs fix those new bugs.
(4) After all bugs are fixed and no new ones are found within the next 24 hours, the new release is deployed on Open Ledger.
+5% and available for testing on win8
BitShares French ConneXion, le portail francophone BitShares.
BitShares French ConneXion, the BitShares french gateway.
www.bitsharesfcx.com

Offline GaltReport

Our current GUI deployment cycle looks like this:
(1) Without any prior notification the devs deploy a new release on Open Ledger (our only live platform).
(2) Community members who happen to find out about the upgrade report bugs introduced with the new release.
(3) Devs fix the new bugs and if the bugs are critical they make an emergency redeployment.

IMO such workflow is unacceptable at this stage.
We are live (no longer beta) and aim to be treated seriously.
It's a very bad practice to deploy a new GUI release without several people testing it first in different configurations.

What I propose is introduce QA (Quality Assurance) in the GUI deployment process by making community testing an integral part of it.
We could implement it in these simple steps:
(1) A new GUI release is announced on the forum and then made available on a dedicated (non-public) URL.
(2) We test the upgraded GUI and give feedback about any new bugs found.
(3) Devs fix those new bugs.
(4) After all bugs are fixed and no new ones are found within the next 24 hours, the new release is deployed on Open Ledger.

And just to make it clear - I'm not upset about bugs occurring, as this is normal when code gets upgraded.
What I'm upset about is that we could easily protect normal users from being exposed to those bugs and yet we don't do it.

We definitely need to be more careful about these things.
This is the time when this GUI is being showcased in business meetings and it needs to work without any new unexpected bugs or issues.
Otherwise we risk making fools of ourselves in those crucial meetings.

 +5% - Starting to get frustrating again having to reload...butttons don't work...works different in different browsers.  You need some sort of formal QA process.

jakub

  • Guest
Yea totally, it's very fast and furious atm since we're trying to add and fix as much stuff as possible as fast as possible, but it would probably be best if we move to a fixed release schedule with time for qa in between releases asap.

Could we use https://bitshares.org/wallet/ for QA community testing?
As far as I know, this URL is not currently advertised as an official BTS 2.0 platform so it can safely be used for QA.
In this case the only modification of the current process would be you deploying to bitshares.org/wallet first and then if nothing comes up during the next 24h deploy it to Open Ledger.

Offline cass

  • Hero Member
  • *****
  • Posts: 4311
  • /(┬.┬)\
    • View Profile
Yea totally, it's very fast and furious atm since we're trying to add and fix as much stuff as possible as fast as possible, but it would probably be best if we move to a fixed release schedule with time for qa in between releases asap.

 +5%

https://www.zenhub.io/open-source
█║▌║║█  - - -  The quieter you become, the more you are able to hear  - - -  █║▌║║█

Offline clayop

  • Hero Member
  • *****
  • Posts: 2033
    • View Profile
    • Bitshares Korea
  • BitShares: clayop
The loading problem I have is also related to the depth chart.
Bitshares Korea - http://www.bitshares.kr
Vote for me and see Korean Bitshares community grows
delegate-clayop

Offline svk

Yea totally, it's very fast and furious atm since we're trying to add and fix as much stuff as possible as fast as possible, but it would probably be best if we move to a fixed release schedule with time for qa in between releases asap.
Worker: dev.bitsharesblocks

jakub

  • Guest
I've pushed a fix for this but not sure when Valentine will update the server. The bug is related to a highcharts plugin that's only used in the price chart but tries to also apply itself to the depth chart. To avoid it until the fix is out, don't open the depth chart..

Tbh what we need is a testnet..

Thanks, svk. I can see you work hard, even during weekends.

But do you agree that we need to coordinate those upgrades in a more orderly manner?
Or at the very least announce those upgrades on the forum so that we know when a new wave of bugs can be expected and prepare ourselves for that.
I'm having a series of business meetings next week where I intend to present the GUI and if something like this happens during those meetings, it can ruin my plans.

Offline svk

I've pushed a fix for this but not sure when Valentine will update the server. The bug is related to a highcharts plugin that's only used in the price chart but tries to also apply itself to the depth chart. To avoid it until the fix is out, don't open the depth chart..

Tbh what we need is a testnet..
Worker: dev.bitsharesblocks

jakub

  • Guest
i noticed that i can not change into "Dashboard, Explore, Trad, Transfer" i have to reload again. Maybe this is the crash you talked about?

Yes, that's the symptom that the js code has crashed.
You should see the errors once you open the js console in chrome.

Anyway, it might be the case that this particular issue is dependent on some other settings - I cannot recreate it on a different Win 7 machine.

But whatever it is in this case, it even enforces my point - we cannot rely on the devs testing the GUI before releasing it as they are not able to simulate all the different configurations.
Community testing should become part of the deployment cycle.
« Last Edit: October 31, 2015, 08:50:43 pm by jakub »