QA PROCESS

Release to QA:

A new release to QA should be:

- accompanied with an email/txt file/readme file that contains (preferably release notes):

1.      the new features that have been added and what modules/functionalities  they do impact

2.      the bugs that are fixed with their number in Jira, what modules are impacted by the changes made

3.      the area to focus on if there is one

- An identified software version (in the form of software checked out of SVN or CVS or at least something with a version number that we can refer to)

Test Cases

-         The test cases should be based on specifications.

Unfortunately today they are not but this should be solved at some point for matters of efficiency and time saving.

On IAMSuite today the TC are based on the product and its evolution/behavior.

The specifications should be written with the QA person. If you are in the beginning of your project (or even if not), consider writing at least a minimal spec, we could discuss that at anytime if you want, just let me know.

-         The test cases will be created according to this format:

-         The test name is an indication of the project and the test itself.

Ex:

TC_group_delete _noSubGr_01: meaning we are in the groups, we want to delete, and there is no subgroup. The number is for different set of attributes/set of data if there are several.

Test Results

The test results will be displayed on a test report with the version of the software:

-         Includes bugs created

-         TC that have been done

-         TC passed and failed

-         %passed and %failed

Defect Reporting  and Bug life cycle:

-         Defects will be reported using JIRA

-         The bug entered by a QA has this life cycle:

- Bug created in Jira and assigned to a developer, the status is open

- An email is sent to the developer so he is aware of the bug

- When the developer works on the bug and fixes it, he changes its status to resolved/won't be resolved if for any reason we decide to do not fix it or we can't

- The QA receive a notification of change of status

- The QA test the resolution of the bug on the new release of the software, if everything is fine the QA passes it to close it if not it goes back to the open state.

The bugs will be retested only if the QA have been aware of a modification/resolution (there will be no review of all the bugs to make sure they still exist)

The bugs should be closed only by the QA person.

Terminology and Versioning:

• A release to QA might be known as "alpha x" or "beta y" and ultimately "Final candidate".

Alpha release

- Not complete functionality, but some functionality working

- So remaining work involves adding new features

Beta release

- complete functionality, fully tested (i.e. all test cases run at least once), defect situation known with a set of defects identified as need to be fixed, others OK not to fix).

- So remaining development work is debugging, not adding new features.

Final Candidate

- When developers have resolved all the bugs, and expect this QA cycle to be the last (which it might not be as QA might find another problem introduced).

• Version numbering format should be <major release>.<minor release>.<update number>

The essential/Summary:

-         Testing must be on an identified software version,

-         No modification is done and no reinstallation is done unless the tests are stopped and a new version is installed, this is track regressions.

-         New installation means a new version.

-         With the new installation come a paper or email containing the modifications made and the added features.

-         The bugs are logged in Jira and are to be closed only by the test team.