Web Analytics Made Easy -
StatCounter Beta Testing - Proper Management - My Plan - CodingForum


No announcement yet.

Beta Testing - Proper Management - My Plan

  • Filter
  • Time
  • Show
Clear All
new posts

  • Beta Testing - Proper Management - My Plan

    I have done beta testing before but this is my first very large project. Also this one i am not only a developer but i am the only developer, on top of that i am also the owner, so it all falls on me. Some might say that its better to have fewer people build a project because there is more micro management and overall control. On the other hand no one person (or a few) can possibly think of everything. So on one hand i want perfection and on the other hand i know ill never have it and all i can do is just do the best i can to get the largest challenges as right as i possibly can.

    Now when the time comes for beta testing, i wanted to get some fundamentals down in my mind of not only how to do it correctly, but what to focus on and also trying to sidestep some common pitfalls. Placing anything in the hands of testers that most likely dont follow your same logic can really expose the weakest links and/or even the greatest strengths, its best to hope for both.

    But here are just a few thoughts about what to expect going into it and what not to panic over.

    1. The most obvious but the hardest to accept is that "there will be bugs" and it will not be as perfect as you thought it was.

    2. This time i will have the beta testers test one feature at a time from different access points, then move to the next feature. Then at the end of that process, ask them to give it a full cycle test, just as some extra insurance.

    3. The plan is to limit the number of beta testers to less than 20. First of all 20 testers is much easier to find than 100 for example. It is also much easier to manage the feedback data and easire to build rapport with each tester so you know if they are attention to detail type or just going through the motions.

    4. The beta testers will share very different skill sets, some with no computer experience, and some with alot of experience. The same goes for ecommerce experience, some with, and some with zero experience. The people with more computer experience ie coders, may test for vulnerabilities as well.

    5. There needs to be 3 types of feedback issues including 'critical', 'important', and 'todo list' items. The critical items are the issues that need to be fixed now before official release, the important items are those things that need to be addressed right after release and fixed in next version, and todo list items are those that can be done as time allows and may take several versions to get the correction in place.

    6. Beta testing will last between 30 and 60 days and must include all of the following. Errors, warnings, notices, grammar, functionality, user friendlyness, instructions, performance, server resource footprint, visual appeal.

    In closing, the bottom line to remember is that beta testing may bring out issues but that is why we do it. It is better to find issues now and address them before release, than have to fix things under the gun when you have users pressuring you to do so. So remember that it is a good thing.. dont get butt hurt....
    Last edited by durangod; Jun 29, 2020, 06:35 PM.
    If a php file only has php code within it you do not need to use the closing php tag
    A good way to remember objects from arrays is you shoot objects with arrows Example: $name->id; then Arrays are $name['id'];
    durangod is short for durango dave

  • #2
    Your "plan" is missing one of the most important parts of software development....Code Review.
    To save time, lets just assume I am almost never wrong.

    The XY Problem
    The XY problem is asking about your attempted solution (X) rather than your actual problem (Y). This leads to enormous amounts of wasted time and energy, both on the part of people asking for help, and on the part of those providing help.

    Make A Donation https://www.paypal.me/KevinRubio


    • #3
      That is a great point ben, i am glad you brought it up. I left it out on purpose only because i did not want to get bogged down in symantics during the BETA testing. There is a time for that i 100% agree, but that time IMO comes after users testing, there are several reasons i believe that.

      1. Much of the time coders cant agree on how to do anything, one always wants to outdo the other one and so they bicker and compete over petty differences.

      2. When number 1 above happens then the release date stalls and we end up chasing our tails trying to find a way to get back to good ground and then do it all over again...

      3. I know the code is sound. But what i dont know is how my logical visual process will be seen by others. This will make the project user friendly or not. At the moment this is more important to me than drudging over code when IMO BETA testing is about user experience and project performance, not "i would have done this in a function" or "why did you use ( on your include_once code", petty stuff that does not need to be done until after the users experience. The users experience will make or break the project, if it passes that phase then it is time to put the visual code to the test. The BETA testing will decide if this is marketable. It makes no sense to have great code if what you have is not marketable to users.

      4. After users experience, changes will certainly need to be made to meet the needs and desires of the user, this needs tohappen after that experience and before code review. We need that dataset first.

      5. After the BETA testing and user experience is done, and it gets good marks, then i can either submit the script to a professional security company to test it, or find an open source volunteer solution to code review.

      Then it will be time for release and most importantly, ready for release..

      Last edited by durangod; Jun 30, 2020, 02:02 AM.
      If a php file only has php code within it you do not need to use the closing php tag
      A good way to remember objects from arrays is you shoot objects with arrows Example: $name->id; then Arrays are $name['id'];
      durangod is short for durango dave