Jeffery Payne is CEO and founder of Coveros, Inc., a software company that builds secure software applications using agile methods. Since its inception in 2008, Coveros has become a market leader in secure agile principles and recognized by Inc. magazine in 2012 as one of the fastest growing private companies in the country. Prior to founding Coveros, Jeffery was chairman of the board, CEO, and co-founder of Cigital, Inc., a market leader in software security consulting. He has published more than thirty papers on software development and testing, and testified before Congress on issues of national importance, including intellectual property rights, cyber terrorism, and software quality.
"Continuous" gets mentioned a lot in agile and DevOps, but one area that often doesn’t get enough attention is how to continuously build, test, and deliver secure applications. Just like for quality, you can’t test security in, so you need to have a plan for how to build it in. Here are some tips on how to do that.
Continuous testing started when DevOps got hot as organizations began trying to figure out how to make everything in the software delivery process more continuous and testers felt they were being left out of the DevOps movement. If you want to get started with continuous testing, here are three things you should know.
Using open source software is all the rage these days, and for good reason. Often teams don’t have the budget to purchase commercial tools, and without an open source solution, their productivity suffers. But open source is not a panacea. There are some challenges that can hit you hard if you aren’t careful.
There are lots of good practices that people will tell you aren’t agile. Usually this comes from people who read a book on Scrum or Extreme Programming and took it literally. But agile is not methods and tools associated with a particular methodology; as long as you follow the agile principles, anything is fair game.
The test pyramid is a valuable visual in agile. In particular, it argues that unit tests should make up the majority of tests, and while agile teams recite this principle, it is often not clear why it is so important. Here are five reasons unit tests should make up the majority of tests written for an application.
Too often, organizations try to rush agile change. It is usually because they want to see the business benefits of agile as quickly as possible. Unfortunately, change doesn’t work like that—you can’t rush it. In fact, trying to change too fast often results in no change at all. Here are some examples to avoid.
A so-called generative culture has all the characteristics necessary to support self-directed teams, shared responsibility, experimentation, and continuous process improvement. But what about the rest of us? Most large organizations don't have a culture where agile will take hold so easily. Here's what needs to change.