Easy Agile

Agile Bug Triage Meeting Definition: Bug Triage meeting is discussion and analyses for all open bug, and agenda of discussion is set the priority to team for which bug should take up first, classify the bug in different category, find the where team struggle to get help to debug RCA, if RCA is available then assign bug to right team, find the recreation step from reporter and severity of bug.                             Procedure: Generally, below procedure is followed for Bug Triage Meeting QA lead sends out a bug report with the new Bugs introduced since the last meeting. Product owner calls out a meeting. During the meeting, each Bug is analyzed to see whether correct priority and severity are assigned to it. Priority and severity are corrected if need be.   Bugs are discussed by the team. This involves discussing RCA, Dependen...

Business value should be demoed Positive working flow for story All test combination should be covered and tested All the Open issue should be demoed All the know behavior should be covered in demo Open issue and behavior should be approved by PM/PO

To help with this, our teams work with the PO to agree on what defines a “ready” state of a backlog item. This will vary by project, but below are some elements to seed the discussion: Story defined and written with details flow Acceptance criteria defined Dependencies identified and marked Size estimated by delivery team User experience included (where required) Performance criteria identified Test Risk identified and written  Team has a good idea about how to demo the user story

Code produced (all ‘to do’ items in code completed) Code commented, checked in and run against current version in source control Peer reviewed (or produced with pair programming) and meeting development standards Builds without errors Unit tests written and passing Deployed to system test environment and passed system tests Passed UAT (User Acceptance Testing) and signed off as meeting requirements Any build/deployment/configuration changes implemented/documented/communicated Relevant documentation/diagrams produced and/or updated Remaining hours for task set to zero and task closed

Agile Exploratory Testing  Exploratory testing not only helps us learn how a given product works. It also helps us understand priorities, define requirements, and test the most critical components of that product in the first order. The process is iterative, allowing one’s understanding to grow with each subsequent cycle. This process makes it easier to isolate and test the software’s core functionality. As software testers we have the choice of approaching our test subjects either ad hoc, scripted or in a more exploratory style. Based on the circumstances either of them may be a good choice to make and as a tester it is wise to be able to use them all when context calls for them. Even so especially in agile the better choice seems to be to do exploratory testing. Like the agile approaches exploratory testing is natural way aimed at adding business value.  

The Agile Team is Responsible for Quality that Improves Quality Better Communication between team Defects are Easy to Fix Flexibly Incorporate New Requirements Transparency & Focuses on Users requirement High degree of collaboration between the client and project team Early and Predictable Delivery Predictable Costs and Schedule Allows for Change Focuses on Business Value

Advantages of Agile model: • Customer satisfaction by rapid, continuous delivery of useful software. • People and interactions are emphasized rather than process and tools. Customers, developers and testers constantly interact with each other. • Working software is delivered frequently (each sprint end). • Face-to-face conversation is the best form of communication. • Close, daily cooperation between management people and developers. • Continuous attention to technical excellence and good design. • Regular adaptation to changing circumstances. • Even late changes in requirements are welcomed Disadvantages of Agile model: • In case of some software deliverable, especially the large ones, it is difficult to assess the effort required at the starting of the software development life cycle. • There is lack of emphasis on necessary meetings and documentation. • The project can easily get taken off track if the customer representative is not clear what final outcom...