Important note: After its completion, this series will be gathered up, updated/polished and published as an eBook. Interested? Register to receive the eBook by sending us an email at firstname.lastname@example.org.
Telerik Platform brings together various products and services. It requires ample coordination between all testing teams, to facilitate the development of mobile apps and provide developers with everything they need. These include:
By combining these elements, Telerik Platform provides a way to visually define the mobile app user interface, develop the functionality behind this UI and facilitate mobile app server-side requirements. Leveraging Analytics, developers can get closer to the end users, then collect feedback from the end user and move to testing with Telerik Test Studio.
To assure the best possible quality for such a diverse platform is quite challenging. For each component, all features must work according to the specification, but the platform must provide seamless integration between all components.
In developing Telerik Platform, we introduced thousands of integration tests to verify integration points between services, including user experience and performance tests. There is no centralized QA team for the entire Telerik Platform—thirty QA engineers work collaboratively in several teams to keep up its quality. This adds further complexity to the task of executing the common testing tasks efficiently.
When we started working together, each team had its own, disparate tests. We started with service testing which covered the integration points between all services. Each team handled its own portion.
Next, we established a schedule for the different teams to execute common tests. All common service tests were scheduled to be executed against all test environments orchestrated by Jenkins, which provided a common place where each team member could observe the status of a particular functional area.
Still, adding tests and executing them across different environments increased the number of Jenkins jobs dramatically, necessitating a way to gain better test visibility. To that end, we built Dashing dashboards, which could be observed on TVs in each team room. At this point, we had established processes for common service tests, UI tests and performance tests, all of which were split across different teams and maintained independently.
We also invested in resilience testing as the teams found it should be an integral part of their testing process.
To facilitate the testing process, we needed a common communication channel. We set up mail groups and IM channels to enable communication between QAs across different teams. Next, we implemented the Telerik TeamPulse feedback portal as part of our QA process. Each QA could submit an idea in the feedback portal; then we voted for the ideas we thought were the most important.
The correct functioning of a single service or component in Telerik Platform is as important as the correct functioning of the entire platform. Functional testing therefore verifies the quality and functionality of all service layers. We use both manual and automated tests for UI, REST and Integration testing. The test types are executed continuously.
All of the test types are executed through a CI tool, which enables us to keep a history of the results, coordinate the tests and integrate the reports with other systems for monitoring and quality estimation.
Cloud services live in an environment where one thing is 100% certain: at some point, something will fail.
Consider a Cloud solution that includes a web server, database server and cache server. A simple UI deployed on and served by the web server collects data from the database server and displays it in the end-user's browser. For better performance, the web server leverages the cache server to decrease the number of requests to the database server. Resilience tests are used to determine the end-user experience should the cache server fail.
A desired outcome is that the end user can still use the cloud solution, regardless of a failed cache server. Performance may be impaired, but the solution should still work.
The Telerik teams test our services when there are missing functional requirements as well as infrastructure dependencies. We strive to answer questions such as:
Automating start/stop procedures of particular infrastructure elements simplifies and accelerates the execution of well-documented resilience scenarios. We manage the start/stop procedure from a web interface to provide the QAs better control over particular infrastructure components, and to visualize all infrastructure elements.
Considerations for preparing resilience tests include the execution environment and defining the testing scenarios. Today, scenarios are defined, tested and documented in Excel spreadsheets. Found bugs are logged into TeamPulse for planning future iterations.
Security is one of the most important non-functional characteristics of enterprise software quality. Unfortunately, security testing is often neglected, as many project stakeholders underestimate the negative impact of a lack of security on the project or company.
We take security testing seriously. Our enterprise customers require established security policies, process control and compliance with certain security standards. To that end, we have the following goals around security testing:
We perform security testing in two categories: black box and white box:
For a quality product, you must achieve good results in terms of response time and server resource utilization with expected load. However, it’s also important to test our systems under stress—when more users access them than expected.
To do so, we simply increase the number of expected virtual users using the “controller-agent” approach. In this approach, each controller manages numerous agents. Controllers and agents are hosted by a cloud-based hosting provider to enable load to be generated in a geographically dispersed manner. (Generating load from a single point in some cases may produce incorrect results for the overall performance of your system.)
Did you find these tips helpful? Stay tuned for the next chapter which will continue the story of the Telerik Platform team and how they go about test execution and reporting.
If you are interested in trying out the latest Test Studio, feel free to go and grab your free trial.
Angel Tsvetkov is an experienced, goal-oriented Quality Assurance Architect for the Telerik Platform with proven ability in test automation. He has exceptional ability to enter new environments and produce immediate results through the use of flexible test techniques with excellent communication skills.
Copyright © 2016, 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.