As an Agile software developer I talk alot about testing. I promote and teach Test Driven Development and push to change the habits of developers to encourage quality traits that make the software we produce just work.
I want to draw a distinction between the understanding that I am "testing" and the fact that I am following a "process". This may be moot in the grand scheme of things but it strikes me as important because of a sentence I was about to make to a security professional.
Consider this:
As a software developer, my primary goal is to make software work.
A QA developer is focused on making software NOT work.
This is why I am not capable of testing.
Similar logic demands that
I am not capable of producing secure code.
A QA developer is focused on making software NOT work.
This is why I am not capable of testing.
Similar logic demands that
I am not capable of producing secure code.
The problem with this logic is that is contradicts everything I teach. Test, test, test but, oh by the way, you are not capable of succeeding.
So, perhaps I should describe TDD as a development process that improves quality instead of a process that tests code. While the eventual result is a set of tests that verify features of code, the developer gets there by following the TDD process, not by trying to make things break.
This is not a statement of whether TDD is a design process or not. Different discussion. I am addressing developer intent, not defining the outcome of the TDD process.
In TDD we first follow a simple mantra:
Run the Test,
Change the Test,
Change the Code,
Repeat every 60 seconds.
Change the Test,
Change the Code,
Repeat every 60 seconds.
Step two of this process could be argued to be an attempt to break code. However, this is not true since all we are doing is writing tests that will break because the functionality is not implemented yet.
TDD offers us a process to ensure that we end up with a suite of testing code that matches our running code. So TDD is not a testing process, just a development process that encourages a higher quality of working code than other processes.
From a higher level, the software development process we use already "values" a Quality Assurance team that double checks the work that we do. These people focus on breaking our code and do a really good job at it. They are a critical step to producing reliable software.
Another important role that software developers are unable to be good at is producing secure code. While we can learn the best practices and gain an understanding of the OWASP Top 10 attacks we are still trying to make software work for the business, we are not trying to prevent customers from attacking it.
Even with this problem, the software development process doesn't "value" a security organization reviewing the product that is produced.
Our industry is just starting to learn how to integrate security intelligence into the software build process and, to date, we software developers do not have a Security Driven Development process to improve our odd for success.
Scott Ambler's 2003 article predicted its creation in 2004 but his predicted internet shutdown wasn't as impressive a game changer as he thought. Unfortunately, that remains a learning curve in our future.
TDD offers us a process to ensure that we end up with a suite of testing code that matches our running code. So TDD is not a testing process, just a development process that encourages a higher quality of working code than other processes.
From a higher level, the software development process we use already "values" a Quality Assurance team that double checks the work that we do. These people focus on breaking our code and do a really good job at it. They are a critical step to producing reliable software.
Another important role that software developers are unable to be good at is producing secure code. While we can learn the best practices and gain an understanding of the OWASP Top 10 attacks we are still trying to make software work for the business, we are not trying to prevent customers from attacking it.
Even with this problem, the software development process doesn't "value" a security organization reviewing the product that is produced.
Our industry is just starting to learn how to integrate security intelligence into the software build process and, to date, we software developers do not have a Security Driven Development process to improve our odd for success.
Scott Ambler's 2003 article predicted its creation in 2004 but his predicted internet shutdown wasn't as impressive a game changer as he thought. Unfortunately, that remains a learning curve in our future.
Posts
