Have you wondered how the teams working on Telerik products test software? In the final chapter of our detailed guide, we give you deeper insight into the processes of our Web Division. You can find past chapters here.
You’re reading the eighth and final post in a series that’s intended to give you a behind-the-scenes look at how the Telerik teams, which are invested in Agile, DevOps and TDD development practices, go about ensuring product quality.
We’ll share insights around the practices and tools our product development and web presence teams employ to confirm we ship high quality software. We’ll go into detail so that you can learn not only the technical details of what we do but why we do them. This will give you the tools to become testing experts.
Important note: After its completion, this series will be gathered up, updated/polished and published as an eBook. Interested? Register to receive the eBook.
Register for the eBook Now
Integration testing is an additional step used when we create an application with different components. It verifies that the components work together. We use Appium, an open source test automation framework. Tests are written in Java.
The testing process starts with developers writing unit tests, which cover main functionality on new features, or entire new components. After every check-in, an automatically triggered continuous integration build begins, which is our first step to verify we will be shipping quality software
Every night a nightly build is executed which generates the latest version of our product. It includes installation files, dlls, examples, source code and nugget packages. Most of the time, QA works with the latest daily build, which enables them to see newly introduced issues as soon as they occur. During the code freeze, we execute the same build a few times a day.
Part of our product is open-source. External contributors’ commits in our public repository can happen only via pull requests approved by a developer on the Telerik team. Pull requests are merged into the master/release version, only if a set of automated smoke tests pass and the request is approved by at least two team members. This helps us to have stable master/release branches at all times.
Automated API-level Tests
These tests are executed against our REST APIs. The tests are much faster than UI tests and are often used for confirmation for sanity of the latest build.
TFS builds with tests running against predefined controls examples are used for CI. The same tests (if possible) are run against different branches every night or per check-in, depending on the branch.
We use the industry-leading tool, JMeter, to perform our stress tests against before major releases. Usually, stress tests are run in various combinations to analyze system behavior when new features are implemented.
Regression testing using UI Automation runs to cover UI and Functionality through UI, including E2E scenarios for each major feature.
The various divisions share knowledge in a few different ways, as follows:
Did you find these tips helpful? We hope you enjoyed this series—please let us know your feedback. Don't forget to register to receive the eBook that will be put together now that this series is complete.
If you are interested in trying the latest Test Studio, feel free to go and grab your free trial today.