When it comes to achieving sustainable test automation, having an appropriate test automation team structure in place is the most important first step to take. This article has some proven practices for a few different test automation adoption scenarios—led by an automation team or a regression team, and with agile adaptations—that have helped organizations enjoy long-term test automation success.
You may feel you don't have time to write unit tests, but you really don't have time not to. Steve Poling makes the case that writing tests first not only will yield better code, but will help you get that code working right sooner. Here's how using a test-first approach changes your thinking about coding, lets you see mistakes immediately, and helps you create more testable code.
Writing changeable code makes it easier and more cost-effective to add features to existing software. Writing changeable code doesn’t take longer, but it does require paying attention to certain things when building a system. It's important to have a good suite of unit tests that support refactoring code when needed, and test-driven development helps you create independently testable code.
Code can express what we want to accomplish, but it’s a little more difficult to express why we’re doing something in the first place. The people who maintain code are often not those who originally wrote it, so documenting why helps set a context and gives clues as to what the author was thinking when they came up with a particular design, making developers' jobs easier.
Just as you should not take out a financial loan without having a plan to pay it back, you should also have a plan when incurring technical debt. The most important thing is to have transparency—adequate tracking and visibility of the debt. Armed with the knowledge of these pending tasks, the team can devise a strategy for when and how to “pay off” technical debt.
IoT security is a large and changing topic, but there is one basic starting point where device security can be improved during development and testing: the user interface. The UI should be the first line of defense, but it’s currently weak in most IoT devices. Implementing better practices during the initial UI setup will go a long way toward improving security.
As with any other quality attribute, it is ideal for accessibility to be incorporated in the early stages of design and engineering. But organizations that didn’t initially take accessibility into account can still address it now—it’s better late than never. Here are the main attributes you should consider from the design, development, and testing angles, whether you're building accessibility in from the beginning or adding it now.
Developers have so much to do that unit tests often fall by the wayside. One solution is to train testers to handle them. Testers get involved earlier in the development lifecycle, they can enhance their programming skills, and bugs are found and fixed quickly and easily, reducing the functional testing phase. Consider taking an active role in unit testing.
Development, operations, and QA have long recognized the importance of coexistence, but they've still had weak or unbalanced relationships. DevOps emphasizes collaboration, rejecting the "us versus them" mentality. Every department needs information, feedback, and support from every other department, helping everyone see how they enable each other.
There are organizations that want to “buy DevOps,” like it is a plugin to add to the development process. They often create a new role, team, department, or infrastructure. But you can't buy DevOps, and it's not a designated team, either. It is the idea of people working together. Here are some approaches to get you there.