Let’s face it, Agile has some tremendous benefits. If you are practicing agile at your company, you know that firsthand. Agile also has some pitfalls that can be extremely deadly if they are not addressed properly. Most of us have learned how to avoid them by implementing costly mistakes.
Sure there are other things that agile has issues with, but we will cover those in subsequent agile posts.
Using the agile methodology, software can be developed very quickly, in fact, business needs demand it is produced as quick as possible. While there is nothing inherently wrong with that, it is important to develop it efficiently. Agile teams want to build the best designed and highest quality product possible. However, that isn’t always what happens. My team has recently been involved in leveraging a COTS product called Globalscape to consolidate all our B2B file transfer systems into a single solution. In fact, our company was acquired, so between both legacy companies we had four solutions which were being used. We selected Globalscape, but the product was brand new to our team. We didn’t have extensive experience but were driven to move off the other systems. We made the best decisions that we knew at the time, but looking back, there were some things that if we had better information and experience with the product, we would have certainly done differently. Naturally, we accumulated technical debt, and we created stories in our backlog to handle those. In certain sprints, we had to put more technical stories in place to implement the necessary changes. While our business partners weren’t thrilled, they understood those needed to be done.
In some situations, you can address technical debt issues as you are addressing stories in the backlog. For example, with our file transfer product, we created a generic function to address how email notifications were delivered, which was much more efficient. While we were moving other B2B files into the new platform, we would go ahead and make those changes, so that we would not have to revert and make those technical debt changes later.
It is also a good idea to keep 5 to 10 percent of your sprint capacity available to handle technical debt issues. If you have one story per sprint handling technical debt, then it will make it a lot easier in not having to deal with too much technical debt later.
Hopefully this real world example will help you avoid Agile Pitfall #2: Too Much Technical Debt!
Agile Software Testing has literally transformed the role of an Agile QA Engineer. There are several key differences which software testing organizations will need to adjust in order to effectively operate with Agile.
Documentation: It isn’t practical within Agile for the Agile QA Engineer to have lots of documentation. Don’t get me wrong, there does need to be sufficient documentation for the QA Engineers to do their job well. If a developer tries to convince you that the Agile Manifesto doesn’t require documentation, Houston we have a problem!
In terms of requirements, there needs to be enough documentation that the Agile QA Engineer knows how the system is supposed to operate. In my team, we currently use a 1 page document that will provide that information for each story. It really does help the agile testers know what is expected so they can adequately plan.
For the Software Test Plan, it isn’t necessary to go through all the hoopla of creating a massive plan that nobody will read or follow. A one page document will be sufficient. I encourage the creation of the one page plan because it forces the agile tester to think about what testing is needed.
For the testing sign off a simple email will suffice.
Test Automation: One of the hottest topics naturally is test automation, especially within Agile software testing. Test automation without a doubt is critical. However, there needs to be a strategy that is going to work. In previous organizations, I have built world class automation teams. We had thousands of automated test cases within our regression suites. Were all those tests necessary, probably not. Was it expensive to maintain, absolutely! I believe having a centralized automation team that can build and execute the automation tests is most effective. The team prioritizes the work based upon the needs of the various agile teams. I have found this to work most effectively. I usually recommend that the agile testers execute the tests within the current sprint and once those have passed, they can hand that off to the agile team to automate and put in the regression suite. Having an Agile QA Engineer do both the functional and automated tests within a given sprint is extremely challenging and often the functional testing gets done and the automation gets put on the back burner.
Performance Testing: Another challenge is system performance. If automation takes a back seat, then performance testing is usually behind that. In order to deal with that challenge, having a centralized performance team will help. Usually 2-3 performance engineers will be sufficient. I encourage a very close look at performance testing within the Agile context. If you don’t need it, don’t do it, if you need it, you better do it.
UI versus Web Service: Agile software testing requires some fundamental changes in terms of how things get tested. More and more agile software testing is taking a closer look at web service testing. It is a critical component that can find a lot of defects. The need for agile teams to focus on spending more time in this area is due to the amount of applications that are using API’s to transfer information. It is a lot quicker to run hundreds of transactions through an API versus through the UI. Agile software testing teams who are able to make this transition are simply more effective.
Let’s face it, transforming your software testing organization is going to be very challenging. Agile software testing is extremely challenging. The key is to have a strong team who is flexible and is adaptable to constant change. The teams that can do that most effectively will be successful.
»DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market.
»Under a DevOps model, development and operations teams are no longer “siloed.” Sometimes, these two teams are merged into a single team where the engineers work across the entire application lifecycle, from development and test to deployment to operations, and develop a range of skills not limited to a single function. and security teams may also become more tightly integrated with development and operations and throughout the application lifecycle.
»These teams use practices to automate processes that historically have been manual and slow. They use a technology stack and tooling which help them operate and evolve applications quickly and reliably. These tools also help engineers independently accomplish tasks (for example, deploying code or provisioning infrastructure) that normally would have required help from other teams, and this further increases a team’s velocity.
»2008- Patrick Debois helps plant the seeds of the DevOps movement at the Agile conference in Toronto
»2009-O’Reilly Velocity Conference—John Allspaw and Paul Hammond deliver a seminal talk known as “10+ Deploys per Day”
»2009-Debois launches the first Devopsdays event, in Ghent, Belgium
»2010-The first US Devopsdays is organized, with the help of Willis as well as other early DevOps proponents like Damon Edwards and Andrew Clay Shafer
»2011- Cameron Haight from Gartner, among others, predicts that by 2015, 20 percent of global 2000 businesses will embrace DevOps.
»2012-various Devopsdays are suddenly popping up around the world, from Bangalore to Boston.
»2013-Various DevOps books emerge: Phoenix Project (Kim), Implementing Lean Software Development” (Poppendiek), The Lean Startup (Ries), Web Operations (Allspaw), Continuous Delivery, (Humble and David Farley) and The Goal (Goldratt)
»2014-DevOps crosses into the enterprise, and established brands like Target, Nordstrom and LEGO embrace the movement. In a survey by Puppet Labs, IT Revolution Press and ThoughtWorks, 16 percent of 1,485 respondents say they are part of a DevOps effort within their organization.
It is important that your QA organization has the necessary items to be successful. Perhaps the most important element is the organization is able to protect the production environment. Here are a few items that are required.
Ensure you have Executive level support. This is the most important items. Without having your executive to support the QA organization when there is a quality concern, delivery will always win.
Reduce the testing cycle time. Another important item, is to make sure your organization is doing what it can to reduce the amount of time spent during test execution. The best thing that can be done is to focus automating your regression suite.
Shift Left. Focus more time getting involved up front and identifying issues with requirements and other documentation.
Focus on Planning. Make sure the QA organization is covering all the bases and spending sufficient time planning.
While there is an ever increasing movement for Quality Engineering organizations to “Shift Left” there needs to be more attention placed on “Shift Right”. Here are some reasons why Quality Engineering must pay close attention:
This is especially needed in more traditional industries where there are smaller and smaller UAT teams. There is increasing pressure on the UAT teams to test more and more with fewer and fewer resources.
UAT resources usually have full-time demanding business jobs. UAT is typically given very little attention and focus. If there is a priority, UAT usually loses.
Quality Engineering should work closely with UAT to understand how the business works and create scenarios based upon day in the life scenarios. Those scenarios can then be automated and will greatly improve the quality of the applications before they hit UAT.
While more and more demands are placed on Quality Engineering organizations, they usually are dedicated resources who can focus all their efforts on software quality.
I agree that it is necessary to “Shift Left” but I believe you should actually start by “Shifting Right” in order to cover the backside of the SDLC.
Agile will place greater demands and significantly compress the historically long UAT cycles, the time that used to be available will no longer be available.
“Shift Right” will require interaction with UAT teams. This is often difficult for QE to interact and understand how the business really works. Let’s face it, we are geeks. Once QE has engaged and understood the real world challenges that the business faces, they will be able to identify potential issues before testing gets to UAT.
While this is not an exhaustive list, it will help support the thought that “Shift Right” first is the right way to go.