Posted on

Top Testing Types to Use in Automation Testing

Planning automated tests.

For any organization, the overall testing culture is influenced by the prevailing testing approach, apart from how they envision the test automation and how are they planning to collaborate beyond the development teams. Establishing test automation in an organization is not your conventional practice and that is why you would want to learn the best approaches possible.

This means retrospecting the current process, finalizing and deciding the new test approach as well as determining the level of testing, roles, and responsibilities of the team members.

Posted on

Thoughts on Efficient Enterprise Testing (Part One)

Multitasking is the MOST efficient.


Testing in the enterprise is still a topic that is not as extensively used as it should be. Writing and especially maintaining tests takes time and effort, however, cutting short on software tests can’t be the solution. Which scopes, approaches, and test technology should be pursued in order to make testing more efficient?

Posted on

Defining Test Boundaries — An Example

I think that everybody agrees that testing is required in order to build a quality product. But there’s also a lot of confusion about the boundaries of each test type. What’s the scope of a unit test? What’s the difference between an integration test, an integrated test and a contract test? If you ask three developers about test boundaries, you’ll most likely get three different answers. For example, I still talk to people who consider that a unit test should test a single class/method.

What’s clear is that most teams don’t have a consensus on what’s the scope of the different types of automated tests and the differences between them. Getting to a universal consensus might be hard, but getting to a consensus inside the team should be easy enough. In this blog post, we’ll see an example of how to do that.

Posted on

Keep Test Coverage Where it is Needed

I'm not a believer in having standards for test coverage. I know teams that require 60%, 70%, or 80% test coverage for their code. I don't like having standards like this because different code has different requirements for testing.

Straightforward code like getters and setters don't really need to be tested. However, more complex code that encapsulates business rules should be tested. When developers do "test after" software development by writing their tests after they write their code, they typically try to find the easiest code to test in order to meet their code coverage standards, but oftentimes this is not the code that we really need to have covered.

Posted on

PHP Traits for Interface Contract Testing

Interfaces, those neat artifacts created to represent contracts to be fulfilled by classes. When appropriately used, they’re a very powerful way to express the expectations a client class has on implementations. Yet, most languages lack the tools to express those aspects that you can’t see by looking at the method signatures.

What should a method return under certain circumstances? If condition X is met, should it throw an exception? If so, of what type? All those questions can be answered by writing good documentation, that’s true, but, what about enforcing those rules? And who writes good docs in a world where working code is more important than documented code? That’s where the documenting facet of unit tests come in handy.

Posted on

How to Increase Java Testing ROI With Parasoft Jtest

In today's digital economy, companies have to deliver software faster to the market to keep pace with consumer demand. To achieve this without sacrificing quality and security, organizations have to be able to effectively test software code changes thoroughly and quickly. But achieving this thorough testing can be a bottleneck, bringing stress and risk to software teams, delaying delivery, and having a direct impact on the business.

One of the biggest contributing factors to software project delays are bugs discovered late in the development process, which occurs because the business puts pressure on development teams to maintain schedules, having a direct side effect on testing and product quality. To help address this issue, development teams leverage unit testing and static code analysis to expose defects earlier in the cycle; however, these practices come with drawbacks of their own, related to time and cost, that can cause a delay in achieving quality at speed.