The download file will come as a .zip file. You can create a folder on your computer called: C:\Selenium and extract the contents of the download there. This will contain all the needed files that will be used to configure Selenium. Once you extract the files it will look like this:
Step 4-Configure Eclipse with Selenium WebDriver
Go to the location where you extracted the zip file. It will contain an executable called eclipse.exe. You might also see a shortcut on your desktop that looks like:
Double click on the Eclipse shortcut and it will launch Eclipse. You can use the location listed, and click on Launch.
Once the screen is launched, click on Create a New Java Project
The following window will appear. For the project name you can call it myfirstproject. You can use the other defaults listed and click the Finish button.
The following window will appear. Click on the Create button.
The following screen appears:
Right click on myfirstproject and select New and then Package.
The following window will appear. Name the new package mypackage and click on the Finish button.
Right click on myfirstpackage and select New then Class
The following window will appear. Under name enter myfirstjavaclass and click the Finish button.
For the next step, right click on myfirstproject and select Properties
On the properties window, select Java Build Path then Libraries tab then Add External JARS…
The JAR Selection window will appear. Go to the location where you installed the Selenium files on your computer. Mine is installed at: C:\Selenium.
Double click on the libs folder
Select all the files and click the open button.
You will see all the files you selected displayed. Click on Add External JARS.. button again
The JAR Selection window will appear. Select all files there and click on Open.
On the Properties window, click on the Apply and Close button.
You will now see the Referenced Libraries displayed.
The Selenium WebDriver configuration is finished. I hope this information has been helpful. Don’t forget when you create a new project, you will need to import these files again. In order to run your scripts you will need to determine which browsers you plan on using.
You can click here to learn how to setup the different browsers.
Open sourced software testing code allows anyone to use this tool with no software licensing costs
Is used to test web based applications
It has a very strong community because many software testers use it
It can be used with popular software programming languages such as Java and Python
Runs on many different browsers across different operating systems
Can easily be integrated and leveraged with other tools
Only used for web based applications, so it will not support automation of mainframe or AS400 applications
Is supported by the community, so there is no central company that owns the code or provides updates
Selenium Grid: Is a tool that enables parallel test execution across multiple machines and browsers at the same time. This saves a lot of time and helps you get through large regression suites.
Let’s face it, Agile has some tremendous benefits. If you are practicing agile at your company, you know that firsthand. Agile also has some pitfalls that can be extremely deadly if they are not addressed properly. Most of us have learned how to avoid them by implementing costly mistakes.
Sure there are other things that agile has issues with, but we will cover those in subsequent agile posts.
Using the agile methodology, software can be developed very quickly, in fact, business needs demand it is produced as quick as possible. While there is nothing inherently wrong with that, it is important to develop it efficiently. Agile teams want to build the best designed and highest quality product possible. However, that isn’t always what happens. My team has recently been involved in leveraging a COTS product called Globalscape to consolidate all our B2B file transfer systems into a single solution. In fact, our company was acquired, so between both legacy companies we had four solutions which were being used. We selected Globalscape, but the product was brand new to our team. We didn’t have extensive experience but were driven to move off the other systems. We made the best decisions that we knew at the time, but looking back, there were some things that if we had better information and experience with the product, we would have certainly done differently. Naturally, we accumulated technical debt, and we created stories in our backlog to handle those. In certain sprints, we had to put more technical stories in place to implement the necessary changes. While our business partners weren’t thrilled, they understood those needed to be done.
In some situations, you can address technical debt issues as you are addressing stories in the backlog. For example, with our file transfer product, we created a generic function to address how email notifications were delivered, which was much more efficient. While we were moving other B2B files into the new platform, we would go ahead and make those changes, so that we would not have to revert and make those technical debt changes later.
It is also a good idea to keep 5 to 10 percent of your sprint capacity available to handle technical debt issues. If you have one story per sprint handling technical debt, then it will make it a lot easier in not having to deal with too much technical debt later.
Hopefully this real world example will help you avoid Agile Pitfall #2: Too Much Technical Debt!
Agile Software Testing has literally transformed the role of an Agile QA Engineer. There are several key differences which software testing organizations will need to adjust in order to effectively operate with Agile.
Documentation: It isn’t practical within Agile for the Agile QA Engineer to have lots of documentation. Don’t get me wrong, there does need to be sufficient documentation for the QA Engineers to do their job well. If a developer tries to convince you that the Agile Manifesto doesn’t require documentation, Houston we have a problem!
In terms of requirements, there needs to be enough documentation that the Agile QA Engineer knows how the system is supposed to operate. In my team, we currently use a 1 page document that will provide that information for each story. It really does help the agile testers know what is expected so they can adequately plan.
For the Software Test Plan, it isn’t necessary to go through all the hoopla of creating a massive plan that nobody will read or follow. A one page document will be sufficient. I encourage the creation of the one page plan because it forces the agile tester to think about what testing is needed.
For the testing sign off a simple email will suffice.
Test Automation: One of the hottest topics naturally is test automation, especially within Agile software testing. Test automation without a doubt is critical. However, there needs to be a strategy that is going to work. In previous organizations, I have built world class automation teams. We had thousands of automated test cases within our regression suites. Were all those tests necessary, probably not. Was it expensive to maintain, absolutely! I believe having a centralized automation team that can build and execute the automation tests is most effective. The team prioritizes the work based upon the needs of the various agile teams. I have found this to work most effectively. I usually recommend that the agile testers execute the tests within the current sprint and once those have passed, they can hand that off to the agile team to automate and put in the regression suite. Having an Agile QA Engineer do both the functional and automated tests within a given sprint is extremely challenging and often the functional testing gets done and the automation gets put on the back burner.
Performance Testing: Another challenge is system performance. If automation takes a back seat, then performance testing is usually behind that. In order to deal with that challenge, having a centralized performance team will help. Usually 2-3 performance engineers will be sufficient. I encourage a very close look at performance testing within the Agile context. If you don’t need it, don’t do it, if you need it, you better do it.
UI versus Web Service: Agile software testing requires some fundamental changes in terms of how things get tested. More and more agile software testing is taking a closer look at web service testing. It is a critical component that can find a lot of defects. The need for agile teams to focus on spending more time in this area is due to the amount of applications that are using API’s to transfer information. It is a lot quicker to run hundreds of transactions through an API versus through the UI. Agile software testing teams who are able to make this transition are simply more effective.
Let’s face it, transforming your software testing organization is going to be very challenging. Agile software testing is extremely challenging. The key is to have a strong team who is flexible and is adaptable to constant change. The teams that can do that most effectively will be successful.
»DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market.
»Under a DevOps model, development and operations teams are no longer “siloed.” Sometimes, these two teams are merged into a single team where the engineers work across the entire application lifecycle, from development and test to deployment to operations, and develop a range of skills not limited to a single function. and security teams may also become more tightly integrated with development and operations and throughout the application lifecycle.
»These teams use practices to automate processes that historically have been manual and slow. They use a technology stack and tooling which help them operate and evolve applications quickly and reliably. These tools also help engineers independently accomplish tasks (for example, deploying code or provisioning infrastructure) that normally would have required help from other teams, and this further increases a team’s velocity.
»2008- Patrick Debois helps plant the seeds of the DevOps movement at the Agile conference in Toronto
»2009-O’Reilly Velocity Conference—John Allspaw and Paul Hammond deliver a seminal talk known as “10+ Deploys per Day”
»2009-Debois launches the first Devopsdays event, in Ghent, Belgium
»2010-The first US Devopsdays is organized, with the help of Willis as well as other early DevOps proponents like Damon Edwards and Andrew Clay Shafer
»2011- Cameron Haight from Gartner, among others, predicts that by 2015, 20 percent of global 2000 businesses will embrace DevOps.
»2012-various Devopsdays are suddenly popping up around the world, from Bangalore to Boston.
»2013-Various DevOps books emerge: Phoenix Project (Kim), Implementing Lean Software Development” (Poppendiek), The Lean Startup (Ries), Web Operations (Allspaw), Continuous Delivery, (Humble and David Farley) and The Goal (Goldratt)
»2014-DevOps crosses into the enterprise, and established brands like Target, Nordstrom and LEGO embrace the movement. In a survey by Puppet Labs, IT Revolution Press and ThoughtWorks, 16 percent of 1,485 respondents say they are part of a DevOps effort within their organization.
It is important that your QA organization has the necessary items to be successful. Perhaps the most important element is the organization is able to protect the production environment. Here are a few items that are required.
Ensure you have Executive level support. This is the most important items. Without having your executive to support the QA organization when there is a quality concern, delivery will always win.
Reduce the testing cycle time. Another important item, is to make sure your organization is doing what it can to reduce the amount of time spent during test execution. The best thing that can be done is to focus automating your regression suite.
Shift Left. Focus more time getting involved up front and identifying issues with requirements and other documentation.
Focus on Planning. Make sure the QA organization is covering all the bases and spending sufficient time planning.