Tutorials and resources on how to apply test automation in software testing
More and more organizations build test automation frameworks based on the WebDriver and Appium tools to perform software testing their web and mobile projects. A big part of why there are so many flaky tests is that we don’t treat our tests as production code. Moreover, we don’t treat our framework as a product.
The shift towards mobile platforms is a strong trend currently and Android is the most widely adopted mobile OS with an estimated market share above 80% in 2014. You should naturally test all the apps developed for Android and a large number of open source testing tools and test automation frameworks have been developed to achieve this goal.
It doesn’t matter if you are developing software with Java, .NET, PHP or another language. If you need to do performance testing – it will be a challenging task, especially nowadays with microservices architectures, clusters and very complex systems. This presentation addresses the most common pitfalls of performance tests. The presenter shares his experience gained through demanding experiments and quite often frustrating failures.
The current trend in software testing might be to talk about test automation or artificial intelligence, but in some cases nothing replace the intelligence of a human tester to detect bugs and consequences of irrational user behavior. This article present a list of exploratory testing extensions available for the dominant Chrome browser.
Running more than 5000 automated system tests on a deployed application with outgoing connections to about 25 other systems, each with their own dependencies, where test data is complex and needs to be in-sync, is a great challenge. Doing it every night, year after year, with the requirement to fail only on the event of actual errors in the application under test, is a nightmare.
One of the most widely touted drawbacks of the automated tests is that they work in strictly bounded context. They can only detect problems for which they are specifically programmed. The standard automated test has a bunch of assertions in the last step. By definition, an automated test cannot detect an ‘unknown’ problem. Because of their narrow focus, the automated tests are occasionally compared to dumb robots. It takes a lot of time and effort to write and support them however their return on investment is still marginal.
Different people from the software testing field can have completely opposing opinions about the process of test automation. Sometimes it happens that after a while, the initial expectations and hopes of this substantially costly investment are not justified at all. In simple words, test automation does not bring the expected profits. In this article, we will try to understand why such situations happen and how to avoid the most common mistakes.
Copyright © 2009-2019 Martinig & Associates