4. 1. Initial Phase
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.
5. 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.
6. 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 the
functionality 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 provided
information.
7. 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.
8. 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
9. 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.
10. 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
11. 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.
12. 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.
13. 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.
