Selenium: Learn More

What is Selenium

What is Selenium?

If you are in the software testing profession, one of the most often asked questions is What is Selenium?   Simply put Selenium is an open sourced software testing code.  It is becoming more and more popular everyday, and it is fairly easy to learn.  It was created by Jason Huggins in 2004.   He had a need to perform testing on a web application, so he decided to create a JavaScript based tool that could simulate manual testing activities.   The original name was JavaScriptTestRunner.  I am going to walk you through the process learning more about the code and the pros and cons of leveraging this capability.

Benefits

  • 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

Disadvantages

  • 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

Components

  • Selenium WebDriver: is a collection of language bindings to drive actions within the web browser.   If you need to create a series of web based test automation scripts you will need to use Web Driver. If you want to learn how to install Java and Selenium WebDriver click here.
  • Selenium IDE: is an integrated development environment.  It is the simplest component of Selenium that allows you to perform record and playback of test scripts. The Selenium IDE is a Firefox add-in that is easy to install and setup.  This helps to uncover defects quickly when you want to use repetitive processes to ensure that nothing breaks when software is changed.  This tool should only be used to quickly record and prototype things to make sure it is going to work.  It will be helpful to know some simple concepts of HTML, JavaScript and DOM(Document Object Model) in order to have a solid foundation on how the tool works. If you need more complex scripting, then you will need to use Selenium Web Driver.
  • 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.

Click here for additional information on Selenium.

There are also some Big Changes in Selenium 4.

For the official website you can visit Selenium HQ.

 

Agile Pitfall #2: Too Much Technical Debt

agile technical debtLet’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.

 

 

 

Agile Pitfall #1: Lack of Integrated Software Testing

Agile Pitfall #2: Too Much Technical Debt

Agile Pitfall #3: Agile Team Silos

Agile Pitfall #4: Too Focused on Agile Team Roles

Agile Pitfall #5: Folks, It Isn’t All About Velocity!

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!

Role of an Agile QA Engineer

Agile QA EngineerAgile 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 101: Learn all about DevOps

What is DevOps?

DevOps»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.


DevOps Benefits

Here are some DevOps benefits:

  • Speed: Move faster as a team so there will  be more product produced
  • Quality: Develop higher quality products with faster feedback loops resulting in continuous quality deliveries
  • Collaboration: Smaller teams work more efficiently together and eliminate organizational silos
  • Scale: Manage development and infrastructure leveraging automation to accelerate productivity
  • Security: Using a DevOps model companies can ensure security compliance

Developing a Quality DevOps Mindset

»Customer is #1

»Frequent delivery of a working software product

»Develop a quality product over production delivery

»Keep technical debt at a minimum

»Constant communication with all team members

»Keep things simple as possible

»Hold meaningful and actionable retrospective sessions

»Automate as much as possible


DevOps Myths

»DevOps will fix everything

»DevOps is for Developers and Operations only

»DevOps only involves automating processes

»DevOps only uses “Cloud

»DevOps only uses new languages and technologies

»DevOps is only for web based systems

»DevOps is only used by small companies

»DevOps is not necessary for my organization


DevOps History

»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.

2016-DevOps is now mainstream


DevOps Goals

»Build repeatable processes and high quality software

»Automate everything

»Definition of Done

»Reduce Risk

»Collaborative Ownership-Everyone is responsible

»Constant communication

»Continuous Improvements

I hope this information has been helpful. I also have a DevOps 101 video. and a DevOps 201 video.

If you would like more information on Agile, DevOps or Software Testing, please visit my Software Testing Blog or my Software Testing YouTube Channel.

Software Quality over Delivery

Software Quality over Delivery

software qualityIt 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.

  1.  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.
  2. 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.
  3. Shift Left.  Focus more time getting involved up front and identifying issues with requirements and other documentation.
  4. Focus on Planning.  Make sure the QA organization is covering all the bases and spending sufficient time planning.

If you would like more information on Agile, DevOps or Software Testing, please visit my Software Testing Blog or my Software Testing YouTube Channel.

 

 

QA Revolution YouTube Channel

If you would like more information on Agile, DevOps or Software Testing, please visit my Software Testing Blog or my Software Testing YouTube Channel.