Shadowrun: Awakened Forums Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
 
  Site Forums   Wiki   Bugs Tasks Code FAQ Docs Help Register  
    Page   Discussion         View source History  

Quality assurance

From Shadowrun: Awakened

Jump to: navigation, search

Quality Assurance, or QA, is any activity that attempts to ensure that a product or system is designed, developed, and implemented in an efficient and effective manner. At a high level, it seeks to double-check the work of developers to reduce risk and assure the project that it is producing highly functional software. Most people believe that QA is synonym with testing, but in reality it is much more. It can be comprised by policies, processes, or procedures, and its main objective is that, at the end of a development cycle, the end-product meets the quality standards set by the organization.

Contents

Quality Assurance in Shadowrun: Awakened

Here you will find the activities that should be carried out by Quality Assurance during the development process of Shadowrun Awakened. Working on this project shouldn’t be done under the assumption that because it will be a free MMORPG, people will put up with any bug or unfriendly feature. People expect AAA quality games regardless of the source.

Quality Factors

Quality is a goal pursued throughout the project. The following steps in development are not absolute and we should try to be agile in our thinking. However, activities will likely fall into at least one of these categories and herein are some intended guidance during each:

Planning

Before and during the build process, plans must be compiled, requirements tracked, and contingencies examined. Key factors in assuring excellence during planning includes:

  • Use the Roadmap to define scope for your current work.
  • Use the Jobs tracker to enumerate the tasks identified for building.
  • Contributors should discuss and premeditate about ideas with relevant other developers before pursuing them. This will cut down on repeated work and ensure all
  • Contributors should prototype when appropriate to test ideas and educate themselves using a hands-on approach.
  • Contributors should resist the automatic conversion of a working prototype into the basis for a new product. Often, prototypes sacrificed thoughtful architecture for speedy delivery. Pull them apart and find the useful chunks that represent your critical learning, then throw away the rest to avoid bad engineering by osmosis.

Building

When modeling, coding, or writing, it's important to keep in mind:

  • Follow the plan and focus on the big picture. For the most part, our preparations should be sufficient and sticking to them will ensure you're working instep with other contributors.
  • When you notice something we did not plan for or see a problem with the current direction, blow the whistle! You might be the only person who sees the problem and everyone should be interested in having as few problems as possible.
  • Programmers should follow the Coding Standard and artists the Asset style article. Creating consistency in our work products will make them easer to learn for others and to maintain for us.
  • Use version control to track all work where appropriate. Not only does this automatically handle concurrent developers, it also keeps the outside world apprised of our progress and enables outsiders to look at the code and start helping.
  • Follow the Jobs in the job tracker and use them as your primary checklist for progress.

Testing

Testing can mean verifying code, examining a model, or editing a mission.

  • The jobs tracker's completed tasks should each be tested individually to ensure new features go through a full life-cycle of being designed, built, AND tested.
  • Noteworthy bugs found should be logged into the Bug Tracker using the standards defined in example 0000001. For further information read the Bug Tracker manual.
  • Bugs in the tracker should be addressed by contributors, then re-tested to absolutely verify they were fixed.

Operating

Once the servers are connecting players and the world is being

  • Referees, in-game administrators who deal directly with users, will be a rarity in SRA given that we can't afford to hire them. However, we will likely have admin-level players in the game who can help fix most problems. We must empower them with necessary features and ensure they present a good face for the organization.
  • An emphasis on recovery in the face of system failure should be pursued at each level, ensuring we maintain reliability. Backups should be made periodically.
  • To foster continual improvement based on verifiable needs of the community, a system of reporting current and historic activity in the project should be utilized to make future decisions in directed based on facts.