Backlog refinement/grooming – This activity occurs on a regular basis with the product owner and the some of the team members (or whole team) to achieve the following objectives:
1. Identify any new user stories that needs to be created based on the customer requirements
2. Writing acceptance criteria for those stories that do not yet have one or modify any existing stories that needs amending due to changes in the requirements or as more information becomes known
3. Prioritise user stories or re-assess them (done by product owner)
4. Assign estimates to stories that do not yet have them or re-assign based on the newly discovered information (assigning story points)

Sprint planning – The team meets on the first day of the sprint and discuss and agree on what will be delivered in this current sprint. Sprint goal is also determined here.

Sprint – This is the iterative development cycle that the agile scrum team commits to completing a set of work.

Sprint review – This activity occurs at the end of the sprint and this is where the team showcases or demonstrates the piece of work that was completed in the sprint.

Retrospective – After the review, the team participates in a retrospective session. This is where the team discusses what went well, what didn’t go so well and also reflect on what the team could do to improve the process.

Stand-up – A quick daily team meeting to discuss what they have worked on the day before, what they are working on today and any impediments that they are facing.

• Inadaptive or inflexible when there is a change in the requirement. Requirements have been defined in the earlier phase so if there are any changes to the requirement especially during the development phase then it becomes very time-consuming and expensive.
• Customer feedback only occurs after all the development and testing has been carried out. This leads to late feedback and the system may not satisfy all the customer requirements.
• Takes a long time to market/delivery because the working software/system is only produced late in the development lifecycle.
• Lots of time spent on documentation.
• All the planning and estimation activities occur at the start of the lifecycle and this may lead to inaccurate or poor estimation in costs and schedule especially if something that was not accounted for pops up. Also the development/QA team does not participate in this activity which also contributes to a possible incorrect estimations (most of the time only Project manager, Dev lead, and QA lead take part in this).

Smoke testing is done to test the health of a software build. It is a test that gets performed before moving onto carrying out a more intensive testing ie. for the initial stage of the build. Smoke testing is done by both developers and testers.
Sanity testing is done to verify that the affected functionality still work as expected. It is usually done after a fix in a particular module/functionality by testers after many regression tests.

System testing involves the testing of the entire application as per the requirements. It validates that the system is complete and will work as expected.
System integration testing focuses on testing the communications and interactions between different systems.

Functional testing involves tests that evaluate functions that system should perform as per customer and business requirements.
Non-functional testing evaluates characteristics of system such as usability, performance and security. It is essentially the testing of “how well” the system behaves in other words, it is concerned with the user experience.

Black box testing is based on an analysis of the specification/requirements or models. It concentrates on the inputs and outputs of the test object without reference to its internal structure.
White box testing is based on an analysis of the architecture, detailed design or the code of the test object. It concentrates on the structure and processing within the test object.

Alpha testing is carried out at the developer’s testing environment by potential or existing customers or an independent testing team.
Beta testing, on the other hand is carried out by potential or existing customers at their own locations.

Defect triage is a process where QA lead, project manager and development lead come together to categorise, prioritise and track defects.

A defect may be rejected by the developer if it turns out to be a false positives, not an actual failure due to defect.
For example, when the user is taken to an error page while searching for an item in the e-commerce website. If it turns out that this occurred not because of the bad logic in code but rather due to a database going down then this will be considered a false positive.

Usually a cosmetic or UI defects tend to have high priority and low severity. An example of this would be wrong location of the field.