Where to save test automation scripts?
I had a problem. While developers were pushing code to their repository, I was unable to test their implementations in the pipeline. I was unable to synchronise my tests with the branch a developer was working on. Therefore, if the developer pushed some code, then my tests did not cover this implementation before merging to the master branch. Also, the tests were outdated frequently; therefore, they used to report incorrect results.
This article describes how to solve these problems, i.e., how to:
- Test implementations in the pipeline.
- Synchronise tests with the branch that the developer is working on.
- Make sure the tests are always up to date.
- Report the right results.
During the last 13 years, I have experimented with several approaches in software testing, from working in a different sector to working together with developers. The diagram below illustrates the approach with a testing sector.
With the advent of agile methodologies, testers started interacting more with developers. Now the role is more oriented to Quality Assurance (QA), and there is daily cooperation among team members.
Tests running in the pipeline
The more I worked in agile teams, the more I felt that the QA should provide mechanisms for testing a branch once a developer pushes code to the repository. By doing this, we receive instant feedback from our tests about whether or not the implementations our team did are working as expected.
We added tests in the deployment pipeline.
Then we faced some problems:
- When developer pushes code to the application repository then the test automation repository does not adhere to those changes. Therefore, tests fail in the pipeline (false feedback from tests for that branch).
- If we update the test automation repository at this moment, then our changes take effect in all pipelines even when some do not have the changes of one specific branch. Therefore, tests fail in all of the other pipelines (false feedback for other branches).
- If we have our continuous integration tool calling a branch with the same name in the test automation repository then we also face a problem because this branch does not exist in the test automation repository at the first time we push a branch. We face the first problem described above.
I could not trust the test results. Nobody could.
Testing at the same repository
Nowadays, it is possible to choose the technology we want for testing, among many, so we could code tests using the same programming language the developers use. As the QAs were working on the same team of developers, we were able to implement tests in the same repository they worked on.
Now tests sync with the code. And we can adjust tests while we adjust the code.
This made it easy for developers to give insights and collaborate with QAs on improving tests, and vice versa. We are now able to automate a test even when the developer’s code has not been pushed yet — and we always get the right results from tests — awesome.
Improving the process
The last step was to improve the process with my team for being able to automate tests while we implement the feature, not after merging developer’s code.
Problem solved! Now we test implementations in the pipeline. We synchronise tests with the branch that the developer is working on. Therefore, if the developer pushes code, then the tests cover those changes before merging to the master branch. Also, our tests are always up to date, and they report the right results.
Conclusion
We can code tests in the codebase when there are technologies supporting it. Independently of the codebase, it is worth checking whether or not the team can code the tests in the codebase.
When the tests are saved in the codebase then we can adjust the tests while we adjust the code, therefore the tests are up to date. The team can trust the test results. Also the practice of coding tests in the codebase increases the collaboration among team members.
Suggestions? Feedback? Feel free to comment here or find me on LinkedIn. Make sure to check out our careers page to discover tech jobs at Takeaway.com!