Webhooks that we now know of have been around already for more than 10 years. In 2007 Jeff Lindsay who at the time was working at NASA as a Web Systems Architect started bringing webhook ideology into the light. Although it was only after couple of years that its popularity started really gaining traction. Github has used webhooks since late 2010 but acknowledged the full potential of webhooks only at the beginning of 2014 and made it as one of the primary features for the public. They started to offer more configuration, customization and debugging options for anyone using webhooks. Since then it has become a buzzword in the developer’s world. But let’s quickly go over what it really is.
The way Jeff Lindsay describes it in his first blog post about the next big thing is: “Web hooks are essentially user defined callbacks made with HTTP POST. To support web hooks, you allow the user to specify a URL where your application will post to and on what events. Now your application is pushing data out wherever your users want. It’s pretty much like re-routing STDOUT on the command line.”
So it’s made clear that it is a tool or process that empowers users to receive important data whenever something happens on the web service side. It means that no polling on status change and long waits on synchronous HTTP requests is required. Service will just use the URL that was provided by the user to notify and send along the appropriate data.
Technically to be able to provide webhooks to users is as simple as adding functionality to send certain data on certain events to a dynamic URL. However on user’s side there has to be an HTTP server that can receive the data to the provided URL endpoint. This webhooks functionality has helped to provide server to server communication in a lot of automation scenarios across many services.
Acceptance tests simulate real user actions and very often are done on real devices. These kind of automated tests run quite a long time. In some cases many hours, especially when acceptance stories have to be validated on multiple devices. But fast feedback from tests is very important in development process. To achieve that we need to decrease test execution time. But how? Good idea would be to run these tests simultaneously on all devices, right? But it’s not going to be so simple.
Calaba.sh acceptance test framework for iOS applications uses Apple “UI Automation” to launch and control these applications, but Apple has limited possibility to use multiple instances of “UI Automation” on the same Mac OS X operating system. For unknown reason Apple “UI Automation” instance uses predefined port which cannot be changed and more than one instance is not possible to launch on a single port.
Did you know that most mobile applications that we use daily have at least one security vulnerability that can be used to alter or even steal our private data? With the new EU General Data Protection Regulation looming just around the corner, situation is dead serious. That’s why our Senior Quality Assurance engineer Kristaps Felzenbergs chose the topic of Mobile Application Security for his presentation at the biggest software testing conference in Baltics – TAPOST 2017.
Time flies so quick! A full week has passed since we returned home from the SIGNAL London 2017 conference organized by our partner and communications expert Twilio. We’ve been to a number of SIGNAL conferences across the world before and it still is the best conference about the communications industry.
It’s a great event to meet companies and individuals who advance communications technologies and this time Twilio launched Twilio Studio – a service that can be used even by non-developers to build customer engagement applications like messaging bots, voice response and order notification systems, appointment reminders and even more. And it is really simple, you can drag-and-drop elements in a web based application. You can read more about Twilio Studio at Twilio blog. Recorded sessions of presentations can be viewed here.
Nowadays, when the industry is dominated by agile development, lean startup methodology, minimum viable product mindset, companies want to develop, test and deliver their projects to clients as fast as possible. This means that hybrid app development popularity has significantly increased. Even such tech industry giants as Uber, Skype and, in some parts, Instagram are using this kind of technology in order to create apps fast while, at the same time, reducing costs for development and maintenance.
For us, QA engineers, this means that we need to be prepared to work with these kind of applications, which in essence are not very different from native or web apps. As the term “hybrid app” in this sense is almost self explanatory, in order to create test frameworks for these kind of apps we need to know a little bit of both.
Appium test automation framework has support for testing hybrid apps via ChromeDriver (for Android starting from API 19) and Selendroid (for Android API 14 to API 18). In this post we will use Android API >= 19. Since hybrid app automation slightly differs from native app automation, in this article we will tackle specific issues to hybrid app automation testing like managing application contexts, finding element selectors, and using touch actions in a webview.
Lately we have been really busy building our own software testing products and today I want to tell you more about one of them. Test48.com is a testing service that we like to call as “Your Own Test Team In The Cloud!”.
You can submit your Android/iOS application’s release candidates or work-in-progress builds to Test48.com, choose from hundreds of real devices to test your app on, and in 48 hours receive a bug and improvements report prepared by our ISTQB certified testing professionals. I want to emphasize: all testing is done on real physical devices and only by professional testers.
Last month we published a blog post about setting up specific network conditions for software testing. In that blog post we shared our knowledge on how to set up specific network conditions using built-in tools in your web browsers or operating systems and explained a more sophisticated solution based on a router. Today we want to advance this topic further with useful information on traffic mirroring to Wireshark. This technique is useful for testing how applications are communicating between themselves or remote devices without interfering with device itself.
When it is necessary to monitor mobile device traffic and capture network traces with Wireshark, iptables-mod-tee library allows network router to mirror all traffic from a specific Client (for example, a mobile device) to another host. This example will show you how to capture mobile device traffic to a host computer with Wireshark.
Newest versions of iOS and Android mobile platforms will be launched in a couple of months and beta versions are already available.
Are you 100% sure that your mobile app will work as intended on Android 8 “O” or iOS 11? We think it is about time to test all mobile apps on devices running Android and iOS betas.
Network checking is part of the non-functional testing. It is often required for communication applications and other network dependant mobile software to check behaviour over various network profiles, complete loss of network connection and network handover. Since mobile software needs to be designed to be truly “mobile” the testing should check for critical bugs and overall usability of the software being able to cope with the changing network environment.
As we are testing mobile applications every day, we use a number of tools and techniques to test how these applications perform under different network conditions. In this blog post we would like to share our knowledge on how to set up specific network conditions using built-in tools you can find in your web browsers or operating systems. Then we will dive in deeper and show you how we created a more sophisticated solution based on router.
Modern technology advances fast not only in the software, but also the hardware industry. To provide quality services and satisfy clients, software testing plays an increasingly important role in the software industry. Given that the number of applications and devices steadily grows new tools for testing are needed as well.
Automation is very important in software development and testing. However, there are cases when test steps need to be done by a human. Such manual work often causes problems, because the test engineer can make mistakes. Furthermore, computerised and robotic automation is more suitable for performing repetitive actions. Additionally, software cannot fully cover full scope of testing. Therefore, we had an idea to build our own robot that could simulate finger taps on a smartphone screen or press physical buttons, something that cannot be simulated with software.