A common misconception with companies trying to create a functioning automated test framework is that they can deal with integrating it into their Continuous Integration process, test environments and data sets later in the process. The reality is that they probably have an initiative to work on Continuous Integration, Continuous Deployment or possibly DevOps. Automated testing is an integral piece of CI/CD/DevOps and should not be developed separately from them.
Most automated test frameworks being created today extensively use tools such as Maven to provide required test artifacts, Nexus to store these artifacts, tools such as Jenkins or Bamboo to kick off the test runs and version control tools such as SVN or GIT to store your test code. The coaches at ATF will not only help you determine which set of tools is right for you, but they will show you how to properly set them up and integrate your automated test framework into the CI process.
The ability to consistently build test environments is a critical building block in DevOps. A common mistake that companies make is to unknowingly try to use their automated testing as a safety net for a poor build process. Having a build process that is not consistent allows for the introduction of variables into the process, which in turn introduces drift. Trying to track down the root cause of test failures in a build process which does not create consistent known test environments, ties up valuable resources and increases costs.
Another consideration that must be taken into account before starting the process of building an automated test framework is what test data will be used, how it will be loaded and how can it be torn down. Our coaches at ATF can help you develop test data sets that work best for your particular situation and show you the various options for loading this data and how and when to tear this data down.