Ближайшая конференция — HolyJS 2020 Moscow
25-28 ноября, Online
Подробности и билеты: https://holyjs-moscow.ru/
Puppeteer is a Node library that provides a high-level API to control Chrome over the DevTools Protocol. It is mostly used and considered for scraping content, UI testing and automated form submissions. This talk aims to change this mindset by inspiring you on observing your daily routines and common patterns on your development and testing workflows. It will help you automate them in a creative way!
We’ll explore capabilities of Puppeteer with the combination of DevTools protocol and cloud functions (FaaS) across a showcase of real life use cases demonstrated over more than a dozen demos on stage. Finally, we’ll go through existing Puppeteer based SaaS solutions to inspire everyone in the room to build the next SaaS solution or open source project with Puppeteer.
#puppeteer #api #developer #programming
Want to try automated inventory management system for small businesses? Originscale automation software automate your data flow across orders, inventory, and purchasing. TRY FOR FREE
#automation #automation software #automated inventory management #automated inventory management system #automation management system #inventory automation
Thorough testing is crucial to the success of a software product. If your software doesn’t work properly, chances are strong that most people won’t buy or use it…at least not for long. But testing to find defects or bugs is time-consuming, expensive, often repetitive, and subject to human error. Automated testing, in which Quality Assurance teams use software tools to run detailed, repetitive, and data-intensive tests automatically, helps teams improve software quality and make the most of their always-limited testing resources.
Use these top tips to ensure that your software testing is successful and you get the maximum return on investment (ROI):
It is impossible to automate all testing, so it is important to determine what test cases should be automated first.
The benefit of automated testing is linked to how many times a given test can be repeated. Tests that are only performed a few times are better left for manual testing. Good test cases for automation are ones that are run frequently and require large amounts of data to perform the same action.
You can get the most benefit out of your automated testing efforts by automating:
Success in test automation requires careful planning and design work. Start out by creating an automation plan. This allows you to identify the initial set of tests to automate and serve as a guide for future tests. First, you should define your goal for automated testing and determine which types of tests to automate. There are a few different types of testing, and each has its place in the testing process. For instance, unit testing is used to test a small part of the intended application. To test a certain piece of the application’s UI, you would use functional or GUI testing.
After determining your goal and which types of tests to automate, you should decide what actions your automated tests will perform. Don’t just create test steps that test various aspects of the application’s behavior at one time. Large, complex automated tests are difficult to edit and debug. It is best to divide your tests into several logical, smaller tests. It makes your test environment more coherent and manageable and allows you to share test code, test data, and processes. You will get more opportunities to update your automated tests just by adding small tests that address new functionality. Test the functionality of your application as you add it, rather than waiting until the whole feature is implemented.
When creating tests, try to keep them small and focused on one objective. For example, separate tests for read-only versus reading/write tests. This allows you to use these individual tests repeatedly without including them in every automated test.
Once you create several simple automated tests, you can group your tests into one, larger automated test. You can organize automated tests by the application’s functional area, major/minor division in the application, common functions, or a base set of test data. If an automated test refers to other tests, you may need to create a test tree, where you can run tests in a specific order.
To get the most out of your automated testing, testing should be started as early as possible and ran as often as needed. The earlier testers get involved in the life cycle of the project the better, and the more you test, the more bugs you find. Automated unit testing can be implemented on day one and then you can gradually build your automated test suite. Bugs detected early are a lot cheaper to fix than those discovered later in production or deployment.
With the shift left movement, developers and advanced testers are now empowered to build and run tests. Tools allow users to run functional UI tests for web and desktop applications from within their favorite IDEs. With support for Visual Studio and Java IDEs such as IntelliJ and Eclipse, developers never have to leave the comfort of their ecosystem to validate application quality meaning teams can quickly and easily shift left to deliver software faster.
Selecting an automated testing tool is essential for test automation. There are a lot of automated testing tools on the market, and it is important to choose the automated testing tool that best suits your overall requirements.
Consider these key points when selecting an automated testing tool:
For detailed information about selecting automated testing tools for automated testing, see Selecting Automated Testing Tools.
Usually, the creation of different tests is based on QA engineers’ skill levels. It is important to identify the level of experience and skills for each of your team members and divide your automated testing efforts accordingly. For instance, writing automated test scripts requires expert knowledge of scripting languages. Thus, in order to perform these tasks, you should have QA engineers that know the script language provided by the automated testing tool.
Some team members may not be versed in writing automated test scripts. These QA engineers may be better at writing test cases. It is better when an automated testing tool has a way to create automated tests that do not require an in-depth knowledge of scripting languages.
You should also collaborate on your automated testing project with other QA engineers in your department. Testing performed by a team is more effective for finding defects and the right automated testing tool allows you to share your projects with several testers.
Good test data is extremely useful for data-driven testing. The data that should be entered into input fields during an automated test is usually stored in an external file. This data might be read from a database or any other data source like text or XML files, Excel sheets, and database tables. A good automated testing tool actually understands the contents of the data files and iterates over the contents in the automated test. Using external data makes your automated tests reusable and easier to maintain. To add different testing scenarios, the data files can be easily extended with new data without needing to edit the actual automated test.
Typically, you create test data manually and then save it to the desired data storage. However, you will find tools that provide you with the Data Generator that assists you in creating Table variables and Excel files that store test data. This approach lets you generate data of the desired type (integer numbers, strings, boolean values, and so on) and automatically save this data to the specified variable or file. Using this feature, you decrease the time spent on preparing test data for data-driven tests.
Creating test data for your automated tests is boring, but you should invest time and effort into creating data that is well structured. With good test data available, writing automated tests becomes a lot easier. The earlier you create good-quality data, the easier it is to extend existing automated tests along with the application’s development.
Automated tests created with scripts or keyword tests are dependent on the application under test. The user interface of the application may change between builds, especially in the early stages. These changes may affect the test results, or your automated tests may no longer work with future versions of the application. The problem is automated testing tools use a series of properties to identify and locate an object. Sometimes a testing tool relies on location coordinates to find the object. For instance, if the control caption or its location has changed, the automated test will no longer be able to find the object when it runs and will fail. To run the automated test successfully, you may need to replace old names with new ones in the entire project, before running the test against the new version of the application. However, if you provide unique names for your controls, it makes your automated tests resistant to these UI changes and ensures that your automated tests work without having to make changes to the text itself. This also eliminates the automated testing tool from relying on location coordinates to find the control, which is less stable and breaks easily.
#automation-testing-tool #automation-testing #automation-tips #automation-software #automation
TestProject is a free automation tool that promises to give painless automation experience. It has the feature of record and plays associated with a developer SDK. It also has the capability to build and utilize addons as per need. It is based on automation tools like Appium and Selenium.
Having said that, TestProject removes the complication of maintaining and downloading multiple browser drivers required for testing an application in various platforms and browsers. This is overcome by having an executable file that can run in the majority of browsers and devices.
#automation #automation testing #codeless test automation #scriptless test automation #test automation #testproject
I’m a Developer Advocate and one of the things I love most about my role is that I travel all of over the world — meeting and consulting with engineering teams, and discussing the challenges that they face.
One thing that I’ve realized about building quality software is…the struggle is real!
Everyone is trying to figure out how to rapidly-produce software that is yet of high quality. So we did some research (shout out to Moshe Milman who helped with this effort) and gathered best practices from some of the top companies in software, financial services, healthcare, gaming, and entertainment verticals and I’ll share with you what these innovative development teams are doing to achieve great levels of success with their test automation initiatives.
As I go through the points of research, feel free to grade your team’s maturity in that respective area. By the end of the article, you’ll have your Test Automation Maturity Level.
100% of companies researched automate their tests
For starters, 100% of the companies we researched employ automated tests to expedite their release cycles. When the goal is to release software on a continuous cycle, test automation is a must-have. There simply isn’t enough time to manually test every new feature as well as manually execute regression tests to make sure existing functionality isn’t broken. So these teams invest an extensive amount of effort into automating their tests so that they are confident in their product each time they deploy.
Percentages showing who on the team is responsible for writing tests
I know from personal experience how difficult it is for developers to find the time to write tests and also how difficult it is to have test teams write the code to automate tests, so we inquired about this a bit more to determine how are teams overcoming these challenges.
Every single one of these companies has its developers involved in writing tests. Many of them said their developers take care of the unit tests, while the QA team is responsible for writing the integration and end-to-end tests.
A whopping 60% of the teams shared that they no longer have the distinction between development and QA engineers, and instead have hybrid engineers. Their goal here is to have developers own ALL the testing of their code, as well as the triaging and maintenance of those tests.
What they discovered is what I already know — developers aren’t the best at this. There’s not much time, and frankly not much interest from developers to go beyond writing their unit tests. So, many of these teams have had to bring in qualified experts to help out.
I dug a bit more to learn how exactly the Quality Advocates are assisting here. We got a variety of answers but here were some of the common ones:
Let’s discuss each of these…
Write Test Infrastructure
The Quality Advocates find the best testing libraries, create the test automation codebase, and all of the utility functionality the developers will need to write their tests. That way it’s not much overhead for the developers. The developers can just focus on cranking their tests out.
Unfortunately, many of the Computer Science and Bootcamp programs that graduated your developers did not teach them how to test. This is a huge hurdle for developers who may have good intentions and want to test their code. They may not ever share this with you, but a LOT of the developers that I speak with simply don’t know how to test. These quality advocates specialize in this stuff and can help the developers think of scenarios, as well as teach them how to write good tests. If you think this may be a problem for your developers and you don’t have a quality advocate just yet, send them to Test Automation University which is an online learning platform that provides free courses on this very thing.
Finally, quality advocates develop testing strategies for the team. They help them assess risk and come up with a plan of attack on what should be tested and how thoroughly.
They also have a big picture view which is greatly needed because your developers are zoned in on their features and their tests. Someone needs to consider how these features interact with one another so that more sophisticated tests can be developed.
Someone also needs to strategize on which tests automatically run given certain pull requests. The advocate can help with that.
The quality advocates also help keep the test suites relevant by pruning out tests that are no longer of high business value.
If your team automates _any _tests at all, go ahead and give yourself 10 points!
We wanted to make sure that we were talking about more than unit tests here, so we inquired about which tests the companies automated.
Give yourself 10 points for each of the types you automate: unit, web/mobile, API, security, performance, and accessibility. If your team does not develop mobile apps, just give yourself 10 points so that you don’t have a deficit. The same goes for if your company does not develop web apps or APIs.
Programming languages used for test automation
I found this interesting because it aligns with what some thought leaders have been preaching for years. I’ll admit, I’ve been a bit stubborn over my career and I tend to go for the language that the automation will be most comfortable in but it seems perhaps I need to rethink that when I want the developers to contribute.
#tutorial #performance #testing #programming #automation #test automation #automated testing #qa #automated testing best practices
I took Nyran Moodie’s course on Test Automation University: Automated Visual Testing with WebdriverIO.
If you use WebdriverIO regularly, and you are unfamiliar with the basics of using Applitools for automated visual testing, you will appreciate this course. Nyran focuses you on how to add visual test automation with Applitools to your WebdriverIO tests.
Nyran expects you to know WebdriverIO. If you want to learn WebdriverIO, check out Julia Pottinger’s excellent course — UI Automation with WebdriverIO on Test Automation University.
Nyran breaks the course into eight main chapters. He gives this description in the course overview:
Each of these chapters provides a methodical approach to getting going with Applitools. I’ll give a quick overview of each.
If you read this review or take the course, you know why visual testing. Your UI and end-to-end tests result in the rendered output. You can write all the functional tests that grab locators, enter data, effect action, and cause the appropriate output locators to have the appropriate values. But, until you look at the result, you cannot tell if the input and output conform to design and usability expectations.
Nyran did not explain the most frequently-experienced reason for visual testing — unintended consequences of code changes over time. Our experience shows us that most expected application changes get tested, but unintended changes cause problems.
Nyran does a nice job explaining how to get started. You need an Applitools API key, which you can get from the Applitools console. Nyran explains why you set up a local environment variable for your API key (so you do not need to include your API key in your test code directly). He also points to the GitHub repo he uses for all the examples in the course.
Chapter 3 involves the first coding examples for setting up Applitools. With a simple:
npm install @applitools/eyes.webdriverio
You get the the node instructions for installing the Applitools Eyes to your WebdriverIO setup. After this, you can install the Applitools Eyes service to your tests. He shows code examples of what test code looks like when calling Applitools:
#performance #testing #automation #automated testing #webdriver #visual testing #automated testing best practices #webdriver io #ui automation tools