The Culture Shift to Developer Testing

Introduction

This is part 2 of a 2-part piece on the culture shift to Developer Testing. Part 1 covered the difference between “culture” and “practices” and their implications for your teams; it also examined the origins of “Developer Testing,” and discussed how much testing is a Developer’s responsibility. Part 2 will begin by exploring various cultural aspects of popular development methodologies with recommendations on how to successfully implement said cultural practices in your own teams; it will conclude by emphasizing the importance of getting culture right within your teams with 5 first-steps you can take. So, without further ado, let’s dive into part 2.

Continue reading
Michael Hackett
"Michael is also a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics.

Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ed. 2003), available in English, Chinese and Japanese, and Global Software Test Automation (HappyAbout Publishing, 2006). He is a founding member of the Board of Advisors at the University of California Berkeley Extension and has taught for the Certificate in Software Quality Engineering and Management at the University of California Santa Cruz Extension. As a member of IEEE, his training courses have brought Silicon Valley testing expertise to over 16 countries."

The Culture Shift to Developer Testing

Introduction

Developer Testing is a trend in software development that aims to improve delivery speed and reduce costs. It’s important to note that there isn’t an exact definition of what Developer Testing is; it is going to vary from organization to organization, with some having Developers take over more of the testing tasks and others have Developers take over all of the testing tasks. It could range from more unit testing by Developers to testing full end-to-end workflows. No matter the case for your organization, to have success in moving testing tasks to Developers is reliant on a culture that supports this—not just implementing a new tool or saying, “Okay, Developers, now you get to test!”

Continue reading
Michael Hackett
"Michael is also a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics.

Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ed. 2003), available in English, Chinese and Japanese, and Global Software Test Automation (HappyAbout Publishing, 2006). He is a founding member of the Board of Advisors at the University of California Berkeley Extension and has taught for the Certificate in Software Quality Engineering and Management at the University of California Santa Cruz Extension. As a member of IEEE, his training courses have brought Silicon Valley testing expertise to over 16 countries."

Mastering Jenkins Pipeline Across Multiple Cloud Environments

Jenkins is a popular build and scheduling tool used to create software for many organizations. As such, it is common to see it used in a variety of situations and configurations. While it is common to think that organizations all use the same build server and/or Jenkins environment, many organizations use a variety of Jenkins systems, some of which are configured to run in different environments. As time goes on, there is often a desire to simplify or merge systems. If that’s not an option, then the ability to get Jenkins to communicate with or transition pipelines to different environments becomes something to consider.

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.

These are the 10 Best Software Testing LogiGear Blog Posts of 2020

At LogiGear, producing content is one of our favorite things to do as it allows us to help our readers find success in their Software Testing. With the throngs of Software Testing content being produced every day, we wanted to make sure you didn’t miss any of our top blog posts of 2020; so, we’ve put together a list of our 10 best performing software testing blog posts from this year. From desktop application testing, to how to build a Selenium framework, to strategizing and measuring the results of your Test Automation, these pieces all offer various ways to improve your SDLC and end-product quality. Check them out!

Continue reading
LogiGear
LogiGear Corporation provides global solutions for software testing, and offers public and corporate software testing training programs worldwide through LogiGear University. LogiGear is a leader in the integration of test automation, offshore resources and US project management for fast, cost-effective results. Since 1994, LogiGear has worked with Fortune 500 companies to early-stage start-ups in, creating unique solutions to meet their clients’ needs. With facilities in the US and Viet Nam, LogiGear helps companies double their test coverage and improve software quality while reducing testing time and cutting costs.