From the Pipeline v26.0

This entry is part 26 of 27 in the series From the Pipeline

The following is a regular feature where we share articles, podcasts, and webinars of interest from the web.

Evaluating Test Cases, Checks, and Tools

In his latest blog post Michael Bolton asks the reader to perform an experiment to observe if they are putting too much stock in tooling or test cases: start a list. Note how significant an impact the artifact was in finding the bug. For the purpose of the blog post, Bolton considers test cases, automated checks, and testing tools to be artifacts. The scoring system can provide a negative impact when the artifact costs time or disrupts from the task of finding problems. An overall high score might indicate the artifacts are helping the testing effort; a low score might suggest the artifacts are hindering the testing effort. What ultimately matters is the experience not the score. Learning to understand the context in which artifacts can help or hurt testing is a path to improvement, most especially in guarding against over-reliance on particular artifacts.

Bad software sent postal workers to jail, because no one wanted to admit it could be wrong

UK Post Office employees have dealt with a piece of software called Horizon that had bugs that made it look like employees stole tens of thousands of British pounds. Some local postmasters were convicted of crimes. More than 736 employees were convicted over the course of 15 years, yet the software defects were responsible for reporting the count was short. At present many of those affected have had their convictions overturned and there is currently an inquiry into the software in question.

Simplify Cucumber Steps

In the later stages of a test automation project, code complexity increases due to development. Ali Fuat Atest provides tips to reduce maintenance cost, complexity, and achieve a better project structure. The Background is recommended to reduce repetition for the common steps that begin each scenario. Using Scenario Outlines are recommended when using datasets to improve readability. Additionally, many common and repeated steps should be combined into a higher-level step definition. Lastly, table structure is useful for a given step that has many components such as data entry.

Cypress Courses

Cypress is a front-end testing tool capable for functional automated checks as well as unit tests. It’s growing in popularity, most especially with angular web applications because it’s written in Javascript. Cypress is different from Selenium in that it executes in the same run loop as the application, as opposed to Selenium that executes external to the browser and sends remote commands. The Cypress team has collected many of the training courses offered across multiple platforms into one place.

Book: 33 Routines to Make You a Better Tester

A brief book review of “33 Routines to Make You a Better Tester”. The book contains topics from exploratory testing, Risk-based testing, static testing techniques, etc.. Each section defines the topic briefly, demonstrates an approach, and has several key takeaways. It’s available on Amazon Kindle for just $1.50.

Series Navigation<< From the Pipeline v25.0From the Pipeline v27.0 >>

Leave a Reply

%d bloggers like this: