banner-649x60

Category Archives: Agile

Understanding DevOps

Continuous Testing and Continuous Monitoring

By  Sanjeev Sharma

What is the goal of Continuous Integration?

Is it to enable Continuous Delivery of the code developers’ produce out to users? Yes, eventually. But first and foremost it is to enable ongoing test and verification of the code. It is to validate that the code produced and integrated with that from other developers and with other components of the application, functions and performs as designed. Once the application has been deployed to a production system, it is also a goal to monitor that application to ensure that it functions and performs as designed in a production environment, as it is being used by end-users.

Logigear_Understanding DevOps

This brings us to the two practices of DevOps that are enabled by Continuous Integration and Continuous Delivery.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Adopting DevOps

Aligning the Dev and Ops Teams

By  Sanjeev Sharma

DevOps as a philosophy has had as its centerpiece the principle that Dev and Ops teams need to align better. This is a people and organizational principle, not a process centric principle. To me this is more important when adopting DevOps than any other capability or tool. My last post focused on the need to better align Dev and Ops and the challenges that such organizational change would address. This post discusses key guiding principles on which this Dev-Ops alignment should be based. They are designed to improve collaboration between these organizations and to break down the proverbial ‘wall’; to end the water-SCRUM-fall, when it comes to the relationship between the Dev and Ops teams.

These guiding principles are:

1. Shift Left:

LogiGear_Chart 3_Adopting DevOps

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Making the Case for Better Test Design

The No-Nonsense Guide for How to Write Smarter and Low Maintenance Test Cases

By Michael Hacket

TD1

Test design is a phrase that is often used when planning testing and test efforts, but I do not believe it is well understood. Also, opinions vary widely about the importance of test design ranging from irrelevant to the crucial ingredient for success.

Recently, I was at a company where they are throwing out their entire test automation suite and starting over. The regression suite they had been building for a few years was bloated and verbose. To make matters worse, the pass-rate (percentage of automated tests passing each run) kept dropping, and the team had long ago lost confidence that the regression suite even gave much assurance.

Their idea two years ago was to invest a bunch of money in a new tool and hire more technical staff. Next, take the manual test cases and automate them since they seem to work, and automating is better than manual. Good idea? Eighteen months later they had a large number of automated scripts, but the tests were poorly designed in the first place.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

LogiGear Magazine – Dec 2015 – The Rise of Test Automation in Agile

Cover

LogiGear Magazine, December 2015: Test Automation

Facebooktwittergoogle_plusredditpinterestlinkedinmail

LETTER FROM THE EDITOR – DECEMBER 2015

Michael_Hackett.20150723Every year, LogiGear Magazine devotes one full issue to Test Automation.  We could do more than one, and perhaps even that would not be enough.

The problems around automation have become increasingly complex. And now, automation is much more integrated into the software development process. For over a decade teams have been faced with “do more with less”: do more testing, do more automation, and do it all with less staff. Then Agile/Scrum came along and we had to automate it faster. As the XP practice of continuous integration (CI) caught fire, our automation suites – smoke tests and full regression suites – got integrated into the autobuild development process, which in most cases was out of our control. Other people and tools are now running our automation and reporting back results – not by us kicking off automation when we choose to, but whenever a build takes place.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Testing Agility in the Cloud: The 4Cs Framework

LGMweb.201512.Mehrota.SS_96470825

 

By Sumit Mehrotra, Skytap

Application development and delivery teams are under constant pressure to release quality features as quickly as possible. CIOs rate delivering applications faster, with higher quality and with strong control on application development as their key priorities. What’s more, supporting this type of agile environment is particularly complex to IT teams that are also tasked with supporting multiple, older versions of applications.

Moving faster, with higher quality and stronger control on costs is a common mantra in enterprise application development and delivery (AD&D) teams today. However, these requirements often pull teams in different directions. To release things faster, teams often skip various pieces of testing to compress the timelines that result in costly customer issues later. And conversely, to achieve required quality, teams often have to sacrifice features, thereby impacting business deliverables. Lastly, in order to achieve business deliverables with the desired quality, teams tend to be forced to spend a lot, both in resources and people.

To avoid being forced to sacrifice quality for speed, and vice versa, I recommend a 4Cs framework. This framework eliminates common constraints faced by AD&D teams looking to adopt DevOps practices like continuous integration and continuous delivery, and helps deliver agility in the cloud. Many enterprises today are adopting this framework to help them evaluate the variety of tools and resources in the ecosystem to help them deliver business value faster, with higher quality and lower costs.

In this article, we introduce the 4Cs framework, and use it in the context of four transformations — each addressing a given set of problems, with an appropriate array of tools for a desired end result — that teams are trying to achieve in their software delivery pipelines.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Get Automated Testing “Done”

How to fit automated testing into scrum, and keep testers in sync with other teams

shutterstock_133776947

By Hans Buwalda and Subu Baskaran

One of the benefits of the approaches of agile projects is their friendliness towards testing. The testing activities, and the testers with it, are integrated into the teams, and testing and quality are redefined as team responsibilities. Automation nowadays is a must-have that needs to be addressed. Automation happens on multiple levels in a system, starting with unit tests. Here, we’ll focus on functional tests at the UI level.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Technical Debt: A Nightmare for Testers

By Michael Hackett

The sprint is almost over; the burndown chart has not budged. The test team sits around waiting. They hear about all kinds of issues, obstacles and impediments at the daily stand-up but there is no code to test. Closing in on the demo and sprint review… then at Wednesday’s standup: the heroes arrive and tell everyone,

“All the stories are done. Everything is in the new build. Test team – get to work! You have one day to test everything for this sprint, we will have an internal demo of everything tomorrow afternoon and a demo to the PO on Friday morning. Get busy!”

Facebooktwittergoogle_plusredditpinterestlinkedinmail

LogiGear Magazine – July 2013 – Agile Testing

LogiGear Magazine – July 2013 – Agile Testing

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Quantify the Impact of Agile App Development

By Larry Maccherone, Director of Analytics, Rally Software

Agile is here to stay. Once the radical alternative to Waterfall development methods, these legacy methodologies are being disrupted and replaced by Agile practices that improve time-to-market, reduce development costs, and produce higher quality software that better meets customer expectations. As the world demands more software, development teams – from scrappy startups to big corporations – are meeting the challenge with Agile.

But while Agile software development projects scale across the enterprise, management is still searching for the best way to gain deeper visibility into these projects. Large organizations cannot rely on the subjective anecdotes of those closest to the work; they require quantitative insight upon which to base business decisions.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Subscribe