QA Requests To Staff

Quality Assurance Design Concept
There are four Goals that Quality Assurance tries to achieve:


 * Making sure that there are enough available sources of information to use
 * Making sure that the sources gathered are as accurate as possible
 * Making sure that the feature being implemented is working on the server as intended
 * Addressing player questions over the status of feature implementations

I'd like the cooperation of the staff on four things to help QA achieve these goals; One is related to research and information gathering;the second parts are related to comparing and validating sources of data; the third part is related to feature implementation validation and the fourth and final part is related to handling player questions about various features.

A. Research Collaboration
When a programmer or world build staff member adds a change where they have had to make up values or guess at proper feature behavior without having any data that supports that decision, then there needs to be made some acknowledgement that guess work was included in the implementation of that feature. Instead of just implementing a change with guessed values and behavior, I'd like for you to inform Quality Assurance whenever you feel that you have insufficient information on a topic. It greatly lessens the chance that incorrect feature behavior will be spotted or dealt with if staff members do not report when insufficient information is available or when "guessed behavior" is introduced.

This request could be posted on the forum with the issue needing research as the topic and any relevant details about what problems have been encountered included in the body. Doing this would allow QA the opportunity to assist with feature implementation through fact checking and acquiring any necessary data and then responding to the request with that data (if available).

B. Fact Checking
QA should have Access to the information sources or testing data used by the staff when implementing any feature, upon the request of QA personnel. The same could be asked of QA from the uthgard staff. If QA has any helpful information, it will be shared with the uthgard staff. Sharing information would allow both groups to better fact check to make sure data is accurate and also compare notes to fill in missing data about how features function.

C. Custom Changes & Feature Validation
There are 3 important things here that I believe should be handled in a particular order:


 * Defining custom changes
 * Defining live-like status and how this relates to custom changes
 * Informing QA about custom changes

Without addressing these three issues, QA cannot achieve total effectiveness with determining if feature implementations are operating correctly.

I have some Ideal (from the QA perspective) recommendations for how to define custom changes and live-like behavior here:

http://uthgard.wikia.com/wiki/Custom_Changes

Defining custom changes - It is important to come to some consensus and conclusion about what is perceived to be a custom change from the QA point of view and from the staff point of view as this greatly affects what information that the staff can/will provide to QA about intended behaviors of game features on the server.

Defining Live-like status - It is important to come to some consensus and conclusion about what is perceived to be live-like from the QA point of view and from the staff point of view as this also affects what information that the staff can/will provided to QA about intended behaviors of game features on the server.

Informing QA about custom changes - I'd like for myself or my successors to be notified when a custom change is being included into the server and explaining the intended purpose of it and the rationale behind why it was thought necessary. It is important that QA are made aware of what the intended behavior is for features on the server for a number of practical reasons:


 * Knowing what the intended purpose and function of the custom change would allow QA to test and observe if this feature is serving its purpose in game or if it is causing any undesirable side effects and problems.


 * Knowing what the intended purpose and function of the custom change would allow QA to not spend time following up leads and testing customly changed features under the impression that the feature is "bugged" or improperly implemented. This is a serious drawback of the current situation where in the past, a lot of time has been spent tracking down perceived bugs only to find out that their behavior is intended by staff members.

In short, This time spent on figuring out what is custom/intended is better spent testing other features and can be resolved with simply just informing QA of what is being implemented to be custom.

D. Questions & Answers
QA will help to channel player questions about various aspects of feature design and implementation on uthgard in a more orderly manner than what has traditionally been used on the forums. For a design concept on this, see:

http://uthgard.wikia.com/wiki/Questions_And_Answers

This process will not be intended to replace players bug reporting or offering their own opinions on issues using the forum. Staff involvement in this would simply be to answer submitted questions for the 3 categories (up to 10 questions for each category). The questions would be tallied weekly and sent in to be answered and the entire month's worth of questions would be archived by month and year. Questions would be also filtered out by QA to make sure that questions that have already been answered are not submitted to staff members.

Responses from the staff would also be used to help fill in missing information in the other areas of the site such as for the status and reasons behind unimplemented features, incorrectly implemented features and custom changes. Another benefit to this from a Quality Assurance perspective would be that questions submitted by the player base can potentially highlight areas where QA can improve on such as bringing up unforeseen issues about game features which may have been overlooked and not addressed by QA or staff members.