Do you have or provide a suite of tests to confirm all VB Connect 5.5.0 features work ffrom web browsers?

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • purple_enigma
    New Member
    • Mar 2019
    • 5
    • 5.3.x

    Do you have or provide a suite of tests to confirm all VB Connect 5.5.0 features work ffrom web browsers?

    Does your SVT team have some kind of software that completes tests against new releases of VB Connect, to confirm things previously broken and fixed, would not be broken in a new release? Maybe some sort of collection of tests done with "curl" , perl or python or some other command-line tools, which login, post, reply, and test all the user requests services of your forum software?

    Is this something VB customers can acquire?

    If you do not have something like this, or you do not make it available to customers, do you know of anyone that has created such scripts for testing VB Connect 5.5.x?

    (I'm not writing about the "do-not-upload/*php" tools which can be used to validate the *server* side can run VB. I am asking about tests to validate client service, access and use with web browsers.)

    My goal is to have a collection of tools to run after upgrades, or installs, or changes to security features for browsers, and make sure there is no loss in functionality over those items tested.

    Thanks!
    -PE
  • In Omnibus
    Senior Member
    • Apr 2010
    • 2310

    #2
    This wouldn't serve much of a purpose since client side apps can and do change their API frequently and without notice.

    Even if you had a set of tools what works today might not work tomorrow.

    Comment

    • purple_enigma
      New Member
      • Mar 2019
      • 5
      • 5.3.x

      #3
      Originally posted by In Omnibus
      This wouldn't serve much of a purpose since client side apps can and do change their API frequently and without notice.

      Even if you had a set of tools what works today might not work tomorrow.
      I'm trying to understand you argument against my request:

      From your view, you expect web clients login to the forums to use them (the content provided for login, the client POST to login), post message, reply to message, upload images, create new blog entries, login to admincp, login to modcp are at high risk for changing from VB Connect 5.5.0 to VB Connect 5.5.1?

      Thanks if you can confirm I understand your arugment, and disinterest.

      -PE

      Comment

      • In Omnibus
        Senior Member
        • Apr 2010
        • 2310

        #4
        Originally posted by purple_enigma

        I'm trying to understand you argument against my request:

        From your view, you expect web clients login to the forums to use them (the content provided for login, the client POST to login), post message, reply to message, upload images, create new blog entries, login to admincp, login to modcp are at high risk for changing from VB Connect 5.5.0 to VB Connect 5.5.1?

        Thanks if you can confirm I understand your arugment, and disinterest.

        -PE
        Perhaps I misunderstood your question but it seemed you were inquiring as to the functionality of the software in each web browser. vBulletin would have no control over changes made to web browsers between their own testing and release of each software version. The recommended method of testing would be to keep a testing database for such purposes. Between the developers, the QA team, the support staff, and the Alpha / Beta test team the vast majority of issues are caught and resolved before the end user sees them. Certainly, it's improbable that every issue will be found before a version is released which is why the software is in continuous development. Minor upgrade releases tend to have no effect on the core functionality of the software.

        The best test of any software version is the use of that version in your specific environment. If tools existed for the testing of each web browser the developers would have to spend considerable time and effort developing and maintaining those tools instead of the software itself. It's far more logical to expect end users to test upgrade their forums and use the software as they do, which is different for each customer. There are simply too many usage variables between customers.

        My personal advice is to wait until there is feedback on any upgrade version before upgrading. A number of us run test sites or development sites or sites we're less concerned about having issues where we test new releases and report any issues we find. It would be highly unusual for there to be some functionality in a minor upgrade release that is so critical to a site that an upgrade cannot wait. Major release versions are those far more likely to cause issues with the core functionality of the software such as posting, replies, comments, images, blogs, and the other items you've specifically mentioned.

        Comment

        • purple_enigma
          New Member
          • Mar 2019
          • 5
          • 5.3.x

          #5
          Originally posted by In Omnibus
          Perhaps I misunderstood your question but it seemed you were inquiring as to the functionality of the software in each web browser. vBulletin would have no control over changes made to web browsers between their own testing and release of each software version. The recommended method of testing would be to keep a testing database for such purposes. Between the developers, the QA team, the support staff, and the Alpha / Beta test team the vast majority of issues are caught and resolved before the end user sees them. Certainly, it's improbable that every issue will be found before a version is released which is why the software is in continuous development. Minor upgrade releases tend to have no effect on the core functionality of the software.
          Though being able to test different web browser clients on different platform would be of interest, it is not the primary focus.

          Let me provide an example of how being able to test user functionality would be useful:
          * As a web admin, you want to test out variation on the HTTP header enhancement for web browsers to take extra steps to protect users from things like XSS , so you expore use of "Content-Security-Policy" in the header
          Which configuration will break VBulletin Connect software? Which will allow most services to work. Will any break the "click on admincp" link in logged-in session to launch new window/tab to login to the admincp or modcp? Maybe you decide to try "frame-src https://yoursite.example.com;" ? An automated scripted test may reveal that it breaks you youtube embedded link for video.

          * Maybe you want to experiment with a served HTTP header like 'Header set X-Content-Type-Options "nosniff"' : will that break upgrades?

          * What about "X-Permitted-Cross-Domain-Policies"

          * Maybe "X-Frame-Options"

          Which of these uncommon changes break which functions (if any) in VBulletin software? I'm pretty sure that any "unsupported configuration" will be literally, unsupported, meaning VBulletin support would not provide answer to questions about which configurations will work, which will break which things and which things will be broken. I'd just get a canned response like, "That is not a supported configuration" or "we do not know the consequences of attempting to use those feature." It is possible I might get lucky and get a response which indicates testing, but no details beyond, "we found enabling that feature harmed some functionality on VBulletin service."

          Having a suite of tools to test most common uses of the forums would allow for customer testing of service and function, to understand what would be lost with various features or settings, when enabled, or configured as desired, and if the owner of the site is interested in accepting the determined cost in lost functionality for the added security benefits to users that have browser which can take advantage of these extra (sometimes experimental) header items.

          Originally posted by In Omnibus
          The best test of any software version is the use of that version in your specific environment. If tools existed for the testing of each web browser the developers would have to spend considerable time and effort developing and maintaining those tools instead of the software itself. It's far more logical to expect end users to test upgrade their forums and use the software as they do, which is different for each customer. There are simply too many usage variables between customers.
          I recognize this. Devs and SVT for products are unable to test all possible use cases for all possible configs. Support cannot support all possible user cases and all possible configs. Both primarily support the most common use cases, with a narrow spectrum of environment (compared to all that is possible.) It is not profitable to chase down all corner cases to address things that maybe one customer might be interested in using.

          It is why I am not asking VB to test all of the things I would want to test, but instead ask if there are any tests that customers can acquire from VB devs or SVT so we can test features on our own. The alternative would be making my own suite of tests. If something exists, it saves me time. If there is nothing available, then I can build my own. I am guessing that exec to "curl" from CLI script or python with libraries should have enough of what I want to be able to test everything from login, save to cookie, and use cookie to test all of the other features, examine HTTP response codes, review content for validation to one of the HTML standards and review CSS for cases where admin edits to styles/templates might violate one of these, and then report it to us.

          It would be easier if this already existed and could be used by customers.

          Originally posted by In Omnibus
          My personal advice is to wait until there is feedback on any upgrade version before upgrading. A number of us run test sites or development sites or sites we're less concerned about having issues where we test new releases and report any issues we find. It would be highly unusual for there to be some functionality in a minor upgrade release that is so critical to a site that an upgrade cannot wait. Major release versions are those far more likely to cause issues with the core functionality of the software such as posting, replies, comments, images, blogs, and the other items you've specifically mentioned.
          Yes, that is something I have done in the past. Unless there is a security issue to make upgrade urgent, wait a week and then install later.

          So, back to the point. Do you know of any tools that can complete any of these kinds of tests specifically for VBulletin Connect 5.5.x , which are available to customers?

          Does anyone else know of tools for validating VBulletin Connect software?

          Also, thanks for the replies on this topic; it provided an opportunity to better describe the purpose with examples. Hopefully someone knows of a tool or collection of tools to help me with this goal.

          Thanks,
          -PE

          Comment

          • In Omnibus
            Senior Member
            • Apr 2010
            • 2310

            #6
            In short, no, I am not personally aware of any tools for these purposes. Maybe someone else is but no one else has weighed in on this issue as of yet.

            I can tell you that i have personally used content security policy code in the headinclude template without issue in the most recent version.

            Comment

            • Wayne Luke
              vBulletin Technical Support Lead
              • Aug 2000
              • 73981

              #7
              Requirements are listed here: https://www.vbulletin.com/forum/foru...m-requirements

              Different optional services that vBulletin hooks (Facebook, Google, Twitter, StopForumSpam, Recaptcha, Akisment, etc...) into may have their own requirements.



              We do not have a script to test every possible server configuration. You have to test your own servers. This is why we allow both a production and test/development installation of the software under a single license.
              Last edited by Wayne Luke; Mon 11 Mar '19, 9:21am.
              Translations provided by Google.

              Wayne Luke
              The Rabid Badger - a vBulletin Cloud demonstration site.
              vBulletin 5 API

              Comment

              • purple_enigma
                New Member
                • Mar 2019
                • 5
                • 5.3.x

                #8
                Originally posted by Wayne Luke
                Requirements are listed here: https://www.vbulletin.com/forum/foru...m-requirements

                Different optional services that vBulletin hooks (Facebook, Google, Twitter, StopForumSpam, Recaptcha, Akisment, etc...) into may have their own requirements.



                We do not have a script to test every possible server configuration. You have to test your own servers. This is why we allow both a production and test/development installation of the software under a single license.
                Thanks to both of you for the answer(s). I'll look to create my own tests.
                Cheers!

                -PE

                Comment

                widgetinstance 262 (Related Topics) skipped due to lack of content & hide_module_if_empty option.
                Working...