Have you wondered how the teams working on Telerik products test software? In the next 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 seventh 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, 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
The Developer Tools Division comprises many teams, each with a specific product focus, including:
We use the Scrum methodology to plan, package and release software products. We ship a major version three times a year. Approximately a month after a major release we deliver a service pack with minor revisions. Additionally, some teams release internal builds weekly containing the latest bug fixes. This dynamic cycle determines our milestones before releasing a product and our testing cycle which guarantees the quality of our software.
For major releases we define two important timeframes:
For service packs, we define one milestone:
Definitions of “Complete”
An issue is resolved when the issue is logged correctly into TeamPulse/TFS. It must be set to “Ready for Test” by the developers and include short notes of tested cases during fixing. The code is then merged into all appropriate branches. A feature is complete when it’s logged correctly into TeamPulse/TFS and a functional documentation specification is present. Then the feature is implemented, and unit tests are performed if possible. A help article and/or SDK example should also be present. Test plans and functional tests are completed, if possible, by the QAs.
We have a policy to distribute an internal build at least once a week. Code reviews are performed per check-in and are mandatory for every team member. Every fix that will be included in the weekly internal build has the highest priority in the QA backlog for testing.
The robust CI process that we have implemented allow us to do this and guarantee an increase of quality with every new version.
We set up different environments to cover all major customer scenarios and cases. These include variations of OS, Browser, Visual Studio, CI tools, Source Control tools, TeamPulse, third-party integration tools, databases and so on.
The first verifications are developer-written unit tests. Developers write unit tests to ensure server-side code or is working as expected. They are triggered as part of the CI build for every supported framework, which happens after every single check-in.
We log and manage all found issues during testing. All issues from customer tickets and all feature requests are logged and managed in GitHub.
Functional tests are based on tasks created from developers and written in TeamPulse.
For example, for Kendo UI online demos we have a number of staging servers for the different platforms (JSP, MVC, PHP) and development versions (current version fixes or next version features). We also have a staging server with stubs (replication examples) of already fixed issues. Functional tests executed on these stubs make sure no regression will occur for already fixed issues. We maintain a set of functional tests of Kendo UI Mobile for Android that can run on a simulator or a real device. With the help of Test Studio team we develop and maintain Test Studio extensions for the Kendo UI framework that are of great help for Test Studio users who create functional tests for Kendo UI.
Automated tools used include:
Manual Functional Testing
Not everything can be automated. In some cases, we perform manual functional testing. This is useful:
Next time, we'll talk about continuous integration, API and stress testing within the Telerik Dev Tools division.
Did you find these tips helpful? Stay tuned for the next chapter and let us know your feedback. And don't forget to register to receive the eBook that will be put together when this series is complete.
If you are interested in trying the latest Test Studio, feel free to go and grab your free trial today.
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.