Category: <span>Features</span>

Continuous integration and continuous delivery for modern testing automation with Trudon

Continuous integration and continuous delivery for modern testing automation with Trudon

In a world where teams are releasing product updates faster than ever before, new challenges have appeared. Quality assurance and testing have become a significant bottleneck for teams due to the time it takes to run and maintain reliable, effective tests.

However, by integrating automated testing directly into continuous integration (CI) and continuous delivery (CD), development teams can adequately support rapid release cycles without sacrificing application quality.

How CI/CD works

Earlier, every developer used to do their development related tasks independently, and other team members were unaware of what their colleague is doing. Using continuous integration, developers maintain their code in one place and integrate it into the repository’s main branch.

Developers used to submit code at the end of the cycle, which lead to more bugs and testing related issues.

Integration costs can be reduced using continuous integration as the developers integrate their code from the very beginning. Following this approach, the conflicts can be resolved earlier, which will save a lot of time and cost. The main aim of CI is to make everyday development tasks simple that can save time and reduce costs.

Continuous delivery comes next to continuous integration, which makes the software delivery process easy. Using continuous delivery, code can be safely deployed to production. Code at this stage can be deployed on the spot. There is no sense of urgency and extraordinary late-night shifts for releasing the code to production. CD is majorly dependent on the deployment pipeline and teams can automate the testing and deployment processes.

At Trudon, we do an average of 7 production deployments every single week, thanks to the CI/CD pipeline and to the end-to-end tests we have in the process.

After failing the critical test in the deployment pipeline, developers can be notified about the issues. If everything goes well, then the pipeline will deploy the code to the production-like environment. Since the build, deployment, and environment are all tested together, the resulted code is deployable to the production environment.

Benefits of continuous integration and continuous delivery

  • Smaller code changes and fault isolations
  • Faster time to bug identification and bug repair
  • Faster and better releases
  • Increased customer satisfaction
  • Increase team transparency and accountability
  • Improve collaboration on issues between QA engineers and developers
  • Reduce costs and maintenance

Continuous integration with Trudon

Trudon is a fast, easy and reliable regression testing platform that allows QA teams to create, customize and run cross browser/device end-to-end tests.

With a highly scalable infrastructure for testing automation, with multiple browsers, screen resolutions and mobile devices, Trudon offers continuous integration and continuous delivery integrations.

Using smart runs to configure a test suite run, you can run periodically, trigger manually, or be part of your CI process. Check the documentation here.

Conclusion

If you want a high-paced development team, you need to transition to a CI/CD process. Testing is a large part of that process because even if you can make your integrations and delivery faster, it would mean nothing if it was done so without quality in mind. The more steps of the CI/CD pipeline that can be automated, the faster quality releases can be accomplished.

Data driven testing increases your test coverage by loading external data into your tests

Data driven testing increases your test coverage by loading external data into your tests

In testing automation, there are often cases where you might have multiple data sets for which you want to run the same tests to strengthen and extend your automated test cases.

Test data can be anything you can think of, such as user credentials, input/output data, uploaded files, expectations, validations, etc. The test data shouldn’t be hard-coded into the test framework in case of automated testing. It can be imported from external files or data sources and fed into our automated test cases.

How data driven testing works

A data driven test performs the following operations for every scenario from the data source:

  • Loads all the variables for the current scenario
  • Replaces the content of the variables in your tests (actions, expectations, validations, etc.)
  • Verifies the actual results with the expected results for the current scenario
  • Repeats the test with the next scenario

And the best part: with Trudon all data set scenarios can be executed in parallel!

Benefits of using data driven testing

  • Any test can be written once and re-executed hundreds or thousands of times, with different inputs and validations each time
  • Test data and verification data can be organized in just one file, and it is separate from the test case logic
  • Redundancy and unnecessary duplication of test scripts are reduced
  • Provides flexibility in application and tests maintenance

Trudon offers a unique way to manage the data sets, feed them to the test runs and see the test results for all scenarios, with screenshots for every test step included.

Popular use cases for data driven testing

  • For SaaS applications: execute your tests with multiple user roles to ensure all the features work for all user types: super admins, company-admins, regular users, …
  • For E-commerce: Check that it is possible to add to cart products from all categories and the checkout process successfully works
  • For generic websites: You might want to upload different files with different formats in order to ensure that it always works

Basically, any test flow you can think of can be converted to a data driven test by replacing all the values with variables and linking a data set source when running the tests.

Data driven testing with Trudon

With Trudon you can work with data-driven testing using various input sources (called data sets) for step actions and validations. Just change your tests’ hard-coded values with variables and link a data source to your test run.

By separating data from functionality when automating software tests, you can reuse the automated flow and switch out the input. It can be useful when running the same tests, often with new or updated data.

Using our highly scalable infrastructure for running tests, all test scenarios from a data set can be executed in parallel.

Conclusion

Data driven testing helps automated tests run rapidly over an application with different input data and provides extensive coverage to ensure an application’s performance. Data Driven testing also enhances business intelligence by reducing risks, increasing the ease of accessing and sharing information with real-time analysis.

Although it requires significant expertise in a scripting language, especially if using with Selenium, Trudon offers o totally different approach that allows anyone to create, configure, and run data driven tests. Schedule a demo to learn more.

Visual testing – compare screenshots from automated tests

Visual testing – compare screenshots from automated tests

Visual testing is becoming more and more important everyday. Each and every time you release a new version of your application, you might push some bugs that go along with it. And it’s not like people have time to browse through logs and code lines to see what happened wrong.

Starting from today, Trudon fully supports screenshot comparison between the latest run and the last passed test.

As always, we get mad excited about Trudon’s new features and we can’t wait to talk about them. And what we love most is TIME. Whenever we develop features that save you a lot of time, we feel like shouting from the rooftops.

So, how will visual testing by screenshot comparison help you save time and reduce risks? Read on.

Why we absolutely ♥ visual testing

Trudon is at the spearhead of innovative, codeless testing. It’s not the 80s or 90s anymore, so applications have an excruciating amount of code inside them, and automated tests are just the same. One of the reasons people choose not to automate testing is because they get entangled with huge amounts of code, and, on top of that, they need a specialised team just to design, manage and analyse the results of those tests.

This is why, in 2020, we see a lot of testing tools making things simpler. Tools like Applitools, Katalon and Trudon are moving past code-based automation and giving regular people the power to write, understand and analyse tests. And, to make things easier, the presentation of these results is visual, not technical.

How we do it

Visual testing is simple, because the presentation is simple. Do you care about or understand what happened at line 259 of test_case_46_datepickers? You probably don’t. And we don’t blame you. But what if we showed you this:

visual-testing-screenshot-comparison-trudon

It’s starting to make sense, right? So in the example, we are applying a Trudon test on the MaterialUI documentation. The last passed test shows the widget autocompleting with 4/15/2020, while the new version shows 5/13/2020. Visual testing makes it simple for you to notice the problem, understand it and relay it to the development team.

Apples and oranges – what should we compare for visual testing?

That’s a tricky one. As you remember, Trudon can run your tests on multiple platforms, devices and browsers, at multiple resolutions. For visual testing to be actually relevant, we compare screenshots from the same step and the same resolution/device. The example shows a comparison between an iPhoneX and an iPhoneX at the exact same point in the test flow.

Code-based tools have no way of giving you this clarity and flexibility, because the flow is entirely different. A failure at line 259 today can be at line 316 tomorrow, even if they test the same thing. 🍎vs. 🍊, which is not the point…

Another thing to keep in mind is that Trudon tests are not just simulations. With Trudon, you can see your application through your customer’s eyes. The same successes and failures for the same actions and intents. Visual testing is a must have in this case.

Coming up next

If you’re here from our Roadmap page, you know our work won’t stop with visual testing and screenshot comparison. In May 2020, get ready for multi-location testing and monitoring. We’ll brag about that too, when it’s done.

Until then, we invite you to enjoy our new screenshot comparison feature and save precious time while testing. And, if you are not yet using Trudon, what are you waiting for? Book a personalised demo today.