Always Use Automated Integration Testing

QA or Quality Assurance of a software project is often the area of software development that is most neglected. Typically developers avoid software testing like their lives depended on it. While a basic level of testing is required for a single scenario to validate that your code “works”, the level of testing that is required to ensure that all users have a good user experience across all targeted platforms is something that a developer seems to think is beneath them.

While there has been much progress made with TDD, or Test Driven Development, and BDD, or Behavior Driven Development, many developers avoid writing even automated testing solutions for the projects they develop. From what I have seen, a developer’s attitude toward QA in general is a significant indicator at the skill level of the developer. One thing to point out here is that I am saying skill level, and not experience level as these do not necessarily correlate. Also, when talking about skill level, the skill level I am focusing on is the ability to write easy to understand, maintainable and performant code. For my purposes, I will split developers into two overly general categories.

The first category is made up of developers that strive to understand how their code interacts with the rest of the project before starting development. The developer also is able to communicate exactly what their changes are to the QA team, ensuring they have an adequate understanding of the scope of the change so that it can be thoroughly tested. While QA will inevitably find issues with the code at some point, the developer is appreciative the bug was found before it made it to production, and fixes it promptly for QA’s verification.

The second category is made up of developers that are frequently over confident of their development abilities and like to rush in to actual coding before having a full grasp of how their part of the project interacts with the whole. Many times, the QA team gets ineffective communication from these developers, and often the testing plan leaves out major functionality changes.

While everyone wishes they were in the first category and wants all their coworkers to also be in that category, reality sets in and it becomes apparent that we all migrate between these categories quite often. The best and easiest way to combat these forays into the second category is to implement automated integration tests for all code that verify the functionality works as expected. While this will never completely replace the manual QA testing efforts, it will help to raise a red flag when a change has inadvertent effects elsewhere in the codebase.

Developers: communicate well with your QA team and write automated integration tests as much as you possibly can.

Related Posts

Jun 2, 2014
2 minutes

Defensive Development - Fail Fast or Go Home

Defensive Development is a programming practice that is frequently misunderstood, but is nevertheless a critical practice to follow when working in many environments. I have seen articles written that argue that defensive development simply causes nonsensical null checks to be written, and as a result of seeing people writing bad code defensively, argues that no one should practice defensive development. There are other articles that, like many things in software development, argue that you should always use defensive development for everything.

Jun 12, 2014
One minute

Code Style Guides - Consistency is King

There have been countless flame wars online about the details of the guidelines that appear in various Code Style Guides. Some of the most famous are the tabs versus spaces arguments, whether or not to put curly brackets {} each on their own line, whether you should even use the curly brackets {} for one line actions in if statements.

I am here to say that the only thing that matters in the style of your source code, other than syntactically correct code, is consistency. When a codebase has internal consistency, developers new to it are more easily able to pick up the meaning of the source code contained within instead of having to first understand why the different styles in different sections matter, or not.

Apr 30, 2014
2 minutes

Always Namespace Variable Names in JavaScript

After running into a few issues with variable naming collisions over the past few days, it drives home how much we all should be namespacing our variable names in JavaScript. When writing JavaScript code that is only in use on your own website, you should still always namespace your variables. If you are writting a JavaScript library that will be in use on any website a user puts it on, namespacing your variable names is a minimum requirement.