Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
{div:style=} {panel:borderStyle=solid|borderColor=#ddd|bgColor=#fbfbfb} h2. QA Section: Contents {pagetree:root=@self|sort=natural} \\ h2. On this page: {toc:exclude=Contents,On this page|includePages=true} \\ {panel} {div}
Div
Wiki Markup
style
width:350px;overflow:hidden;float:left;
Panel
borderColor#ddd
bgColor#fbfbfb
borderStylesolid

QA Section: Contents

Page Tree
root@self
sortnatural


On this page:

Table of Contents
includePagestrue
excludeContents|On this page


{div:style=
Div
Wiki Markup
style
overflow:auto;margin-left:10px;min-height:600px;
} h2.

Thalia's

QA

Schedule

First

half

of

each

Thalia

sprint

is

devoted

to

development.

QA

uses

this

time

to

write

test

plans

and

test

cases

to

cover

new

functionality,

and

perform

testing

on

fixed

bugs

and

new

features

as

they

are

released

to

the

staging

platform.

Bug

reports

are

converted

to

new

test

cases,

as

they

indicate

an

area

that

needs

coverage.

The

second

half

of

each

Thalia

sprint

is

the

QA

phase.

When

the

candidate

build

has

been

put

up

on

the

staging

platform,

QA

begins

regression

testing

to

confirm

that

all

functionality

still

works

as

expected.

h3. _Development Phase_ *As each build is released to QA:* * Smoke test to confirm integrity of basic functionality: \- test create, view, update, and delete of all components    * Verify and close defect fixes with each new build: \- Close fixed JIRA issues \- Reopen JIRA issues as needed. \- Write additional test cases for new bugs. * Test new functionality: \- Open JIRA issues as needed. \- Write test cases for new functionality. h3. _QA Phase_ *When final candidate build is released to QA:* * Initial smoke test of major functionality. * Regression test - hunting for bugs in previously working areas (use test cases to guide this; log results in the test log). * Re-test bugs fixed during the current sprint - make sure they are still fixed. * Open new JIRA issues as requiredExploratory testing - find creative new ways Thalia can go wrong. {div}

Development Phase

As each build is released to QA:

  • Smoke test to confirm integrity of basic functionality:
    - test create, view, update, and delete of all components   
  • Verify and close defect fixes with each new build:
    - Close fixed JIRA issues
    - Reopen JIRA issues as needed.
    - Write additional test cases for new bugs.
  • Test new functionality:
    - Open JIRA issues as needed.
    - Write test cases for new functionality.

QA Phase

When final candidate build is released to QA:

  • Initial smoke test of major functionality.
  • Regression test - hunting for bugs in previously working areas (use test cases to guide this; log results in the test log).
  • Re-test bugs fixed during the current sprint - make sure they are still fixed.
  • Open new JIRA issues as requiredExploratory testing - find creative new ways Thalia can go wrong.

Acceptance of the Release

...

Test plans change with each version of the product.  They also provide documentation about product functionality which would help a new programmer or tech writer ramp up. This makes it as important to keep test plans in a versioned, central location with the code.  Thalia's QA plans may be found with the code in SVN at svn+ssh://svn.mit.edu/zest/thalia/qa  . You must have access to SVN to access the repository.
 

{div} {}
Wiki Markup
Div