Principles of Software testing

Seven Principles of Software testing-


1. Testing shows the presence of bugs.


2. Exhaustive testing is impossible. Unless the software under test has a very small logic, it is not possible to test all the combinations of input values(Permutations and Combinations)


3. Early testing: The testing should be started at an early stage so that enough time is available for testing.


4. Defect Clustering: It is seen that most of the bugs in a software are found in a small number of modules .i.e. 80% of the bugs are found in 20% of the modules.


5. The pesticide paradox: If we keep running the same set of tests over and over again, chances are that no new defects will be discovered by those test cases s the regression test has to keep changing too to accommodate the change in software. Test cases need to be regularly revised and reviewed.


6. Testing is context dependent: The amount of testing done depends on the criticality of the product. i.e. a critical product requires more rigorous testing.


7. Absence of errors fallacy: If no defect is found in software, it does not mean that the software is perfect and ready to be shipped.

Equivalent Partitioning (Black Box Testing Type)

What is Equivalent partitioning?

Equivalent partitioning is the process of classifying all the test cases into classes an to pick one test value from each class while testing. It is used to reduce the number of test cases to a limited set such that all input and output values are covered.
For Example: If a given input box attends only numbers from 1 to 100, there is no point is trying out all the values. You can classify the input into 5 cases.
1. A value at the lesser than the lower boundary Ex: -1 etc
2. A value equal to the lesser boundary i.e. 1
3. A value in between 1 and 100
4. A value equal to higher boundary i.e. 100
5. A value greater than the higher boundary , i.e. 101

Selenium Wait

Why do users need Selenium Wait?

Most web applications are developed with Ajax and Javascript. When a page loads on a browser, the various web elements that someone wants to interact with may load at various time intervals.

This obviously creates difficulty in identifying any element. On top of that, if an element is not located then the “ElementNotVisibleException” appears. Selenium Wait commands help resolve this issue.

Selenium WebDriver provides three commands to implement wait in tests.

Implicit Wait

Explicit Wait

Fluent Wait



1.Implicit Wait in Selenium

Implicit wait is applied globally on all web elements .

Implicit Wait directs the Selenium WebDriver to wait for a certain measure of time before throwing an exception. Once this time is set, WebDriver will wait for the element before the exception occurs.

Once the command is in place, Implicit Wait stays in place for the entire duration for which the browser is open. Its default setting is 0, and the specific wait time needs to be set by the following protocol.



Driver.manage().timeouts().implicitlyWait(10,TimeUnit.SECONDS);



2.Explicit Wait in Selenium

By using Explicit Wait command, the WebDriver is directed to wait until a certain condition occurs before proceeding with executing the code.

Setting Explicit Wait is important in cases where there are certain elements that naturally take more time to load. If one sets an implicit wait command, then the browser will wait for the same time frame before loading every web element. This causes an unnecessary delay in executing the test script.

Explicit wait is more intelligent, but can only be applied for specified elements


WebDriverWait wait = new WebDriverWait(driver,20);

Element = wait.until(ExpectedConditions.visibilityOfElementLocated(By.xpath());


In order to declare explicit wait, one has to use “ExpectedConditions”. The following Expected Conditions can be used in Explicit Wait.

alertIsPresent()

elementSelectionStateToBe()

elementToBeClickable()

elementToBeSelected()

frameToBeAvaliableAndSwitchToIt()

invisibilityOfTheElementLocated()

invisibilityOfElementWithText()

presenceOfAllElementsLocatedBy()

presenceOfElementLocated()

textToBePresentInElement()

textToBePresentInElementLocated()

textToBePresentInElementValue()

titleIs()

titleContains()

visibilityOf()

visibilityOfAllElements()

visibilityOfAllElementsLocatedBy()

visibilityOfElementLocated()

3.Fluent Wait in Selenium


The Fluent Wait command defines the maximum amount of time for Selenium WebDriver to wait for a certain condition to appear. It also defines the frequency with which WebDriver will check if the condition appears before throwing the “ElementNotVisibleException”.

To put it simply, Fluent Wait looks for a web element repeatedly at regular intervals until timeout happens or until the object is found.

Fluent Wait commands are most useful when interacting with web elements that can sometimes take more time than usual to load. This is largely something that occurs in Ajax applications.

While using Fluent Wait, it is possible to set a default polling period as needed. The user can configure the wait to ignore any exceptions during the polling period.

Wait wait = new FluentWait(WebDriver reference)

.withTimeout(timeout, SECONDS)

.pollingEvery(timeout, SECONDS)

.ignoring(Exception.class);

Selenium Framework

Selenium Framework:

Selenium Framework is a code structure that helps to make code maintenance easy. Without frameworks, we will place the “code” as well as “data” in the same place which is neither re-usable nor readable. Using Frameworks, produce beneficial outcomes like increased code re-usage, higher portability, reduced script maintenance cost, higher code readability, etc.

There are mainly three types of frameworks created by Selenium WebDriver to automate manual test cases:

· Data-Driven Test Framework

· Keyword Driven Test Framework

· Hybrid Test Framework


Data-Driven Test Framework:

In the data-driven framework, all of our test data is generated from some external files like Excel, CSV, XML or some database table.

To read or write an Excel, Apache provides a very famous library POI. This library is capable enough to read and write both XLS and XLSX file format of Excel.


Keyword Driven Test Framework:

In the keyword-driven test framework, all the operations and instructions are Keyword Driven Framework is a type of Functional Automation Testing Framework which is also known as Table-Driven testing or Action Word based testing. The basic working of the Keyword Driven Framework is to divide the Test Case into four different parts. First is called as Test Step, second is Object of Test Step, third is Action on Test Object and fourth is Data for Test Object.

The above categorization can be done and maintained with the help of Excel spreadsheet:

Test Step: It is a very small description of the Test Step or the description of the Action going to perform on Test Object.
Test Object: It is the name of the Web Page object/element, like Username & Password.
Action: It is the name of the action, which is going to perform on any Object such as click, open browser, input etc.
Test Data: Data can be any value which is needed by the Object to perform any action, like Username value for Username field.



Hybrid Test Framework

Hybrid Test framework is a concept where we are using the advantage of both Keyword and Data-driven framework.

Here for keywords, we will use Excel files to maintain test cases, and for test data, we can use data, provider of TestNG framework.

Types of Environment

What is Environment?

It is basically a server which hosts the application. There are basically three types of environment-

1.Development Environment - This is the environment where developer tests code and checks whether the application run successfully with that code. Every developer run his/ her machine that is called local environment. Once the application has been tested and developer feels that the code is working fine. Then application goes to test environment which is an independent server.


2.Test environment - The application is tested to check the reliability and to make sure it does not fail on the actual production server. Once QA finds any bug or defect, the application sends back to the developer to fix the bugs.This process is repeated until application is debug free and ready to deploy.


3. Production Environment - Once the application is approved by developer and QA , then it is deployed to the production Environment. After deployment finishes, all features and fixes are to be tested that they work properly in production. Basically testing is done in all environments. Test scripts are written once to run against all the environments.

Contract Testing

 Contract testing- 

The contract is between a consumer (for example, a client who wants to receive some data from an app) and a producer (for example, an API on a server that provides the data the client needs) 

Contract testing is a way to ensure that services can communicate between Producers and Consumers. 

Before making changes in service Producer needs to know if the consumer can still use the service and whether the changes still meet the demands of the consumer’s contract. This is when contract testing plays important role. 

Contracts are written and managed exclusively by consumers, producers must first obtain permission from consumers before they can make any changes. If producers need to implement new features, they can see which consumers would be affected by the change(s) by looking at the status of the consumer’s contract tests.

Swagger Spec

What is Swagger Spec -

Swagger allows us to describe the structure of an APIs so that machines can read them. The Swagger specification defines a set of files required to describe such an API. These files can then be used by the Swagger-UI project to display the API . The OpenAPI Specification, originally known as the Swagger Specification, is a specification for machine-readable interface files for describing, producing, consuming, and visualizing RESTful web services. Swagger definitions can be written in JSON or YAML format. 

Basic features of Swagger spec-

• It  provides Nice fancing UI generic operation. When creating an APIs, Swagger tool may  be used to automatically generate an Open API document based on the code itself.
• It reduces the need for human generated client code.
• Swagger open-source tooling may be used to interact directly with the API through the Swagger UI.
• It's human readable and machine readable. 

API

What is an API? 

API acts as an interface between two different applications so that they can communicate with each other and third-party vendors can write programs that interface easily with other programs. For example, two applications written in C# and Java can communicate via API. 

How Web Service is different from API? 

Web service and API both are means of communications. The only difference is that a Web service provides interaction between two machines over a network. “HTTP” is the most commonly used protocol for communication. Web service also uses REST, Soap, GraphQL and RPC as a means of communication. While an API can use any means of communication. For example- Jar files, Interrupts in Linux kernel API, DLL files in C/C# etc.

How does API work?

Imagine a waiter in a restaurant. You, the customer, are sitting at the table with a menu of choices to order from, and the kitchen is the provider who will fulfill your order.

You need a link to communicate your order to the kitchen and then to deliver your food back to your table. It can’t be the chef because he/she is cooking in the kitchen. You need something to connect the customer who’s ordering food and the chef who prepares it. That’s where the waiter — or the API — enters the picture.

The waiter takes your order, delivers it to the kitchen, telling the kitchen what to do. It then delivers the response, in this case, the food, back to you. 

 

Here are some key points to remember- 

1. API and Web service serve as a means of communication.
2. All Web Services are API but APIs are not Web Services. A Web Service needs a network for its operation whereas an API doesn’t need a network for its operation.
3. Web Service might not perform all the operations that an API would perform.
4. Web services include any software, application, or cloud technology that provides standardised web protocols (HTTP or HTTPS) to interoperate, communicate, and exchange data messaging written in different language formats – usually XML, Json Format, HTML, JavaScript – throughout the internet.

What are the Different Protocols for API? 

1. SOAP- SOAP is defined as Simple Object Access Protocol. This web service protocol exchanges structured data using XML and generally HTTP and SMTP for transmission.
Pros: Usually easier to consume, more standards, distributed computing
Cons: Difficult set-up, more coding, harder to develop
2. REST- (Representational state transfer)A REST web service uses HTTP and supports/repurposes several HTTP methods: GET, POST, PUT or DELETE. It also offers simple CRUD-oriented services.
Pros: Lightweight, human readable, easier to build
Cons: Point-to-point communication, lack of standards
3. GraphQL- It can show the best performance when the number of queries needs to be reduced to the absolute minimum. It can be a good solution for cases when there is no dependency between the client application and the server.
4. RPC- This protocol specifies the interaction between client-server based applications. One program (client) requests data or functionality from another program (server), located in another computer on a network, and the server sends the required response.
HTTP Methods for Restful APIs-

HTTP Verb
CRUD
Entire Collection
Specific Item (e.g. /customers/{id})

POST
Create
201 (Created), 'Location' header with link to /customers/ {id} containing new ID.
404 (Not Found), 409 (Conflict) if resource already exists.

GET
Read
200 (OK), list of customers. Use sorting and filtering to navigate big lists.
200 (OK), single customer. 404 (Not Found), if ID not found or invalid.

PUT
Update/Replace
405 (Method Not Allowed), unless you want to update/replace every resource in the entire collection.
200 (OK) or 204 (No Content). 404 (Not Found), if ID not found or invalid.

DELETE
delete
405 (Method Not Allowed), unless you want to delete the collection itself.
200 (OK) or 204 (No Content). 404 (Not Found), if ID not found or invalid. 

for example--

Resource - Person

Service- Contact information 

Representation: name, address, Phone number 

JSON or XML format

Some of the risks using API-

API changes - we can risk about versioning, Structure - schema can change, Server calculations change.

Availability - Any n/w issue can have an effect how API works 

Performance-  Programmatic access , Security

We have to figure out different paths in API

Test doubles- we actually test that is not real. 

what are they ?

Mock - u can focus on testing , i have created json data , u can reference them in that way.

stubs - 

fake -

Anything that stands in for another part of the system 

Powerful tool 

why use them?

Isolate the server 

Server not available 

exploration means finding new things ..............

automation - repeating things - do not change , do change , third party API 

they are related but not same.

Automation approaches 

- 

Data Driven testing- what data is available . for example- how to share data bt 300 calls. 

Workflow driven- series of API call in seq

follow workflow as customer follow

setting up test automation.

there is new set of test data 

how data is effectively into coding

do not  automate everything

API are great way for automation testing

load testing, speed testing how fast page response, how many item page is looking for

security testing - 

the user suspects 

Standard security checks 

Areas of responsibilities

Vulnerabilities happens 

Validations 

Test micro services -

API driven 

 how do micro services talk to each other 

 

Design patterns in Automation Testing

Design Patterns in Test Automation World


Automation testing is a process of developing software to test software. Hence, the test patterns are loosely similar to design patterns that are used in software development.
Design patterns show how to design the test automation test ware so that it will be efficient and easy to maintain. A design pattern provides a general pattern provides a general reusable solution for the common problems occur in software designs.
The basic idea is to speed up the development process by providing well tested, proven development and design paradigm.


What are the advantages of using Design Patterns?


· Low maintenance effort and time
· Low maintenance cost
· Enhanced code re-usability
· Enhanced reliability
· Structured code base which is easy to fix and extend
· Improved communication





Different Design Patterns -


1. Record and play
2. Classical Design
3. Facade Design
4. Singleton Design
5. Page Object Design
6. Modular Design


1.Record and play


Record and playback tools are used in training. Tools let the tester hit record and manually go through the real user actions of pre scripted test case. For example- learning and training, simple play your video, extremely simple web based application functionality, where the code base never changes.


2.Classical Design


It requires the creation of small, independent scripts that represents features, functionality or module of system based on its own managed data source. The process is complex and requires an extra effort to come up with the test data sources. For example- Small application of not more than 100 TC’s, application like data entry/from filling regularly.


3.Facade Pattern


The Facade pattern provides a simple interface to deal with complex code. In the facade pattern, as applied to test automation, we design the facade class which has methods that combine actions executed on different pages. For example- Customer service application, departmental store application


4.Singleton Pattern


A Singleton class means only one instance of it can exist at any time. But why would you need this?
Well it is very useful in a case when you need to use the same object across the whole framework. A Singleton class returns the same instance every time you try to instantiate an instance of the class. Think of it providing global access to a single object, for example, the log file object ,most of the desktop application, test automation, hardware devices automation.




5.Page Object Model


The Page Object Model is a widely used object design pattern for structuring automation test code. Here, pages in the applications are represented as Classes, and various UI elements of that pages are defined as variables. For example- Any enterprise application, retail software, banking application, e-commerce application.


6.Modular Design Pattern


In the current era of digital transformation where Mobile, Cloud, Big data concepts are playing a significant role, Complex design help to design end to end test automation solutions efficiently by integrating. Methodologies, frameworks, accelerators, latest technologies, virtualisation tools and lab management solutions. For example- Mobile application, Enterprise application, Cloud application.

GIT AND GITHUB

The Version Control System – Git and GitHub

What is Git?

  Git is open free source distributed control system designed to handle everything from small projects to large project with speed and efficiency. Git actually create local repository on our computer.

Why should we learn Git?

Git is most popular version control system. Let’s talk about manage our projects files. Project can have so many files like html, xml. Git keep track of every change in our application. If we want to see out code which we have written a month ago then Git is very helpful and we can see what date and time we have made change to our data.

DevOps

What is DevOps?

It is coming up with two words Development and operations. DevOps is not a tool, it is not a software, not a programming language then what it is? DevOps is more over a philosophy, more over a mindset the way how you take your product  or whatever website you are designing and taking that product or website so that million of people can use it. This entire process has variety of ways to go through with it. So DevOps is the concept that is used in application lifecycle management in which both Development and operation team are working in the sink so whatever product and feature you are giving to end user, you can give it to smoothly.

Shift-Left Testing

                                                            SHIFT-LEFT TESTING


Shift lift testing is an approach to the software testing and system testing in which testing is performed earlier in the life cycle.
Firstly, the principle of ‘Shift left’ supports the Testing team to collaborate with all the stakeholders early in the software development phase. Hence they can clearly understand the requirements and design the test cases to help the software ‘Fail Fast’ and enable the team to fix all the failures at the earliest.
Shift Left approach is nothing but involving the testers much earlier in the software development life cycle, which in turn would allow them to understand the requirements, software design, architecture, coding and its functionality, ask tough questions to customers, business analysts, and developers, seek clarifications, and provide feedback wherever possible to support the team.

This involvement and understanding will lead the testers to gain complete knowledge about the product, think through various scenarios, design real-time scenarios based on the software behaviour which would help the team in identifying the defects even before coding is done.











Shift Lift Approach influences Software Development in several ways----


· Shift Left approach focuses on involving testers in all and most importantly the critical stages of the program.
· Shift Left approach gives the opportunity for the Testers to design the tests first,
· IT allows the Developers to take more ownership of their code and increase their responsibilities on testing.
· Shift Left approach also encourages testers to adopt Behavioural Driven development and Test driven Development.
· Shift Left Testing in Agile: Shift Left approach supports forming Agile Scrum Teams which mandatorily includes Testers along with the other roles and includes Testers in regular stand up calls, other interactions, review meetings which has made the testers to have more information related to the program and hence has allowed them to indulge and involve in the detailed analysis of the software and provide rapid feedback which would help in preventing the defects grounded in the software.

Serverless Architecture

SERVERLESS ARCHITECTURE -


Serverless is a cloud computing execution model where the cloud provider dynamically manages the allocation and provisioning of servers.
Serverless applications are event-driven cloud-based systems where application developments rely solely on a combination of third party service and client side and cloud-hosted remote procedure calls.


ADVANTAGES -

1.No server management is necessary
Although 'serverless' computing does actually take place on servers, developers never have to deal with the servers. They are managed by the vendor. This can reduce the investment necessary in DevOps, which lowers expenses, and it also frees up developers to create and expand their applications without being constrained by server capacity.
2.Developers are only charged for the server space they use, reducing cost
As in a 'pay-as-you-go' phone plan, developers are only charged for what they use. Code only runs when backend functions are needed by the serverless application, and the code automatically scales up as needed. Provisioning is dynamic, precise, and real-time.



3.Serverless architectures are inherently scalable
Applications built with a serverless infrastructure will scale automatically as the user base grows or usage increases. If a function needs to be run in multiple instances, the vendor's servers will start up, run, and end them as they are needed, often using containers (the functions start up more quickly if they have been run recently – see 'Performance may be affected' below)..
4.Quick deployments and updates are possible
Using a serverless infrastructure, there is no need to upload code to servers or do any backend configuration in order to release a working version of an application. Developers can very quickly upload bits of code and release a new product. This also makes it possible to quickly update, patch, fix, or add new features to an application
5.Code can run closer to the end user, decreasing latency
Because the application is not hosted on an origin server, its code can be run from anywhere. It is therefore possible, depending on the vendor used, to run application functions on servers that are close to the end user. This reduces latency because requests from the user no longer have to travel all the way to an origin server. Cloudflare Workers enables this kind of serverless latency reduction.
When should developers avoid using a serverless architecture?
There are cases when it makes more sense, both from a cost perspective and from a system architecture perspective, to use dedicated servers that are either self-managed or offered as a service. For instance, large applications with a fairly constant, predictable workload may require a traditional setup, and in such cases the traditional setup is probably less expensive .
Serverless architectures are not built for long-running processes
It is difficult to replicate the serverless environment in order to see how code will actually perform once deployed. Debugging is more complicated because developers do not have visibility into backend processes, and because the application is broken up into separate, smaller functions

Requirement Traceability Matrix

Requirement Traceability Matrix
Requirement Traceability Matrix is a document that maps and traces user requirement with test cases to ensure that for each and every requirement adequate level of testing is being achieved. It captures all requirements proposed by the client and requirement traceability in a single document.
The process to review all the test cases that are defined for any requirement is called Traceability. Requirement Traceability Matrix is the means to map and trace all of the client's requirements with the test cases and discovered defects. It is a single document that serves the main purpose that no test cases are missed and thus every functionality of the application is covered and tested.
A Requirements Traceability Matrix is usually in tabular format as it holds multiple relationships between requirements and test cases.



How To Create A Requirements Traceability Matrix--
To being with we need to know exactly what is it that needs to be tracked or traced.
Testers start writing their test scenarios/objectives and eventually the test cases based on some input documents – Business requirements document, Functional requirement document and Technical Design document (optional). Then according to the requirement, we trace our test cases.


Here is how a simple Traceability Matrix would look for our example:

CI/CD PIPELINE

Understanding the CI/CD Pipeline: What It Is, Why It Matters



Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.
When you have a team of developers, each of whom is responsible for a separate feature, you need to integrate the different features before you’re ready for a release. By integrating so frequently, your team can surface errors earlier. And when those are caught, the amount of backtracking needed to find the cause is also much reduced. Therefore, your team can resolve the integration errors much faster.

Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.





Top of Form

Bottom of Form

How to Practice Continuous Integration
If you want to practice CI, the steps roughly go like this:
1. Developers check out code from the repository to work on it locally. Ideally, they create a new branch for the feature they want to implement.
2. When their feature branch is ready, they run tests locally in their development environments.
3. Once all tests pass, they push the commits to the single source repository.
4. Whenever there are changes on the repository, a CI server checks out the changes and performs a “build and test.” A build and test is when the CI server builds the entire system on the developer’s feature branch and runs all the unit and integration tests.
5. The CI server notifies the team of the integration result. There should generally be four outcomes: failed build, successful build, failed tests, successful tests.
6. If there’s a failure, the team fixes the issue ASAP.
7. When the feature branch is merged to the main branch, they repeat steps 2–6.
8. They continue to develop and repeat the steps 2–6 whenever there’s new code to be checked in to the repository.


.
What’s the Difference Between Continuous Deployment and Continuous Delivery (CD)?
You may be confused by the fact that there’s another term CD can stand for: continuous delivery. So what’s the difference between the two? continuous deployment is about automating the release of a good build to the production environment. In fact, Humble thinks it might be more accurate to call it “continuous release.” On the other hand, continuous delivery is about ensuring that every good build is potentially ready for production release. At the very least, it’s sent to the user acceptance test (UAT) environment. Your business team can then decide when a successful build in UAT can be deployed to production —and they can do so at the push of a button.
To keep it simple, here’s a diagram.

Agile Software Development Process model

                                                                   Agile Methodology

Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and development practices so that you can improve.

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.

The rules of Scrum bind together the events, roles, and artifacts, governing the relationships and interaction between them. The rules of Scrum are described throughout this tutorial.

Scrum formal events for inspection and adaptation:

Product backlog: Sometimes known as backlog grooming, this event is the responsibility of the product owner. The product owner’s main jobs are to drive the product towards its product vision and have a constant pulse on the market and the customer. Therefore, he/she maintains this list using feedback from users and the development team to help prioritize and keep the list clean and ready to be worked on at any given time. You can read more about maintaining a healthy backlog here.

Sprint planning Meeting: The work to be performed (scope) during the current sprint is planned during this meeting by the entire development team. This meeting is led by the scrum master and is where the team decides on the sprint goal. Specific use stories are then added to the sprint from the product backlog. These stories always align with the goal and are also agreed upon by the scrum team to be feasible to implement during the sprint.

At the end of the planning meeting, every scrum member needs to be clear on what can be delivered in the sprint and how the increment can be delivered. 

Sprint: A sprint is the actual time period when the scrum team works together to finish an increment. Two weeks is a pretty typical length for a sprint, though some teams find a week to be easier to scope or a month to be easier to deliver a valuable increment. Dave West, from Scrum.org advises that the more complex the work and the more unknowns, the shorter the sprint should be. But it’s really up to your team, and you shouldn’t be afraid to change it if it’s not working! During this period, the scope can be re-negotiated between the product owner and the development team if necessary. This forms the crux of the empirical nature of scrum.

All the events — from planning to retrospective — happen during the sprint. Once a certain time interval for a sprint is established, it has to remain consistent throughout the development period. This helps the team learn from past experiences and apply that insight to future sprints.

Daily Scrum or Stand Up Meeting: This is a daily super-short meeting that happens at the same time (usually mornings) and place to keep it simple. Many teams try to complete the meeting in 15 minutes, but that’s just a guideline. This meeting is also called a ‘daily stand-up’ emphasizing that it needs to be a quick one. The goal of the daily scrum is for everyone on the team to be on the same page, aligned with the sprint goal, and to get a plan out for the next 24 hours.

Sprint review: At the end of the sprint, the team gets together for an informal session to view a demo of, or inspect, the increment. The development team showcases the backlog items that are now ‘Done’ to stakeholders and teammates for feedback. The product owner can decide whether or not to release the increment, although in most cases the increment is released.

This review meeting is also when the product owner reworks the product backlog based on the current sprint, which can feed into the next sprint planning session. For a one-month sprint, consider time-boxing your sprint review to a maximum of four hours.

Sprint retrospective: The retrospective is where the team comes together to document and discuss what worked and what didn’t work in a sprint, a project, people or relationships, tools, or even for certain ceremonies. The idea is to create a place where the team can focus on what went well and what needs to be improved for the next time, and less about what went wrong.