Improving Wetware

Because technology is never the issue

Upgrading from Selenium to Playwright

Posted by Pete McBreen 16 Sep 2021 at 22:37

For a long time Selenium has been the default option for writing automated browser tests, but there are alternatives now available. One leading contender is Playwright, and while it does not have as much language support as Selenium, it does cover the main options (JavaScript, Python, Java and .Net) while providing full browser support.

With a large suite of automated Selenium tests, it might not make much sense to rewrite existing tests to use Playwright, but for new test suites it might make sense to switch over to Playwright. It has better affordances for testing, has easy control over the browser contexts without that getting in the way for normal usage and deals with single page applications and websockets. The python samples below are equivalent


import pytest
from playwright.sync_api import sync_playwright

def browser():
    playwright = sync_playwright().start()
    browser = playwright.chromium.launch()  # use params headless=False to see browser

    yield browser


def test_blog_title(browser):
    page = browser.new_page()

    # find the blog link in the header and then click on that link"#main_navbar :text('blog')")
    title = page.title()
    assert title.startswith("Blog | Selenium"), title

    h1text = page.wait_for_selector('h1')
    assert h1text.inner_text() == "Selenium Blog"


import pytest
from selenium import webdriver
from import By

def webbrowser():
    firefox = webdriver.Firefox() # default is to show the browser, use options to make headless
    yield firefox

def test_blog_title(webbrowser):


    # want the blog link from header, so two stage process to get correct element
    header = webbrowser.find_element(By.ID,'main_navbar')
    blog = header.find_element(By.PARTIAL_LINK_TEXT , 'Blog')

    title = webbrowser.title
    assert "Blog | Selenium" in title, title

    assert webbrowser.find_element(By.CSS_SELECTOR, 'h1').text == "Selenium Blog"

Slow decision making as a failure mode for Scrum

Posted by Pete McBreen 09 Sep 2021 at 21:03

Although Scrum can operate on with one to four week sprints, most organizations currently choose a one or two week duration for their sprints. This limits how long a team can take to make decisions, since with only five or ten days in the sprint, taking a day or two to organize a meeting to discuss the decision will impact delivery.

Some common failures that I have seen include:

  • Team members letting an open Pull Request sit around for a day or more because they are too busy to review the changes in the PR
  • Developers not immediately merging approved Pull Requests so the changes are delayed getting to the test environment
  • Database changes that impact a few tables needing to be discussed with the DBA who is not available until later in the week
  • Defects reported by testers sitting waiting for a developer to have the time to review report

All of the above are examples of extra time incurred in the process of taking an item from the backlog and moving it to the Done state. This increases the likelihood that there will be a rush to complete items at the end of the sprint, or that the overall sprint goal will not be met.

The fix I see for this is to build slack into the sprint so that the team is not busy all the time. Aiming for 100% utilization always leads to queuing and delays, so the team has to build in appropriate slack time to prevent decision delays.

Note. Martin Fowler has a possible fix for delays caused by the Pull Requests needing reviews.