5 Replies Latest reply on Mar 2, 2017 3:12 AM by globe11123

    Best practise for testing scripts / developments


      I've made myself a little development module within our system so that our employee's can make development requests or ask for changes to be made within the system.


      Currently I am making an instant backup from Filemaker server and copying that solution which is the quickest method of testing the live database without messing with live data.


      I've found that many of the changes I've made aren't being fully tested enough (more of a gung-ho method of getting stuck into the problem rather than checking what the consequences of making the changes are) which then is creating more work for me to re-look at the request/change and redo it.


      Whats the best practise for testing any developments made?

      Is there any better methods than just taking backups all the time?

        • 1. Re: Best practise for testing scripts / developments

          Instead of working on n dev requests at a time, concentrate on just one of them and keep hammering on it till it satisfies users. Then move to the next one. While waiting for user feedback, google "scrum".

          2 of 2 people found this helpful
          • 2. Re: Best practise for testing scripts / developments

            "Smoke testing" as it's sometimes referred to in software development, is crucial prior to deployment to production. Without really "hammering" as siplus in the development environment and then monitoring it carefully in production, one risks facing cascading issues which are difficult to sort out. I try to educate my clients/users of the importance of only adding significant features or functionalities in controlled steps. By providing them with an easy feedback tool they seem to understand and don't mind the confinements of reality.

            • 3. Re: Best practise for testing scripts / developments

              It is just as important to manage and document the script changes you make is it is to test them in advance before installing the change into the live system.


              I do the following once I am ready to "go live" with a script change:

              We have a "documentation block" at the head of every script that summarizes what it does and which developer created the script. A "modified by" section lists each change made, when and by whom.

              If the change is relatively "small" that rewrites just a portion of the code, Encapsulate the changed code like this:

              #3/1/17 Phil Begin change

              new code here

              //Disabled Old Code here

              #3/1/17 Phil End change


              Thus, if a problem is identified, we can quickly disable the new code, enable the old and thus "revert" the script to its previous version if we discover that it is not working as intended. After about a month, The Begin/end comments and disabled lines are considered OK to remove in order to keep down the clutter.


              If the change is more complex and we have extensively rewritten a script, we first duplicate the old version and add text such as "BU delete after 4/1/17" to the end of the duplicated script. If we find that we have to revert to the previous script, we can copy and paste all scripts from this back up back into the original script after deleting all lines of code from the original.

              1 of 1 people found this helpful
              • 4. Re: Best practise for testing scripts / developments

                Another good idea is to work on a version which has twice the data your oldest clients have. In our case we have about 1'000'000 invoice lines, 100'000 appointments and so on in the development version. Backups are bigger, of course, but you can immediately tell if something suggested to you will become a big problem in some years from now, when data will grow.

                1 of 1 people found this helpful
                • 5. Re: Best practise for testing scripts / developments

                  Thanks for the suggestions guys


                  From reviewing whats been said I've upgraded my development module so that I have a process similar to the SCRUM process siplus mentioned. Going to now put a header on all new scripts which I should of been doing ages ago! Also going to put more emphasis on the testing stage before anything gets put live.


                  Created a cool visual aid with portals based upon SCRUM. Clicking into the mini-sticky note takes you to that task.

                  Might filter Complete to only show completed tasks within a weeks range.


                  Screen Shot 2017-03-02 at 11.10.53.png