Top 10 points Before Start Test Automation

Launch Firefox browser with Gecko Driver and Selenium 3

As Selenium 3 has launched, firefox browser initialisation became the most common problem among the Selenium testers. Selenium 3 does not support default Firefox with in it.


What is Gecko Driver

Gecko Driver is the link between your tests in Selenium and the Firefox browser. GeckoDriver is a proxy for using W3C WebDriver-compatible clients to interact with Gecko-based browsers i.e. Mozilla Firefox in this case. As Selenium 3 will not have any native implementation of FF, we have to direct all the driver commands through Gecko Driver.



Marionette (the next generation of FirefoxDriver) is turned on by default from Selenium 3. Even if you are working with older versions of Firefox browser, Selenium 3 expects you to set path to the driver executable by the webdriver.gecko.driver.

Click here For more details on Marionette

Lets take example

Code Sample without Gecko Driver and Selenium 3

import org.openqa.selenium.WebDriver;

import org.openqa.selenium.firefox.FirefoxDriver;

public class TestSelenium3 {

public static void main(String[] args) {

WebDriver driver = new FirefoxDriver();

driver.get("https://www.google.com");

}

}

"java.lang.IllegalStateException: The path to the driver executable must be set by the webdriver.gecko.driver system property;" 

So to Run above code you need to first download Gecko Driver from Github.
Download Gecko Driver

After download extract zip file to some specific folder and copy that path. Now in selenium code set the system property for that Gecko Driver and give path actual Gecko driver as below.

System.setProperty("webdriver.gecko.driver", 

geckodriverpath+"geckodriver.exe");
DesiredCapabilities capabilities=DesiredCapabilities.firefox();
capabilities.setCapability("marionette", true);
WebDriver driver = new FirefoxDriver(capabilities);

So new selenium code is as below.

import org.openqa.selenium.WebDriver;

import org.openqa.selenium.firefox.FirefoxDriver;

public class TestSelenium3 {

public static void main(String[] args) {

System.setProperty("webdriver.gecko.driver","/Users/username/Downloads/geckodriver"); // Set Gecko driver path
DesiredCapabilities capabilities = DesiredCapabilities.firefox();
capabilities.setCapability("marionette", true);
WebDriver driver = new FirefoxDriver(capabilities);

driver.get("https://www.google.com");

}

}

Above solution will work for you. Happy testing 😎😎😎.

Scrum workflow and Scrum Roles in Organization

Scrum workflow

Any scrum workflow is very easy and it can be easily understand from below figure. For any scrum first phase is sprint planning of requirement and then it will go through team and review.

Scrum roles fall into two broad categories:

Core Roles

Core roles are those roles which are mandatorily required for producing the project’s product or service. Individuals who are assigned core roles are fully committed to the project and are ultimately responsible for the success of each project iteration and of the project as a whole.

These roles include:

The Product Owner

Is the person responsible for achieving maximum business value for the project. He or she is also responsible for articulating customer requirements and maintaining business justification for the project. The Product Owner represents the Voice of the Customer. 


The Scrum Master

Is a facilitator who ensures that the Scrum Team is provided with an environment conducive to complete the project successfully. The Scrum Master guides, facilitates, and teaches Scrum practices to everyone involved in the project; clears impediments for the team; and, ensures that Scrum processes are being followed. 


The Scrum Team

Is the group or team of people who are responsible for understanding the requirements specified by the Product Owner and creating the Deliverables of the project. 


 

Non-core Roles

Non-core roles are those roles which are not mandatorily required for the Scrum project and may include team members who are interested in the project. They have no formal role in the project team and may interface with the team, but may not be responsible for the success of the project. The non-core roles should be taken into account in any Scrum project.

Non-core roles include the following:

Stakeholder(s)

Which is a collective term that includes customers, users, and sponsors, frequently interface with the Scrum Core Team, and influence the project throughout the project’s development. Most importantly, it is for the stakeholders that the project produces the collaborative benefits. 


Vendors

Including external individuals or organizations, provide products and/or services that are not within the core competencies of the project organization. 


Chief Product Owner

Is a role in bigger projects with multiple Scrum Teams. This role is responsible for facilitating the work of multiple Product Owners, and maintaining business justification for the larger project. 


Chief Scrum Master

Is responsible to coordinate Scrum-related activities in large projects, which may require multiple Scrum Teams to work in parallel. 


Scrum Aspects - Agile Methodology

Scrum Aspects

The Scrum aspects must be addressed and managed throughout a Scrum project 

 

Organization— Understanding defined roles and responsibilities in a Scrum project is very important for ensuring the successful implementation of Scrum.

Business Justification— It is important for an organization to perform a proper business assessment prior to starting any project. This helps key decision makers understand the business need for a change or for a new product or service, the

Quality— In Scrum, quality is defined as the ability of the completed product or deliverables to meet the Acceptance Criteria and achieve the business value expected by the customer.

Change— Every project, regardless of its method or framework used, is exposed to change. It is imperative that project team members understand that the Scrum development processes are designed to embrace change. Organizations should try to maximize the benefits that arise from change and minimize any negative impacts.

Risk— Risk is defined as an uncertain event or set of events that can affect the objectives of a project and may contribute to its success or failure. Risks that are likely to have a positive impact on the project are referred to as opportunities, whereas threats are risks that could affect the project in a negative manner. Managing risk must be done proactively, and it is an iterative process that should begin at project initiation and continue throughout the project’s lifecycle.

Scrum Process - Agile Methodology

 Scrum Process

Scrum processes address the specific activities and flow of a Scrum project. In total there are nineteen processes, which are grouped into five phase.

Initiate

1.Create Project Vision—In this process, the Project Business Case is reviewed to create a Project Vision Statement that will serve as the inspiration and provide focus for the entire project. The Product Owner is identified in this process. 


2.Identify Scrum Master and Stakeholder(s)—In this process, the Scrum Master and Stakeholders are identified using specific Selection Criteria. 


3.Form Scrum Team—In this process, Scrum Team members are identified. Normally the Product Owner has the primary responsibility of selecting team members, but often does so in collaboration with the Scrum Master. 


4.Develop Epic(s)—In this process, the Project Vision Statement serves as the basis for developing Epics. User Group Meetings may be held to discuss appropriate Epics. 


5.Create Prioritized Product Backlog—In this process, Epic(s) are refined, elaborated, and then prioritized to create a Prioritized Product Backlog for the project. The Done Criteria is also established at this point. 


6.Conduct Release Planning—In this process, the Scrum Core Team reviews the User Stories in the Prioritized Product Backlog to develop a Release Planning Schedule, which is essentially a phased deployment schedule that can be shared with the project stakeholders. Length of Sprint is also determined in this process.

Plan and Estimate

7.Create User Stories—In this process, User Stories and their related User Story Acceptance Criteria are created. User Stories are usually written by the Product Owner and are designed to ensure that the customer’s requirements are clearly depicted and can be fully understood by all stakeholders. User Story Writing Exercises may be held which involves Scrum Team members creating the User Stories. User Stories are incorporated into the Prioritized Product Backlog. 


8.Approve, Estimate, and Commit User Stories—In this process, the Product Owner approves User Stories for a Sprint. Then, the Scrum Master and Scrum Team estimate the effort required to develop the functionality described in each User Story, and the Scrum Team commits to deliver the customer requirements in the form of Approved, Estimated, and Committed User Stories. 


9.Create Tasks—In this process, the Approved, Estimated, and Committed User Stories are broken down into specific tasks and compiled into a Task List. Often a Task Planning Meeting is held for this purpose. 


10. Estimate Tasks—In this process, the Scrum Core Team, in Task Estimation Meetings, estimate the effort required to accomplish each task in the Task List. The result of this process is an Effort Estimated Task List. 


11. Create Sprint Backlog—In this process, the Scrum Core Team holds Sprint Planning Meetings where the group creates a Sprint Backlog containing all tasks to be completed in the Sprint. 


Implement

12. Create Deliverables—In this process, the Scrum Team works on the tasks in the Sprint Backlog to create Sprint Deliverables. A Scrumboard is often used to track the work and activities being carried out. Issues or problems being faced by the Scrum Team could be updated in an Impediment Log. 


13. Conduct Daily Standup—In this process, everyday a highly focused, Time-boxed meeting is conducted referred to as the Daily Standup Meeting. This is the forum for the Scrum Team to update each other on their progress and any impediments they may be facing. 


14. Groom Prioritized Product Backlog—In this process, the Prioritized Product Backlog is continuously updated and maintained. A Prioritized Product Backlog Review Meeting may be held, in which any changes or updates to the backlog are discussed and incorporated into the Prioritized Product Backlog as appropriate. 


Review and Retrospect

15. Convene Scrum of Scrums—In this process, Scrum Team representatives convene for Scrum of Scrums (SoS) Meetings in predetermined intervals or whenever required to collaborate and track their respective progress, impediments, and dependencies across teams. This is relevant only for large projects where multiple Scrum Teams are involved. 


16. Demonstrate and Validate Sprint—In this process, the Scrum Team demonstrates the Sprint Deliverables to the Product Owner and relevant stakeholders in a Sprint Review Meeting. The purpose of this meeting is to secure approval and acceptance from the Product Owner for the Deliverables created in the Sprint. 


17. Retrospect Sprint—In this process, the Scrum Master and Scrum Team meet to discuss the lessons learned throughout the Sprint. This information is documented as lessons learned which can be applied to future Sprints. Often, as a result of this discussion, there may be Agreed Actionable Improvements or Updated Scrum Guidance Body Recommendations. 


Release 

18.   Ship Deliverables—In this process, Accepted Deliverables are delivered or transitioned to the relevant stakeholders. A formal Working Deliverables Agreement documents the successful completion of the Sprint.

19. Retrospect Project—In this process, which completes the project, organizational stakeholders and Scrum Core Team members assemble to retrospect the project and identify, document, and internalize the lessons learned. Often, these lessons lead to the documentation of Agreed Actionable Improvements, to be implemented in future projects.

 

Scrum Principles - Agile Methodology

Scrum Principles 

Scrum principles are the core guidelines for applying the Scrum stratergy and should mandatory be used in all Scrum projects.

 

Scrum principles can be applied to any type of project in any organization and must be adhered to in order to ensure effective implementation of the Scrum framework. Take a brief of below principle.

Empirical Process Control—This principle emphasizes the core philosophy of Scrum based on the three main ideas of transparency, inspection, and adaptation. 


Self-organization—This principle focuses on today’s workers, who deliver significantly greater value when self-organized and this results in better team buy-in and shared ownership; and an innovative and creative environment which is more conducive for growth. 


Collaboration—This principle focuses on the three core dimensions related to collaborative work: awareness, articulation, and appropriation. It also advocates project management as a shared value-creation process with teams working and interacting together to deliver the greatest value. 


Value-based Prioritization—This principle highlights the focus of Scrum to deliver maximum business value, from early in the project and continuing throughout. 


Time-boxing—This principle describes how time is considered a limiting constraint in Scrum, and used to help effectively manage project planning and execution. Time-boxed elements in Scrum include Sprints, Daily Standup Meetings, Sprint Planning Meetings, and Sprint Review Meetings. 


Iterative Development—This principle defines iterative development and emphasizes how to better manage changes and build products that satisfy customer needs. It also delineates the Product Owner and organization’s responsibilities related to iterative development. 


 

API Automation with postman : Pass Data file in runner

 We go through the collection feature of postman.

Lets start basic usage of collection in runner. To run a collection, open the Collection Runner window by clicking on the link in the navigation bar. Choose a collection from the drop down menu, and hit Start.

 

So this way you can iterate your collection as many time as you want. So your collection run multiple time as you set value in iteration field.

Second thing is you can run your collection by giving csv or json file to pass your data in your API collection. The Collection Runner let’s you import a CSV or a JSON file and then use the values from the data file inside HTTP requests and scripts. We call these variables data variables. To use them inside the Postman UI, you have to follow the same syntax as environment or global variables. Having the same syntax helps you test individual requests inside Postman using dummy environment values. When you move to the Collection Runner you don’t have to change anything.

Data variables in requests

Variables inside the Postman UI are enclosed inside curly braces. For example, in the screenshot below, {{username}} and {{password}} inside URL parameters would be replaced by corresponding values from the data file:

So like this way you can also pass data to the API and run your collection with different data value.

CSV files

For CSV files to work inside the Collection Runner, the first row needs to consist of variable names that you want to use inside requests. Every subsequent row is used as a data row. Make sure the line endings of the CSV file are in the Unix format. That’s a restriction in our current CSV parser.

JSON files

The JSON file needs to be an array of key/value pairs. The keys are used as variable names while the values are replaced inside requests.

For more information you can check  Using CSV data file post in postman blog.