1. Initial Phase1.0 The beginning of any software project is based on aprevious analysis of the problem and its formula for a possiblesolution. This solution is written through a proposal developedmost of the time by the CEO.
2. Requirements Specification PhaseIn Specification Requirements Phase, the needs of end usersof software are analyzed in order to determine whatobjectives should be covered. It requires skills from theanalyst to recognize incomplete, ambiguous orcontradictory requirements.
2. Requirements Specification Phase2.0 User Stories must provide and facilitate the requirementsmanagement. They may capture the who, what and why of arequirement in a simple and precise way. User stories are written byor for the business user as users 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 userstories are captured. For certain projects, if the customer doesntprovide 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 thesystem 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 bedeveloped in the Sprint, a ticket must be created for eachone. If the User Story and / or Use Case is too large, it maybe divided into several tickets considering that they must beassociated with the original Unfuddle
3 Analysis and design phase3.0 When you finish a sprint, QA starts designing test cases tobe executed in the next Sprint (before starting theconstruction of the system code). It is important to keepthem updated during the rest of the phases of the project.
4 Development phaseAgile processes are a re-evaluation of the way software iscreated. The quality of the source code is much more importantthan you may think. Just because customers dont see codedoesnt mean we are excused from the effort needed to beready for changes by keeping quality up, complexity down, andfull test coverage. Source from: http://www.agile-process.org/change.html
5 Testing phase5.1 When a QA finds a bug that is beyond the scope of a review, it isconducted to a ticket in Unfuddle on issues not related to this. Then PL isnotified so he can decide whether to create a new ticket to correct theerror in the next sprint. In addition we recommend using the format bugs toknow the status of the errors, ie, if it were created, are pending to beconfirmed, or simply if they have not received a response from the PL orPM.5.2 When a bug is found, you must make a comment on Unfuddle thatdescribes the path of reproduction and relevant information as to whichserver, browser, et al. We recommend using the bug format designedand attach evidence with videos or screenshots.
I. Control of changes on Unfuddle - Customer, PL,QAThe reports functionality on Unfuddle can be focus to generatetraceability reports that will indicate the coverture of the testsperformed by the QAs. But it is useful to know that these canbe generated with different purposes too.II. Milestones creation, Sprint planning and BacklogUpdate- PLBasic development cycle of the SCRUM which is equivalentto one Iteration or Milestone; during which the team works totransform a Ticket Backlog requirement into a projectincrease.At the end of each Sprint, the team must present progresswith functional features for the client.
III. Control of Changesa. 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 possiblec. Update the Milestone changes on Unfuddle.d. Tracking evolution change.