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.

comments powered by Disqus

Related Posts

How Not to Use SQL Transactions

SQL Transactions allow you to isolate atomic operations so that you can ensure that a third party does not update the data affected during the atomic operation protected by the transaction. An example of an operation that you would want to protect with a SQL Transaction would be transferring funds from one bank account to another. The first step of this operation would be to subtract the funds from bank account A.

Read More

== and === in JavaScript and HTML Input Elements

If you read any current information about best practices in JavaScript, you will typically find the following advice somewhere in the list of things to do. Always use === and !== while avoiding == and != While I will never argue against this advice, there are a few things that a developer shoule realize when using === and !== instead of == and !=. === and !== first do a check of the data type of the two objects you are comparing.

Read More

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.

Read More