Untitled

Cookie in simpler terms means just the textual information saved by some website. 

When you visit a particular website, some information is saved in your local system so that when you visit the same website again, this website is able to recognize you and show you the results according to your preferences. Cookies have been long used in the internet history and have developed in a magnificent way.

When you visit a website you actually requests the web page from the server. For a server, every request is a unique request. So if you visit hundred times, the server will consider each and every request unique. Since the intensity of requests that arrive at a server is high, it is obvious and logical not to store every user’s information to the server. Maybe you never visit again and the same information will be redundant. So, to uniquely remember you, the server sends the cookies along with the response which is saved in your local machine. Now the next time you hit the same server, you will get a response according to you as the server will recognise you.

                        This cookie is unique to every server (some exceptions exist today because of advertisements). So you might have many cookies in your system but a server will recognize its own cookie and can analyse it for you. How this evolved over time and used today is discussed in the next section.

 Why to use Cookies?

Cookies developed in the initial days because developers needed some information about the client to make their experience better. Let say you visit a website which is not in your local language (let’s say English). You choose the English option in the language section of the website. Now if you visit the same website 5 times a day, you might have to change the language 5 times. Therefore, this information is saved as a cookie in your system. So the next time you send the request, the server will know that you want to see the website in English. This is where cookies play a vital role. This is extended to a greater level today. Cookies are also used to store your cart’s information while browsing products on an eCommerce site. Cookies has helped us from logging in again and again every time you login. So if you sum these things, cookies are used primarily to make your experience better and shed the load from you wherever possible.  But this is a very minute example of the scale cookies are used today.

As seen in the above image, a cookie can be anything from your preferred language to your gaming related data to the products in your cart.

 Advancement of Cookies

The concept of cookies was developed for creating a better experience by saving little information as texts on the client’s machine. But as the concept became more and more demanding and successful, the usage of cookies increased many folds. Today, cookies are used from what you searched to even what you saved in your cart. Cookies are used today at an extreme level saving your information about various websites. Knowing this, it is obvious that the size of the information has increased. So developers have recognized that all the information cannot be saved in the client’s machine as it will increase the cookie size which is sent with requests and also will load the client’s machine. Therefore cookies are now saved in a different way. Now, if you visit a website, the website provide you with a cookie id which is uniquely recognizable by the server and saved in your system. This id is then linked to the database of the company where all your information is saved and then fetched from the database. This way cookies can be managed more efficiently and more securely.

  In the above image, the cookie is linked with an id to the database of the website where all the data is fetched using that Id. You should not think that cookies today save only the id in your system. Cookies contain some information like login credentials and session time etc. But these are very minimal as compared to what cookies are actually linked to in the database of the website.

Security threats related to Cookies

Cookies as you must have come to know till now, saves your information to your machine. This information is highly personal to you and should only be retrieved by the server which saved it. Does it possess any security threats? Fortunately no. The following things should be kept in mind

·         A cookie cannot be used by any other server as the id saved in your cookie is directly mapped to the website’s database.

·         A cookie can never be used to access any information saved in your system, browser or hard disk.

·         A cookie cannot be used to deliver viruses or any other threats.

What are Parameters in Request?

Request Parameters are part of the URL which is used to send additional data to the Server. Let us analyze a simple URL:

https://www.bing.com/search?q=ToolsQA

In this URL Request parameter is represented by “q=ToolsQA” part of the URL. Request parameter starts with a question mark (?). Request parameters follow “Key=Value” data format. In our example “q” is the Key and “ToolsQA” is the value. Server reads the Request parameter from the URL and sends a Response based on the Request Parameter. In our example Bing will return search results for ToolsQA. If you change the Value from ToolsQA to DemoQA, you will get results for DemoQA instead of ToolsQA. Which means that Server reads the Request parameter and responds based on that.

Parameters can be passed in GET Request, if you are not sure how to do a GET Request using Postman, please take a look at the previous article How to make a GET Request. Since, now you know how to make a GET Request, we will move ahead with sending parameters in a GET Request.

Before talking about Parameters and understanding them clearly, we will send the url in our browser.

1.Go to your browser and write www.google.com in your address bar.

2. You will see the response page from Google. Type ToolsQA in the search bar and press Google Search.

Now you need to understand here that the page which shows the results will remain the same just the results will differ according to the search. You just now searched for ToolsQA, this serves as a parameter in the url to tell the server that we need the results of the ToolsQA specifically. The server responds according to the search parameter.

A url consists of many parameters such as source id  and encoding format etc. See the url below and you will see &q=ToolsQA which is added in the url to tell the server.

Request Parameters in Postman

1.Just prepare a GET Request in Postman with the URL www.google.com/search and then click on Params.

                        2. Write the following things written under Key-Value pair as shown. Again q stands for query here and ToolsQA is the search term. Now press Send.

 3. Look at the preview, you would see that instead of the google home page we have received a response for a specific search query which is ToolsQA. Instead of ToolsQA you could write anything and receive it’s response. This indicates that we have passed some information (Parameters)  about the result we wish to see.

NOTE: As discussed above, you can see that different search queries give different results but the page design remains the same, just the content differs.

Multiple Parameters

You can also use multiple parameters inside a single query. As we discussed above while sending the search query as ToolsQA, there are many parameters that are sent in the url. ToolsQA was for the results that were to be shown, another parameter such as encoding format is also used to tell the server in which format can the result be encoded and sent to the client. In the above example the default encoding format used is UTF-8.

People who have worked on Selenium will be well versed in the concepts of locators. Locators are the backbone for all automation frameworks for Web-based applications. Additionally, a locator is an identifier that tells any automation tool that GUI elements ( say Text Box, Buttons, Check Boxes, etc.); it needs to operate. Following the same concepts, Cypress also uses the locators to identify the UI element for the application under test. Subsequently, we will cover the following topics in this article to understand the concept of locators in the world of Cypress:

What Locators are supported by Cypress?

What Locators are supported by Cypress?

Unlike Selenium, Cypress only supports CSS selectors( very similar to JQuery Selectors). Therefore, we will be using CSS selectors in all our Cypress automation code.

Note: Cypress does support Xpath selectors as well. However, that does not come by default. In other words, we need ‘Cypress-Xpath’ external plugins to assist this selector.

We can write CSS selectors in multiple ways. For example, using the id, class, or any other attribute of a web element that can help us in writing customized CSS selectors. Moreover, we can categorize the CSS selectors into the following categories:

How to write Cypress Locators with CSS Selector?

It is a simple HTML page, which has a label as “UserName.”  Additionally, it also has a text field that has various attributes such as “id” as ‘userid,’ “class,” as ‘login’ and “name” as ‘username.’

Now suppose, we have to identify the web elements on this HTML page by using the various types of CSS selectors. Let’s see in the below sub-sections, how can we achieve the same.

CSS Selector: ID

HTML tag – It is the tag that denotes the web element which we want to access.

# – The hash sign symbolizes the ID attribute. Additionally, it is mandatory to use the hash sign if we are using the ID attribute to create a CSS Selector.

Value of ID attribute – It is the value of an ID attribute that we access.

For Example, input#userid where “userid” is the id of the tag input.

CSS Selector: Class

. – The dot sign is used to symbolize the Class attribute.

Example: input.login where login is the class name of the tag input.

CSS Selector: Attribute

Attribute – It is the attribute we want to use to create a CSS Selector. Moreover, it can be value, type, name, class, id, etc.

For Example, input[name=username] where “username” is the value of attribute “name”.

or

input[class=login], where, “login” is the value of the attribute “class”

CSS Selector: Sub-string

There are three ways in which CSS Selectors can be created based on matching the substring:

Match a prefix

Match a suffix

Match a substring

While designing a Test Automation Framework, one of the primary requirements is to segregate the test scripts from the test data. Additionally, if the same framework can provide the functionality to mock the backend/third-party requests and offer the capability to test the frontend independently, it will be the icing on the cake. Cypress provides both of these functionalities, which we can quickly achieve with the help of Fixtures in Cypress. Let’s understand these capabilities of Cypress by understanding the following topics in Cypress:

What is a fixture in Cypress?

How to implement fixtures as a test data source in Cypress?

What is a fixture in Cypress?

As already stated above, Cypress provides us with a feature to drive the data from external sources. We can draw a comparison to the Data-Driven Frameworks, which are one of the popular automation testing framework types in the current market. As we all know that, in Data-Driven Frameworks, we generally keep the data in excel files and use external libraries such as Apache POI to read the data and use it in our test with an automation framework. Similarly, Cypress has provided the same functionality in its architecture, where we can read the data from external files known as fixture files.

Now, as we discussed in the article “Cypress Tests,” Cypress provides a directory named as fixtures, which stores various “JSON” files, and these JSON files can store the test data which can be read by multiple tests. We store test data in the form of key-values, which we can access in the test scripts.

How to implement fixtures as a test data source in Cypress?

As we discussed, fixtures can store and serve test data in Cypress tests. The implementation of fixtures is a two-step process:

Defining a fixture file, which will store the test data.

Using the fixture file in test scripts and access the test data.

Let’s understand how can we implement both of these steps:

How to define a fixture in Cypress?

To understand the concepts and implementation of fixtures in detail, we will use the demo website. Suppose we want to automate the following test case:

Open the URL, which is My Account page of E-commerce demo website – http://shop.demoqa.com/my-account/.

Then do the registration using a valid username, email, and password.

Verify if the registration was successful or not.

Now to accomplish these tasks, we need a valid username, email, and password. One way to pass this data is directly in the test script, but that will hard code the data set. To avoid this hard-coding problem, we can specify this test data in the fixture files. When we created the project hierarchy for Cypress, it automatically creates a folder named “fixtures” and a file named “example.json” under the fixtures folder. We can use this file to specify our test data  and edit it to put the following fundamental values:

Where,

filePath (String) is a path to a file that you have written within the fixtures folder(defaults to cypress/fixtures).

encoding (String) is put to use when reading the file. Some of the popular encodings supported are ascii, utf-8, utf-16le, hex, etc.

options (Object) changes the response timeout.

Key Takeaways

Fixtures enable data-driven automation in Cypress by saving the test data in JSON format

In simplest of terms, the domain object modelling is to take a problem domain and build a class diagram showing different types of objects, and the relationship between them. In other words, the domain object model provides an overall framework, which details out how we are going to add functions for every feature.

Since we already discussed the classes that we are going to use, and also the interaction between these classes, it becomes effortless for developers to follow this structure.

The best technique for Domain Object modelling is modelling in colour. Which, in turn, means that different colours represent different classes. Additionally, their categorisation happens as per the requirements.

According to Wikipedia, UML is a set of four colours and is called the Unified Modeling Language diagram.

Peter Coad suggested these colors first. The classes divide into different categories, and each class has its color.

·         Pink: Time Interval: Here, in this category, the time associated with a business process or a moment in time is there. In other words, we can say anything which has time interval or moment when some event happened comes under this category. For example, the purchase order of the car can be categorized under pink as it will have the date and time the vehicle was purchased. Therefore, these become tracking details.

·         Yellow: Represents an active role- Represents an active role- An individual or an organization can play a role. A person can play a unique role or multiple roles. For example, on a car-selling website, a customer can be a buyer, a seller, or a broker. One person is playing multiples roles.

·         Green: Party, Place or Thing- On a car selling website like cardekho.com, the vehicle will be categorized under green color as it is a thing. In addition to that, this category recognizes attributes like registration number, serial number, license number, person’s name, etc. This attribute will have the buyer and selling party details, place details, or things details.

·         Blue: Catalog like- In this category, mostly catalog like descriptions are there. This attribute will have the list of all the details for one particular party or activity. For example- on a car selling website if there is one car for sale, then all the descriptions of this car will be given. In other words, all the characteristics, car type, engine configuration, and everything will be mentioned and not just the car.

For example: Let’s consider the case of a yoga center. The performance of multiple tasks happens there.

                        All the services (Exercises) will have time or rounds (Reps) assigned to them. Therefore, they are there in the Pink category. 

Yoga is a party(service provider), so it is green in color. It also includes its unique attributes like registration number, head office location, and center head. 

Pranayama tells you about a part of the description of the course. As a result, the blue color represents it. As mentioned above, pranayama is a description of yoga and the items covered in Pranayama are Surya Namaskar, Kapalbhati, Hummingbird, Anulom Vilom (Alternate nostril breathing) are the asanas(Items) covered under that. The details of these, along with benefits form part of the description.

A person can be either a trainer or a trainee. Therefore, the yellow color represents them both.

 Below is the format we use to define this UML diagram

The fundamental difference between Crystal Clear and other Crystal methods is that in Crystal Clear, there is only one team in a project. Whereas in the rest of the Crystal methods, there are multiple teams to follow through the project.

However, in all the Crystal methodologies, one job assignment may include numerous roles.

The Crystal methods have many positions like Executive Sponsor, Executive, Lead Designer, Programmer, The Ambassador User, and Tester. These are the leading roles.

There are some other sub-roles like Project Coordinator, Business Expert, Technical Writer, and Business tester.

Above roles are divided into two categories-

  Real Roles: ·         

The Executive Sponsor: The executive sponsor is the one who

·         Allocates or decides the allocation of the money for the project

·         Creates visibility for the project

·         Help team with crucial business-level decisions

The Ambassador User: The Ambassador User is the one 

·         Who would be testing the final product

·         One who is aware of the complete operational procedure

·         Who has the knowledge of the entire system in use

The Lead Designer: is responsible for all technical work

·         Should have a massive experience with software development

·         Should be able to figure out when the project team is on-track

The Programmer: The Programmer is another significant person. A Programmer works along with the designer to make the software system. Additionally, a person who can do coding or programming can do design and vice versa.

                          The Virtual roles ·     

    The Coordinator: is the Project Manager, responsible for

·         Take notes at the Project Planning and Review Meetings

·         Combine the information and present it to the Sponsors

·         Keep the Project Sponsor informed about the status of the project and keeps the things visible.

 The Business Expert: Business expert is the person who 

·         Knows how the business runs

·         Identifies the priorities and can differentiate between less prior tasks

·         Understands the policies and makes sure everyone follows them

·         Develop all the queries that a programmer may have about policies and system

The Technical Writer and the Tester: It is not a permanent role and is rotating or temporary. A tester is responsible for testing the software after its de. A tester is responsible for

·         Testing the software

·         Reporting a bug (if any)

·         Try to fix the bug at his end first (if possible)

What is DSDM?

DSDM is dynamic in nature as it’s a Rapid Application Development (RAD) approach to software development. It is an iterative and incremental approach that emphasises continuous customer/ Client involvement.

What makes DSDM different is, active involvement of the user and the decision making power is with the teams working on it. The teams are empowered to make decisions.

It focuses on the formula: 80% system deployment in 20% time, i.e., it doesn’t take long to achieve a working stage or to get it to a stage where you can say it will work.

This method is used mainly for the system where software delivery requirements happen in a short span. Its goal is to deliver software in time and on budget while still adjusting for new conditions or changes along the way.

 Brief History:

According to Wikipedia, the Dynamic Systems Development Method (DSDM), its base was developed in the 1990s to meet the need for rapid business, but it was officially originated in January 1994 by a non-profit group in the UK, to provide an industry-standard framework for project delivery. Its first version got finished in January 1995. And the latest version, which is currently in use is 4.2, developed in 2003.

 DSDM Principles:

DSDM has nine fundamental principles revolving around the business needs:

                        1.    Active user involvement: the first and most crucial principle is user involvement. User, the people who will be using the final product, must be actively involved throughout the project development. It helps in reducing the errors which may occur due to user perception and thus reduces the cost of rework as well. DSDM emphasis on working with a small and selected group of users and stay in touch with them continually, rather than meeting them occasionally in periodic meetings and review sessions.

2.    Empowered teams: To proceed quickly and smoothly, this model encourages and empower teams to take decisions. Below are some areas where decision making as a team is very critical  

·         Requirements decision

·         Prioritizing the activities and features delivery

·         Details of technical requirements

·         Which functionality needs to add in a given incremental

3.    Frequent delivery: A frequent delivery of value to the customer ensures that the errors/bugs get identified, worked upon, and resolved/ reversed/fixed at an early stage. The source of the error and root cause is also found and fixed. It applies to all, requirement documents (user stories), working models as well as on program codes.

4.    Fitness for business: In DSDM, our focus is to deliver software which is efficient enough to solve a business need and accepts changes or enhancement in a later iteration. DSDM focuses on satisfying business needs first and doesn’t allow to create ad-hoc software. It keeps the process flow simple and effective.

5.    Incremental development: To keep the big project simple and less complicated, it becomes crucial to decompose it into multiple small feature projects. Every delivery ensures a new feature gets delivered to the client. This incremental development and delivery continue until the delivery of the complete set of business required features.

6.    Reversible changes: In DSDM iteration happens through small increments. As all the stages of development are well known to developers, so changes here are reversible. Therefore, the fear of total loss of work is also very less.

7.    Base-line the requirements: Some high-level baselines need to be set to limit the degree of freedom to make changes. During the business agreement phase, the Business and Development Team discuss and agree on the baseline when the change requests and requirements would be “frozen.”

8.    Integrated testing: In DSDM, testing is done as early as in the development phase to ensure that the product does not have any technical flaws. Developers and team leads cross-check even the testing documents. It helps in fixing issues at a very early stage and reduces rework and therefore reduces cost and time.

One of the significant contributors to Kanban’s popularity is “Kanban Board.” In Kanban, we use a visual board to display the progress of the project in three simple and easy stages i.e.

·         To Do

·         In-Progress/Doing

·         Completed/Done

                        A basic Kanban board structure includes-

Lists (columns to track progress):

Lists are the columns that are there on the mainboard. Each column represents a specific process step. These activities together compose a “Workflow.” Each card follows the flow until it reaches the last stage, which is “Done/Completion.” Any Kanban workflow can be as simple as “To Do,” “In Progress,” “Complete.”

  Cards (items to represent a task) :

The most remarkable thing that makes it different about the Kanban board is visual cards/Signals (stickies, tickets, screenshots). One card usually has one work item written by the Kanban team. When the team starts working, and the Project Manager ensures that the board is updated, visual cards make teammates understand, what their team is working on and what stands finished.

 Work In Progress 

(WIP)

 Limits:

as the name suggests “WIP limits” is used to limit “work in progress” tasks. It’s a maximum number of cards that can be present in one column at any given time. For example, if there is a column that has a WIP limit of five, then that particular column can’t have more than five cards. These WIP limits are critical as they control the workflow and give you an early warning sign that you committed to too much work.

 Commitment point:

Kanban teams often have a backlog for their board. The backlog is nothing but a column where customers and teammates put their ideas for projects that the team can pick up from and prepare their To-Do list. The commitment point is the moment when an idea is picked up by the team, and they start working on that particular task.

 Delivery Point:

The delivery point is the last point of a Kanban team’s workflow. It’s the point when the service, software, or product gets delivered to the customer. The team’s goal is to pick up cards from the commitment point to the delivery point at the earliest.

  Basic Kanban Board Workflow

As we familiarized ourselves with artifacts so let’s try to understand the workflow of a basic K-Board

·         In the above picture – tasks listed under the “Stories” column act as a Backlog for the team.

·         Four columns (Stories, To Do’s, Doing, Done) are called lists.

·         The tasks which are picked up by the team from the “Stories” column to work upon move to the To Do’s list. This Process of picking up stories from backlog and moving them to To Do’s is called Commitment Point.

·         As and when the team starts working on a task, it moves to the “Doing” column.

·         Stickies, pictures, and comments are called Visual Cards.

·         There is a limit of tasks that can be there in “Doing,” and that the limit is known as “WIP limits.”

·         And finally, when the task gets finished & it moves to Done from Doing, that moment will be called Delivery Point.

 Board Example

 for Software Development:

In software development, we can have the following columns-

·         Analyze

·         Design

·         Develop

·         Test

·         Deploy

Note – A task can pass through as many columns as your chosen workflow allows.

For any new software development, there is a to-do list of activities; then the development team might pull items from To-Do to in-progress and move them to Work in progress, this is called the Pull system. In WIP, they will analyze it, design, and develop it, and the test team will complete Testing and move them to Deploy.

There are five values of Extreme programming

1. Communication:

Communication is the most crucial part of any project. Proper communication is needed to fill the gaps between what the developer is making and the customer requirement. It will help in reducing rework if we know the exact condition. In addition to that, proper communication within the team (the developers) is also needed to ensure that they all are on the same page.

For instance, let’s say in a restaurant if a customer tells the waiter specifically that he wants his dish to be

·         Less oily

·         Mildly spicy

·         Less salty due to medical reasons.

But the waiter tells the chef to make the dish less spicy. After that, when the meal arrives, it gets rejected by the customer, the reason being; it had oil and the usual amount of salt too. And the chef had to cook it again. All because there was no proper communication between the waiter and the chef.

 2. Simplicity:

As per Wikipedia, we need to start developing the most straightforward features first, and then later, we should move to the problematic and extra functionalities. It should be simple, and we should work on the need at the moment. In addition to the above, we must not worry about future requirements and should not make it complicated, assuming that this feature might be needed later. The developers and testers will easily understand simple code and design.

For instance, when the chef has multiple orders, then he always starts with whatever he finds comfortable and is confident that he can cook well.

Like, during exams, we were always suggested by our seniors to start with whatever is the simplest.  

 3. Feedback:

Continuous feedback helps you understand how great you are doing. It works as a catalyst for the project. In extreme programming, feedback can come from different sources like

·         Customer: After each iteration, one function will get delivered to the customer who will perform the Acceptance test. Based on acceptance test results, the developers get the feedback and work on it subsequently.

·         System: The main reason for performing the Unit test is to get feedback. When writing the Unit test or performing an Iteration test, they get to know from the state of the system if there are any flaws in the coding.  

·         Within the team: The purpose of forming a team is to help each other and work as one. Whenever the customer comes with a new requirement, the team can provide feedback about estimating the time required & setting up an expectation with them based on their previous experiences.

For instance, developers are like chefs in a restaurant. They should be ready to accept feedback from all the sources in the same vein as a chef can get feedback from the customer, his senior chef, the waiter, or the management.

 4. Courage:

In Software development, courage means:

·         Firstly, to provide confidence to the developers to take brave decisions by understanding all the aspects involved.

·         Secondly, it gives the programmer confidence and enables the programmer to refactor (re-use) the used code, as and when needed. In other words, the developer reviews the current code and changes or modifies it to fit for future purposes.

·         In addition to the above, it supports lead developers in deciding to make the rest of the developers work more efficiently. For example, when a programmer gets trapped in a difficult problem for an entire day, he may prefer to take a break and solve it quickly the next day. However, it will be possible only if he is persistent.

For instance, in a restaurant, the chef is responsible for deciding the ingredients, the time of cooking, and the spice. It is the kind of faith that the team shows in the chef and gives him the courage to make his own decisions.

 5. Respect:

In Extreme programming, everyone respects each other.

·         Respect is the base of all four values.

·         We can gain respect by adopting above for values in the system.

·         Moreover, this value is more about teamwork.

·         To sum up, this value is dependent on the above four values.

What are the Characteristics of the Development Team?

We have got a good hold of the responsibilities of the development team. Let’s discuss the characteristics that the development team needs to exhibit so they can fulfill these responsibilities. According to Wikipedia, the following are some of the characteristics of the Scrum Development Team:-

· Self Organizing – One of the critical characteristics of the development team is that they self organize. What this means is no one tells them how to achieve the sprint goal. They organize themselves and figure this out.

· Cross-Functional – Development teams in Scrum need to be Cross-functional. Together, they should possess all the skills necessary to complete the sprint goal.

· Without Title – Have you heard about the Leader who had no title? The same applies to the Scrum team. Every member of the team (except Scrum Master and Product Owner) is a development team member. There are no further titles given irrespective of the work they do within Sprint.

· No Sub Teams – Scrum doesn’t create any sub-teams within the development team. There is no concept of a testing team, dev team, UI team, or an architecture team.

· T Shaped Skills – An ideal development team has always got T Shaped Skills. It means that there is always one skill (like Java, UI development, testing, etc.) where they have acquired in-depth knowledge (Experts).

· Team Accountability – All the members of the development team have a musketeer attitude – All for one and one for all.

· High Bandwidth and Transparent Communication – Development team members need to communicate amongst themselves and also with Scrum Master and Product Owner. Communication should also be transparent. It means telling the status correctly in the daily scrum meeting, so there is no ambiguity in status. Additionally, one should highlight any issues and suggestions without hiding any information.

· Focused and Committed – You cannot achieve the sprint goal unless every member of the team is focused and committed to getting it done.

· Sustainable Pace – One of the critical principles of Scrum is that the team works at a Sustainable pace. It means that they take the work that they can accomplish in a sprint, rather than being given an unrealistic goal by managers.

What’s the ideal size of the Development Team?

Scrum prescribes that the ideal team size is between 3 – 9 team members (3 and 9 inclusive). It doesn’t include the Scrum Master and Product owners unless they are also executing the work of the sprint backlog (which is pretty rare)

So what’s the logic for this range? It’s quite simple! A team size of less than three will not be cross-functional. They might not have all the skillset required to get the sprint work done.

Introduction

Each programming language has a fundamental need to store data in memory for doing some computations on that data. Now to store and access this data, the memory location needs a name, and this name is called “Variable.”

In other words, Variable means anything that can change/ vary. JavaScript includes variables that hold the data value and it can be changed anytime.

Definition

Variables are just the name of the storage location. Moreover, we can also call them as containers that hold some data during the program execution.

According to Wikipedia, Variables in standard JavaScript have no type attached, and any value can be stored in any variable. Starting with ES6, the version of the language finalized in 2015, variables can be declared with let (for a block-level variable), var (for a function level variable) or const (for an immutable one). However, while the object assigned to a const cannot be changed, its properties can.

In other words, Variable means anything that can change/ vary. JavaScript includes variables that hold the data value and it can be changed anytime. It’s also beautifully explained here.

Subsequently, let’s understand the concept in more detail with the help of the following examples:

In the above example, “digit” is a variable which points to a memory location which holds/stores the numeric value “12”. Similarly, “lang” is a variable which points to the memory location which stores the string value “javascript.” So we can say that a variable is just a name to the memory location, where the value will be stored.

In addition to the above, JavaScript uses reserved keyword var to declare a variable. A variable must have a unique name. You can assign a value to a variable using equal to (=) operator when you declare it or before using it.

SYNTAX

Let’s look at its syntax below:

Syntax:

var <variable-name>; var <variable-name> = <value>;

Example: Variable Declaration & Initialization

var one = 1; // variable stores numeric value var two = 'two';  // variable stores string value var three;  // declared a variable without assigning a value

In the above example, we have declared three variables using var keyword: one, two, and three. We have assigned values to variables one and two at the same time when we declared it, whereas variable three is declared but does not hold any value yet. Therefore, it's value will be 'undefined'.

Declare Variables in a Single Line

Multiple variables can also be declared in a single line separated by a comma.

Example: Multiple Variables in a Single Line

var one = 1, two = 'two', three;

Declare a Variable without var Keyword

JavaScript allows variable declaration without var keyword. You must assign a value when you declare a variable without var keyword.

For example:

Variable without var Keyword

one = 1; two = 'two';

Point to Remember:

It is Not Recommended to declare a variable without var keyword. It can accidentally overwrite an existing global variable.

The scope of the variables declared without a var keyword becomes global irrespective of where it is declared. Global variables can be accessed from anywhere on the web page.

Visit the Scope of Variables for more information.

Key Takeaways:

1. Variable stores a single data value that can be changed later.

2. Variables can be defined using the var keyword. Variables defined without var keyword become global variables.

3. Variables must be initialized before using them.

4. Multiple variables can be defined in a single line. e.g. var one = 1, two = 2, three = "three";