![]() ![]() Providing instant feedback on the failures is needed to build trust in the QA Robot.One way we accomplished this was to wait for dependent services to be in a good state and then only running the tests once, then combined the results into one report at the end of the run. As the QA Robot matured and started picking up more tickets, more tests were running concurrently, so we needed to look for ways to be efficient.This is facilitated by having detailed documentation, constant communication and training sessions. We rely on users to create pull requests and update Jira in standardized ways. Process plays a huge part in success for this project.Because our script calls many third-party services (GitHub, Jenkins, Jira), we are often troubleshooting issues and adjusting our code to accommodate when their systems presented issues.Once we saw that the integration of running our tests after the script deployed the code and updating Jira tickets with the results was seamless, we moved forward with converting the rest of our tests. We converted a few tests at first and made sure they’d work well with the QA Robot. This required us to spend time converting our existing tests from Cucumber to Robot Framework before fully rolling out. We used Robot Framework in the QA Robot since it’s an automation framework built on Python, making it easy to integrate with our script. We use the Jenkins API library to deploy our code. Our script uses the Jira API library to identify which tickets to test, then uses the GitHub API library to determine if the pull request is actually ready for testing. We decided to use Python primarily because of its abundance of libraries that would make this easier to solve - plus, a few members of our team were already familiar with the language. This was tricky, potentially risky, and we wanted to be sure we had it right. We knew we weren’t going to get it right the first time, so we made sure to give ourselves time to learn from our mistakes and make improvements. Phase 2: Learning and making improvements These areas are pretty straightforward and are good wins for the QA team. To make building this tool a little less daunting, we broke it into a few phases: Deploying a ticket to the production environment.Running automated tests and reporting the result.Verifying that a pull request is mergeable.Deploying a ticket to a staging environment.The tasks that we identified as being automatable were: The tool, which we dubbed the QA Robot, would help us scale along with our fast-growing development team and allow us to focus on more important aspects of quality. A little over a year ago, we started building a QA tool that would automate most of our daily tasks outside of our automated tests. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |