It is important to know when a product includes all of the desired features and is ready for release. Sometimes, this can lead to spending excessive time perfecting it only to realize that the extra time spend on such perfection might not have been worth the effort. The longer time is spent perfecting a product for release may result in missed sales opportunities.
Insisting on releasing perfect products can lead to frustration and disappointment because there is no such as a perfect product. The common cliche that you “can satisfy some people some of the time, but you cannot satisfy everybody all of the time” consistently holds true. When choosing which features to include in a product, one must consider the time and effort required to implement it in exchange for the increased (or lack thereof) sales that results from it.
During the finalization of a product there will always be tweaking involved based on both internal testing and possibly from external beta testers. However, as each new product is released you will gain experience to know when to stop making adjustments and when to just finish creating the product so it can be marketed.
Knowing when to stop perfecting is important for both product development as well as individual projects even when the project does not originate from you. External requests, sometimes referred to as contract work, will have strict deadlines and milestones that must be accomplished along the way which can all be reasonably satisfied without being “perfect”.
Functionality testing a new product or service before general release to the public is generally performed in two stages, alpha testing performed by the creator of the product and then beta testing by individuals most likely to use the product in the field. The primary reasons for functionality testing is to ensure that it satisfies the requirements of end users and also to come up with suggestions for future improvements.
Scripted objects are more likely to be functionality tested than non-scripted objects. Such testing requires that the product be utilized over and over again starting with individual testing of minor components (i.e. when odd symbols and excessive characters are submitted into the script does it respond appropriately or result in parsing and memory errors?) working up to the overall major characteristics of the solution such as generating the correct output when provided multiple variations of inputs. If a significant issue is discovered at the early stages these are usually resolved first before proceeding onto a later and larger stage. The testing process can very monotonous, yet is an important requirement.
The platform and viewer used to interact with and view the object is a circumstance that needs to be considered too as many still insist on using older viewers that may not be capable of rezzing sculpt and mesh objects nor respond appropriately to the latest and greatest scripting commands. Textures may not load as quickly as desired on computers with minimum hardware specifications and/or slow internet bandwidth speeds. Such limitations may either be addressed by the creator through either modification of the object or a mention in the notecard instructions that the viewer, hardware, and bandwidth must be meet certain requirements. In the latter case any identified glitches are indicated as “not a bug” and disregarded.
In the absence of external testers the creator can simulate much of the above by having multiple clients installed on multiple computers (i.e. desktop and laptop/netbook) as well as connections both hard-wired as well as wireless to vary the internet connection speeds. Alternate accounts can not only test for correct functionality, but can also be used to ensure the permission of objects and their contents (i.e. textures, notecards, scripts, animations, etc) appropriately protect the creator against theft while also allowing the user to customize or configure as required.