Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Functional Continuous Integration with Selenium and Hudson

This slide deck illustrates Constant Contact's approach to running sets of regression test suites on a regular schedule using SeleniumRC and Hudson. Hudson is a continuous integration server designed for building applications and running unit test unattended, and storing run report and metric artifacts. Hudson can also process a variety of different types of jobs, including running SeleniumRC Java test cases using JUnit as the test runner. SeleniumRC can be run unattended on multiple slave computers in parallel, each running SeleniumRC, to quickly run through many test cases.

Related Books

Free with a 30 day trial from Scribd

See all

Functional Continuous Integration with Selenium and Hudson

  1. 1. Functional Continuous Integration<br />SeleniumRC and Hudson<br />David Jellison: Director, Quality Engineering<br />Collin Riley: Principal Quality Engineer<br />January 25, 2011<br />
  2. 2. Agenda<br />About US<br />Continuous Integration (CI) Concepts<br />Continuous Integration (CI) Concept<br />Functional Continuous Integration (FCI) Extends the concept<br />SeleniumRC is part of the capability for an FCI strategy<br />Continuous Integration Servers make CI easy<br />Constant Contact FCI Approach<br />Hudson is a rich dashboard to orchestrate traditional CI & FCI<br />How Constant Contact uses Hudson and SeleniumRC for FCI <br />What other pieces are in the FCI framework at Constant Contact <br />Q&A<br />
  3. 3. Speakers<br />David Jellison: Director, Quality Engineering<br />David has 18 years experience in test and development management, and over the last 4.5 years he led agile development and test organizations with .Net, Rails, and Java stacks in SaaS organizations. David is passionate about test leadership and efficient software development practices. He is consistently has his hands in technological and agile practice continuous improvement.<br />Collin Riley: Principal Quality Engineer<br />Collin is the architect of Constant Contact's use of Selenium RC in our Java automation framework utilizing Hudson. This framework integrates with Quality Center, uses page objects, and other scalable features. Collin has 8 years Quality Engineering and automation experience and has been using Selenium RC for over two years.<br />
  4. 4. Who is Constant Contact? (CTCT)<br />Constant Contact Corporate<br />Helps small businesses, associations, and nonprofits connect with their customers, clients, and members. (>400,000 subscribers)<br />Launched in 1998, Constant Contact champions the needs of small organizations and provides them with an easy and affordable way to build successful, lasting customer relationships.<br />Constant Contact Engineering<br />~200 people, ~16 Agile teams (½ product & ½ services)<br />~30 in Quality Engineering, 3:1 Dev:QE<br />SaaS (Software as a Service), Java/JBoss/CentOS/DB2 stack, live up-time deployments to production<br />Practice ScrumBan (blend of Scrum release management and KanBan work item management)<br />Use Java/Groovy test scripts with SeleniumRC and Java libraries for functional tests<br />
  5. 5. CI Concepts<br />
  6. 6. Assumptions<br />Familiar with the following:<br />Selenium Remote Control (SeleniumRC)<br />Agile Practices (what Scrum and eXtreme Programming are)<br />Source Code Repository (e.g. ClearCase, CVS, SVN, Git, etc.)<br />Integrated Development Environment (IDE - e.g. Eclipse)<br />Infrastructure Monitoring (e.g. Nagios)<br />xUnit test runner family (e.g. JUnit, NUnit, Test:Unit etc.)<br />
  7. 7. Continuous Integration<br />“Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.” <br /> – Martin Fowler (<br />Approach (Developer Focused)<br />Developer creates unit tests along with new and re-factored code<br />Developer builds and runs unit tests locally often<br />Developer often commits code to a source code repository that is auto-built, tested, and packaged on a CI server<br />Benefits<br />Significantly reduce integration problems<br />Allows teams to develop cohesive software more rapidly<br />Note: The term ‘Continuous Integration’ was introduced as one of the 12 practices of eXtreme Programming.<br />
  8. 8. Continuous Delivery<br />Deployment Automation<br />Theme of reducing cycle time between idea and usable software<br />Culture of frequent reliable deliveries<br />Configuration management for OS, Server, and Application settings<br />Manifest description of each environment<br />Machines and their allocation of applications<br />Database and resource permissions<br />Load balancer configuration<br />Test Environments<br />Represent configuration of production (manifest for each)<br />Rely on manifest and deployment automation for changes<br />Dedicated CI test environment to validate deployment automation with each change<br />
  9. 9. Functional Continuous Integration (FCI)<br />Prerequisites<br />Continuous Integration (CI) practices<br />Continuous Delivery (Deployment Automation) practices<br />Dedicated CI test environment (minimum configuration)<br />CI Functional Tests<br />Deployment tests that prove a system is properly configured<br />Application smoke tests that prove an application is testable<br />Extend the culture of break-the-build urgency<br />Passing tests can be delivered to test environments or production<br />Failing tests require immediate attention to resolving problems<br />Benefits<br />Robust deployments to stable test environments<br />Frequent deliveries to production<br />Increased release confidence, lowering business risk<br />
  10. 10. Challenges of scaling CI and FCI<br />Multiple Branches<br />Rebasing often (merge back from trunk)<br />Merge back to trunk as often as feasible<br />Multiple repositories<br />Package integration installers often (automated packaging)<br />Package library includes and dependencies carefully<br />Many services and applications<br />Distributed application architecture<br />Clearly defined interfaces (with versioning)<br />Test fixtures (test components in isolation)<br />Health check requests for infrastructure monitoring (e.g. Nagios)<br />Deploy and functional test often<br />Require functional regression tests with new features <br />
  11. 11. Agile Testing<br />Collaborating with Developers<br />Agile Testers collaborate with Developers<br />Developers participate in test planning<br />Testers participate in feature design<br />Testers test as early as code changes are available<br />Domain expertise<br />Traditional and exploratory testing<br />Develop automated test cases<br />Developers work with testers to keep page objects consistent with application pages as code changes are delivered<br />Developers run regression tests prior to check-in<br />Regression tests consistently pass with automated test runs<br />
  12. 12. With passing tests, commit changes<br />Agile Testing<br />QE & Dev work together to create, re-factor, and update functional regression tests<br />Dev deploys to sandbox system<br />QE runs tests against the sandbox<br />Dev updates the application code for problems found – no defects written<br />When all tests are complete and working, Dev commits changes<br />FCI<br />
  13. 13. Constant Contact<br />
  14. 14. Functional Test Needs<br />Test Case Manager (Quality Center)<br />Representation of what is automated & automation runs<br />Test Runner (SeleniumRC / Junit / Page Objects)<br />Browser & OS Testing<br />Scalability<br />Run Manager (Hudson)<br />Push-button runs<br />Parallel test runs<br />Run reporting and artifacts<br />Drill-in Run Reports (internal reporting application)<br />Reporting Application leveraging Quality Center<br />Aggregate run reports<br />Dynamic charts<br />
  15. 15. Choosing Hudson for FCI Dashboard<br />Familiar Java-based server<br />Hudson was already CI server choice by Release Engineering<br />Job flexibility<br />Can configure job parameters, run externally, run a collection of other jobs, produce artifacts, permission levels<br />Job Queuing<br />Can create slave pools to queue many jobs to cycle through the target slave pool<br />Job Agents<br />Control over agent machines<br />Iframe views<br />Can create dashboard applications on a report server and integrate into Hudson views.<br />Support many plug-ins to CI tools<br />
  16. 16. Test Automation Stack<br />
  17. 17. Test Automation Stack<br />
  18. 18. FCI Flow – Authoring Tests<br />Quality Center<br />Add Test Case(s) / Test Plan<br />Test Templates<br />Pull Templates from QC into the Java Framework<br />Write the Test Code <br />Page Object classes<br />Helper methods<br />Web Class<br />Reporting Class<br />Test locally<br />Once Pass, mark in QC for Hudson<br />
  19. 19. FCI Flow – Before Running in Hudson<br />Build the Java Project in Hudson<br />Push to Hudson slaves<br />Java Project Jars<br />Custom Firefox profile<br />Host file entries<br />Restart Selenium Server Instances on Slaves<br />Publish Hudson Jobs<br />Talk to QC and Push Jobs to Hudson<br />Test Plans automated<br />Selenium based<br />Webservice based<br />Run Types<br />
  20. 20. FCI Flow – Running with Hudson<br />Launch a Run<br />Hudson talks to QC for what to run<br />Hudson adds Testplans to the build queue<br />n Number of slaves pull from the queue in parallel<br />Test Plans report back<br />To Hudson<br />Red or Green<br />Archive html report with screenshots<br />Junit output<br />To QC<br />Full results for TestCases Status with framework Run Id<br />Detail info for each step of the TestCase<br />
  21. 21. Running Tests<br />Repository<br />Pool of Win Machines<br />Environment 1<br />Build Test Jar<br />Pool of Apple Machines<br />Smoke Daily<br />QC<br />Suite 01<br />Suite 02<br />Suite 03<br />Suite 04<br />
  22. 22. Reporting<br />View Reporting<br />Via a simple Java web application integrated into Hudson<br />View Aggregate reporting for all TestPlans in a Run<br />Graphing<br />Trends, Pies<br />Drill in grid based reports<br />Compare run over past runs<br />Act on Reporting<br />After Failure is investigated<br />Mark Failure as Known<br />Defect<br />Script Issue<br />Configuration Issue<br />
  23. 23. Run Results<br />Wiki regression status charts<br />Email drill-in grid report <br />
  24. 24. Drill into run comparison grid & detail report<br />
  25. 25. Q&A<br />
  26. 26.<br />Quality Engineering<br />Senior Quality Engineer - Event Marketing - Waltham, MA<br />Senior Quality Engineer - Contact Management - Waltham, MA<br />Senior Quality Engineer - Scalable Infrastructure - Waltham, MA<br />Senior Quality Engineer - Web Services - Waltham, MA<br />Software Development<br />Principal Software Engineer - Online Survey - Waltham, MA<br />Principal Software Engineer - Website - Waltham, MA<br />Principal Software Engineer, Social Media - San Francisco, CA<br />Senior Software Engineer - Event Marketing - Waltham, MA<br />Senior Software Engineer - San Francisco, CA<br />Senior Software Engineer - Waltham, MA<br />Senior Software Engineer - Waltham, MA<br />Senior Software Engineer - Waltham, MA<br />Software Development Manager - Waltham, MA<br />Software Engineer - Waltham, MA<br />Software Engineer - Social Media - San Francisco, CA<br />