In a small cry of victory today, someone on the team found this article from the BBC detailing the “top 25 most dangerous programming errors.” I say small cry of victory, because he had recently logged a ticket in JIRA detailing one of those errors, but when the ticket came up for review it was ignored. It was acknowledged as an issue, but pushed to a later sprint for work.

Download this free guide

The Benefits of a DevOps Approach

Bringing development and IT ops together can help you address many app deployment challenges. Our expert guide highlights the benefits of a DevOps approach. Explore how you can successfully integrate your teams to improve collaboration, streamline testing, and more.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

While I agree with the reasons we used when we prioritized the ticket, for me this incident demonstrated a common pattern I see in the teams I’ve worked with. First, there seems to be an expectation that the testing team shouldn’t be looking for errors like this — that is, unless you’re a high-priced security tester. Second, that when issues like this are found they take a backseat to the more traditional functional defects.

I like research like this (both SANS and OWASP do great work in this area), because it gives me a way to structure the conversations that take place when these issues come up. I find that programmers typically respond well to links to catalogs of errors with descriptions. They are unrelated to the software they are working on. It makes it less personal I think — less close to home.

That said, these issues aren’t always burning, top-priority issues. Like I said, in the context of our current project where we found one of these, we have time to fix it. Given the current list of commitments, the issues we know we need to work, and the relative risk of this causing a problem — this specific issue can be sidelined for a couple of weeks until we get to it. That perspective is important as well, and it’s one that I sometimes forget. There’s always a business story to tell as well with issues like this — context is important.

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy