Open in app

Sign in

Write

Sign in

Mastodon

My Article Series

A list of my article series for convenient access

Zhimin Zhan
13 min readApr 19, 2022
Table of Contents:
· Quick Guide
· How to do X in Selenium WebDriver?
· Courtney’s Appium Series
· Functional Test Refactoring
· Optimize Selenium WebDriver Automated Test Scripts
· Why Do Most UI Test Automation Fail?
· Benefits of Continuous Testing
· IT Terminology Clarified
· Software Design Pattern by Example
· Programming Language Advice
· Be aware of Fake Test Automation/DevOps Engineers
· IT Job Interviews
· Bad Test Automation Frameworks/Tools
· My Innovative Solution to …
· Chinese Idiom Stories for Software Professionals
· Web Test Automation Workbook
· Stories
· E2E Test Automation Anti-Pattern
· What Does it Take to Become a Real E2E Test Automation Engineer?
· Correcting Wrong ‘Playwright’s Advantage over Selenium”
· Laws in Software Development

Quick Guide

How to do X in Selenium WebDriver?

Courtney’s Appium Series

Functional Test Refactoring

Automated test scripts are often poorly designed, inefficient, and hard to understand and maintain, i.e., the same issues we found in code. Functional Test Refactoring is a process of enhancing the quality of automated functional test scripts.

  1. Functional Test Refactoring: Introduction
  2. Functional Test Refactoring: Extract Function
  3. Functional Test Refactoring: Move to Helper
  4. Functional Test Refactoring: Move
  5. Functional Test Refactoring: Extract to Page Function
  6. Functional Test Refactoring: Introduce to Page Object
  7. Functional Test Refactoring: Rename

Optimize Selenium WebDriver Automated Test Scripts

Working automated test scripts is only the first test step to successful test automation. As automated tests are executed often and the application changes frequently too, it is important that test scripts need to be fast, easy to maintain and read.

Why Do Most UI Test Automation Fail?

FACT: not many software engineers (in Test) received proper education or training in test automation, which is unfortunate. Considering this: 30–40% of staff in a software team are usually testers. Programmers and business analysts spend a lot of time performing functional testing as well. However, there are few dedicated Functional Testing courses offered at universities to my knowledge. Therefore, it is not surprising that many wrong decisions on test automation are made due to a lack of knowledge.

(Technical)

  1. Wrong choice of automation framework
  2. Wrong choice of test syntax framework
  3. Wrong test scripting language
  4. Wrong choice of test automation tool
  5. Don’t know how to design easy-to-maintain test scripts
  6. Lack of Efficiency
  7. Lack of experience in executing a medium-size regression suite of automated UI tests

(Human)

  1. Management under-estimate the effort, especially on test maintenance
  2. Tech leads over-estimate their capability in test automation
  3. Tech leads are fixated with a particular wrong technologies
  4. No access to a real Test Automation Coach

Benefits of Continuous Testing

Continuous Testing (enables software teams to push software updates to production daily, not fake CI/CD talks. Check out “Continuous Integration at Facebook” and AgileWay Continuous Testing Grading) is the heart of the software development process. It benefits all stakeholders of a software project.

1. Part 1: to Wise Executives
2. Part 2: to Wise Managers
3. Part 3: to Wise Business Analysts
4. Part 4: to Wise Developers
5. Part 5: to Wise Testers
6. Part 6: to Happy Customers

IT Terminology Clarified

In software development, particularly in software testing, there are many terminologies that are used wrongly by IT professionals.

  1. Unit Testing Clarified
  2. User Story Card Clarified
  3. Regression Testing Clarified
  4. Cross Browser Testing Clarified
  5. Headless Browser Testing Clarified
  6. ‘Data-Driven Testing’ Clarified
  7. ‘Shift Left Testing’ Clarified
  8. Continuous Testing Clarified
  9. Full-Stack Software Engineer Clarified
  10. Testing Pyramid Clarified
  11. BDD Clarified: BDD ≠ “Given-When-Then” (Gherkin)
  12. Codeless Test Automation is Irrational
  13. “Done, Done” in Agile
  14. Fake End-to-End Test Automation Clarified
  15. In-Sprint Test Automation Clarified
  16. CI/CD (Pipeline) Clarified
  17. DevOps Clarified
  18. Test Automation Clarified
  19. “Release Early, Release Often” Clarified
  20. Robotic Process Automation (RPA) Clarified
  21. “Daily Production Releases” Clarified
  22. Testing Center of Excellence Clarified
  23. Code Commenting Clarified
  24. Side Hustle Clarified
  25. Why I don’t use Test Management Tools at all?
  26. Execution Speed of Automated End-to-End (via UI) Testing Clarified
  27. Expose a Common Lie, “Selenium is Flaky”, Part 2: Clarify ‘automated waiting’
  28. Record/Playback in Test Automation is Bad, mostly
  29. Correct a Common Misconception: “Using the Coding Language for End-to-End Test Automation”
  30. Correct two Common Misconceptions: End-to-End Test Automation is “Simple and Easy” or “Complex and Impossible”.
  31. Correct a Common Misconception: “Setting up Selenium is Complex and Time-Consuming” with a benchmark test.
  32. User Acceptance Testing Clarified
  33. Auto-Waiting in Web Test Automation Clarified
  34. Three Types of Efforts in E2E (UI) Test Automation Clarified

Software Design Pattern by Example

Design Patterns are good practices of Object-Oriented (OO) Software Design. Applying appropriate design patterns will help to design your software better. However, design patterns are not easy to master, it was the case for me, and my daughter as well when she started an IT degree at Uni. I wrote a series of articles to help her learn Design Patterns quickly. My approach is to use easy-to-understand exercises, which I believe is an easier way to master design patterns.

Programming Language Advice

Be aware of Fake Test Automation/DevOps Engineers

IT Job Interviews

Bad Test Automation Frameworks/Tools

My Innovative Solution to …

Chinese Idiom Stories for Software Professionals

Using Chinese idioms to explain some of the problems I have witnessed in the software industry (in particular, test automation and continuous testing) ”. Chinese idioms are insightful and often with interesting stories. Human nature has changed little, and these Chinese idioms stand the test of time (over 1000 years).

Web Test Automation Workbook

Welcome to Learning Web Test Automation with short and purposeful exercises, no tech background is required at all. An exercise typically takes 15–20 minutes.
(Bold ones: published, italic and underlined: soon will be published)

Stories

E2E Test Automation Anti-Pattern

What Does it Take to Become a Real E2E Test Automation Engineer?

Correcting Wrong ‘Playwright’s Advantage over Selenium”

  1. “Playwright is Modern and Faster than Selenium” 😒
  2. “Playwright has Parallel Execution Support” 👎🏽
  3. “Playwright has Native Auto-Waiting Mechanism” 👎🏽
  4. “Playwright has a native test runner” 👎🏽 (coming soon)
  5. “Playwright has native HTML Reporters” 👎🏽
  6. “Playwright Features Can be Configured in one Configuration” 👎🏽
  7. “Playwright supports a range of Testing Types, e.g. API Testing, Component Testing, …” 👎🏽
  8. “Playwright ARIA locator support” 👎🏽
  9. “Playwright UI Mode, CodeGen, Debugging support.” 👎🏽

Laws in Software Development

  • 80/20 Rule
  • Broken Window Theory
  • Parkinson’s Law: “work expands so as to fill the time available for its completion”
  • Sturgeon’s law: “ninety percent of everything is crap”
  • Murphy’s law: “Anything that can go wrong will go wrong”
  • The 10,000-Hour Rule: “The key to achieving true expertise is simply a matter of practicing”
  • Brooks’ Law: “Adding manpower to a late project makes it later.”
  • KISS Principle: “Keep it Simple, Stupid”
  • Hosftadter’s Law: “It always takes longer than you expect, even when you take into account Hofstadter’s Law.”
  • Conway’s Law: “Any piece of software reflects the organizational structure that produced it.”
  • Linus’s Law: “given enough eyeballs, all bugs are shallow”
  • Wirth’s Law: “Software gets slower faster than hardware gets faster”
  • Ninety-Ninety Rule: “The first 90% of the code takes 10% of the time. The remaining 10% takes the other 90% of the time”
  • KNUTH’S OPTIMIZATION PRINCIPLE: “Premature optimization is the root of all evil”.
  • Goodhart’s Law: “When a measure becomes a target, it ceases to be a good measure.”
  • Kernighan’s Law: “Debugging is twice as hard as writing the code in the first place”
  • Gall’s Law: “A complex system that works has evolved from a simple system that worked. A complex system built from scratch won’t work.”
  • Doerr’s Law: “We need teams of missionaries, not teams of mercenaries”
  • Choose Boring Technology: “Consider how you would solve your immediate problem without adding anything new”
  • Questioning “If It Ain’t Broke, Don’t Fix It” in Software Development

Software Side Hustle Anti-Pattern

  • Creating Something You Wouldn’t Use Daily
  • Get the first customer too late, and Assume adding the second customer is easy
  • Use the same tech stack as day-time work
  • No E2E Test Automation

--

--

Zhimin Zhan
Zhimin Zhan

Written by Zhimin Zhan

5.7K Followers
72 Following

Test automation & CT coach, author, speaker and award-winning software developer. Help teams succeed with Agile/DevOps by implementing real Continuous Testing.

No responses yet

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams