Recent Posts

Using DevOps Best Practices to Strategize Continuous Testing

As I have had the opportunity to work in environments that have emphasized the role of Continuous Integration and Continuous Delivery (and with it, the goal of achieving Continuous Testing as well), I have also had the chance to see our Operations Team focus more attention on the goals of DevOps and the methodology that lets us steer towards that goal. In many ways, we are actively working towards getting to that effective DevOps goal and each day gets us closer.

Continue reading
Michael Larsen
Michael Larsen is a Senior Automation Engineer with LTG/PeopleFluent. Over the past three decades, he has been involved in software testing for a range of products and industries, including network routers & switches, virtual machines, capacitance touch devices, video games, and client/server, distributed database & web applications.

Michael is a Black Belt in the Miagi-Do School of Software Testing, helped start and facilitate the Americas chapter of Weekend Testing, is a former Chair of the Education Special Interest Group with the Association for Software Testing (AST), a lead instructor of the Black Box Software Testing courses through AST, and former Board Member and President of AST. Michael writes the TESTHEAD blog and can be found on Twitter at @mkltesthead. A list of books, articles, papers, and presentations can be seen at http://www.linkedin.com/in/mkltesthead.

Self-Healing Automation: A Remedy for Failing Automated Tests

In CI/CD environments, automated tests are the linchpin of a successful build and deployment. When tests go bad, they cause failed builds, necessary research, and examination. And, of course, if there is a real error, the need to be fixed and rerun. However, what often happens is that a test changes slightly or the underlying environment changes in a way that may cause a test to fail at certain times but not others. These situations are frustrating and I often mutter to myself, “Can’t the test figure these things out on their own?” Today, the answer is “Yes, they can!” Or, at least they can to a point.

Continue reading
Michael Larsen
Michael Larsen is a Senior Automation Engineer with LTG/PeopleFluent. Over the past three decades, he has been involved in software testing for a range of products and industries, including network routers & switches, virtual machines, capacitance touch devices, video games, and client/server, distributed database & web applications.

Michael is a Black Belt in the Miagi-Do School of Software Testing, helped start and facilitate the Americas chapter of Weekend Testing, is a former Chair of the Education Special Interest Group with the Association for Software Testing (AST), a lead instructor of the Black Box Software Testing courses through AST, and former Board Member and President of AST. Michael writes the TESTHEAD blog and can be found on Twitter at @mkltesthead. A list of books, articles, papers, and presentations can be seen at http://www.linkedin.com/in/mkltesthead.

How to Effectively Unsilo Teams in DevOps

As I have seen various organizations embrace a DevOps model, there are several goals that they hope to accomplish. One is the idea that by automating the process of building, deploying, and monitoring software, they can make a system that is robust and well-documented. What is the primary benefit of this? It takes that arcane and specialized knowledge that is locked inside of the brains of a single or small group of specialists and makes it available for everyone. This is in contrast to the idea that knowledge, skills, and expertise are isolated within a single person or a small group. This process of isolation is called “siloing” or placing that knowledge into a “silo.” For those not familiar with the word, silo comes from the Greek word “siros” and means “grain pit.” They are typically large structures, and their purpose is to store an item separate from other items. Common examples are wheat, dry cement powder, and other things that are beneficial to keep separate until they are needed.

Continue reading
Michael Larsen
Michael Larsen is a Senior Automation Engineer with LTG/PeopleFluent. Over the past three decades, he has been involved in software testing for a range of products and industries, including network routers & switches, virtual machines, capacitance touch devices, video games, and client/server, distributed database & web applications.

Michael is a Black Belt in the Miagi-Do School of Software Testing, helped start and facilitate the Americas chapter of Weekend Testing, is a former Chair of the Education Special Interest Group with the Association for Software Testing (AST), a lead instructor of the Black Box Software Testing courses through AST, and former Board Member and President of AST. Michael writes the TESTHEAD blog and can be found on Twitter at @mkltesthead. A list of books, articles, papers, and presentations can be seen at http://www.linkedin.com/in/mkltesthead.

Shift Left? Shift Right? When Does It Matter?

A phrase we hear often in Software Testing circles and commentary is “shift left.” When we dig a little, we realize that “shift left” is talking about the idea that Software Testing is happening either too late in the process or it is not effective at the time it is being allocated. This dates back to an embrace, willingly or not, of the traditional Software Development Life Cycle (SDLC) and especially the Agile Waterfall (Agile Falls) methodology. In the waterfall methodology, each piece is completed (design, programming, testing, packaging, etc.) and the product moves through each of those cycles.

Continue reading
Michael Larsen
Michael Larsen is a Senior Automation Engineer with LTG/PeopleFluent. Over the past three decades, he has been involved in software testing for a range of products and industries, including network routers & switches, virtual machines, capacitance touch devices, video games, and client/server, distributed database & web applications.

Michael is a Black Belt in the Miagi-Do School of Software Testing, helped start and facilitate the Americas chapter of Weekend Testing, is a former Chair of the Education Special Interest Group with the Association for Software Testing (AST), a lead instructor of the Black Box Software Testing courses through AST, and former Board Member and President of AST. Michael writes the TESTHEAD blog and can be found on Twitter at @mkltesthead. A list of books, articles, papers, and presentations can be seen at http://www.linkedin.com/in/mkltesthead.