QA Process

during Software

Lifecycle

1.0 The beginning of any software project is based on a

previous analysis of the problem and its formula for a possible

solution. This solution is written through a proposal developed

most of the time by the CEO.

1. Initial Phase

2. Requirements Specification Phase

In Specification Requirements Phase, the needs of end users

of software are analyzed in order to determine what

objectives should be covered. It requires skills from the

analyst to recognize incomplete, ambiguous or

contradictory requirements.

2. Requirements Specification Phase

2.0 User Stories must provide and facilitate the requirements

management. They may capture the 'who', 'what' and 'why' of a

requirement in a simple and precise way. User stories are written by

or for the business user as user's primary way to influence thefunctionality of the system being developed.

User stories may also be written by developers to express non-

functional requirements (security, performance, quality, etc.),though primarily it is the task of a product manager to ensure user

stories are captured. For certain projects, if the customer doesn't

provide them, the QA should create them based on the providedinformation.

2.1 A use case is a description of the steps or activities,

typically defined as interactions between an actor and the

system in order to comply with a functionality.

An actor may be a human or an external system.

2.2 From the user stories and / or User Cases selected to be

developed in the Sprint, a ticket must be created for each

one. If the User Story and / or Use Case is too large, it may

be divided into several tickets considering that they must be

associated with the original Unfuddle

3 Analysis and design phase

3.0 When you finish a sprint, QA starts designing test cases to

be executed in the next Sprint (before starting the

construction of the system code). It is important to keep

them updated during the rest of the phases of the project.

4 Development phase

Agile processes are a re-evaluation of the way software is

created. The quality of the source code is much more important

than you may think. Just because customers don't see code

doesn't mean we are excused from the effort needed to be

ready for changes by keeping quality up, complexity down, and

full test coverage. Source from: http://www.agile-process.org/change.html

5 Testing phase

5.1 When a QA finds a bug that is beyond the scope of a review, it is

conducted to a ticket in Unfuddle on issues not related to this. Then PL is

notified so he can decide whether to create a new ticket to correct the

error in the next sprint. In addition we recommend using the format bugs to

know the status of the errors, ie, if it were created, are pending to be

confirmed, or simply if they have not received a response from the PL or

PM.

5.2 When a bug is found, you must make a comment on Unfuddle that

describes the path of reproduction and relevant information as to which

server, browser, et al. We recommend using the bug format designed

and attach evidence with videos or screenshots.

I. Control of changes on Unfuddle - Customer, PL,

QA

The reports functionality on Unfuddle can be focus to generate

traceability reports that will indicate the coverture of the tests

performed by the QAs. But it is useful to know that these can

be generated with different purposes too.

II. Milestones creation, Sprint planning and Backlog

Update- PL

Basic development cycle of the SCRUM which is equivalent

to one Iteration or Milestone; during which the team works to

transform a Ticket Backlog requirement into a project

increase.

At the end of each Sprint, the team must present progress

with functional features for the client.

III. Control of Changes

a. Registration of the change of the ticket belonging to

the backlog . If it is necessary, create a new one.

b. Remove as many approvals as possible

c. Update the Milestone changes on Unfuddle.

d. Tracking evolution change.