Automated regression testing ascertains code changes and functionality issues
Automated Regression Testing ascertains code changes and functionality issues. In other words, it is a quality measurement check to discover if new code complies with the old code so that the remaining unmodified code stays unaffected. Automation regression testing also allows for finding any bugs that may have occurred due to changes in the code and if the testing is not done, the product could have a critical issue occur during a live event which can lead to negative marketing impact.
There are various types of automated regression tests and they include:
- Unit Regression – done during the unit testing phase when a code is tested in isolation.
- Partial Regression – done to verify the code works fine even when the code is changed performed while the unit is integrated with the unchanged or already existing code.
- Complete Regression – done when a change in code is in numerous modules and/or if the change impact in any module is uncertain.
It is understood that automated regression testing is hard because for every action performed there is a reaction. A few result in successful tests but there may be another two-hundred that will lead to failure. Unfortunately, there is no one size fits all test strategy for automated regression and shortcuts that are used, have not had consistent positive results. The good news is there are some comprehensive specs, rules and examples that countless software engineers have diligently put together for our knowledge base and application protocol. (Baril, Gounares, & Krajec, 2014)
The Reason We Have Automated Regression Testing
Automated regression testing’s intent is to speed things up, so we can increase quality and velocity simultaneously which results in obtaining the prize of all promotional tools – being the first to market. It doesn’t matter if you are releasing a new software suite, software feature or even if you wish to make sure a particular software feature is current and working properly, there are steps to take, rules to follow and regression automation tests to conduct. Common practice is to utilize a suite of four regression automation tests which perform in an exemplary manner. They are:
- Retest all and repeat frequently – the entire test case in the suite are re-executed to ensure there are no bugs from a change in the code. This regression test is expensive due to its expansive nature and requires more time and resources than any of the other types of automated regression testing methods.
- Selection testing is worth using for maintenance – test cases are selected from suites to be re-executed. The test cases are selected from code changes in the modules and have two categories – reusable and obsolete. The reusable test cases can be used in future regression cycles whereas the obsolete ones are not use in future regression cycles.
- Prioritization to create stability – priorities are created, and the test cases depend on the listed and needed priorities to be for product impact and functionality.
- Simple – a combination of regression test selection and test case prioritization. Rather than selecting the entire test suite, only test cases which are re-executed and are listed as a priority are designated.
It should be noted automated regression testing not only enables checks into various changes but can also release and prompt testers to conduct manual assessments in the more uncommon cases respective to their unique production environment.
Stakeholders are usually willing to accept automation regression testing as being a part of the final analysis of ‘completion’ for user stories being worked on and evaluated. User stories are only closed when the corresponding automated tests were run effectively and efficiently and had successful outcomes. When the feature is successfully released into production, the regression suite becomes part of the tests. In layman’s terms that means there is a stable version of tests which now exist as part of the regression suite-built layer by layer and are available whenever development of a new feature is added. (Briand, Labiche, & Soccar, 2002)
However, there is a more difficult automated regression test to perform which occurs when a feature was released into production without having any automated tests performed. The challenge then becomes finding a regression suite to put into place since you can only do that incrementally, layer by layer so prioritization is mandatory to ascertain what must be tested.
Automated Regression Testing Tools and Time Savers
There are various tools that can be used in automated regression testing which combine testing with functionality in a single platform and a couple of popular ones include Selenium and vTest. However, there is a sidebar that needs to be considered and understood when using automated regression testing tools. The implementation of the tests are faster than manual tests but be cognizant that everything else will take significant time, so preparation is the key. What does that mean? It means that writing the tests and setting up the suite needs must be prioritized, listed and understood. To help save some inefficient use of your time, we have listed some automated regression testing time savers. (Raulamo-Jurvanen, 2017)
- Try to write individual and independent tests because you will ultimately regret it if you don’t. By not writing individual and independents tests, if an issue arises, you will find because you did not write an independent test, your solutions are problematic and must work around test orders and the storing of state and data between test runs.
- Separate acceptance and end-to-end tests because they do entirely two different things and need to run separately to get proportions correct. Acceptance tests target and test one thing efficiently and effectively. An end to end test is implemented to cover the user’s journey through an app and then test the app the same way a user access it. The end to end tests do take more time and are considered fragile because they contain so many incremental steps.
- If you want your test to perform brilliantly, decipher why you are doing automated testing and once you ascertain need, determine what measurements will be needed. Your end goal should be to have as few automated tests as possible and only use them for valid and objective business reasons because automated tests are time-intensive and costly.
- Never forget that intention and implementation are two different things. When writing scenarios, it is logical to input how best to implement the set-up, but that thinking is faulty and will not help longevity within your specifications or enhance business readability. Intentional features and scenarios provide outcomes that are clear and easy to understand and if you really want to provide exemplary solutions you can even build in the ability to change your test, if needed without changing your specifications.
- Automated regression testing is not a one shot and you’re done deal because if you don’t run them on a consistent basis, they will become almost useless when someone changes code. The test should be in the same source control repository as the app, so they will not be forgotten about or ignored.
- Automated tests should never be run on several browsers because almost every browser performs differently with slight variations which invalidates true results. In essence you are probably wasting your time. Try to find the browser most of your customers will be using. Google Chrome is usually a good place to start.
- There are nuanced differences in manual and automated testing. This sounds like a no-brainer but it’s not. Automated testing is the testing of choice for functionality, but it does not do well in testing stories or exploring your system. Automated, artificial regression testing no matter how brilliant, logical or error-free, rarely understands weird quirks or cultural definition variances. But humans can find those unique perspectives and manually test them which is more cost efficient and allows for fine-tuning for human users’ needs.
- Try to run your automated tests as they incrementally grow and develop to speed up your run times. It takes almost no time to create an agent to run tests and collate the results on a consistent loop integrated with the testing server.
- Use, use and use your application development team because each member should be accountable for quality. The most effective and efficient automated tests are developed with the application development team because they integrate what is needed with what can be tested with the results being successfully magnified.
- Try to find any opportunity to extract the most value for the least amount of time and energy. If you have to keep running automated end to end testing after deployment of product, is it a good use of a company’s outlay? Always seek value in every level of testing. Always.
Automation regression testing is one of the most important aspects in helping deliver a quality product because it makes sure that any change in the code whether it’s small or large does not affect the existing or old functionality. You can even use automaton to create master data and setup configurations for manual testers which ultimately allows you to facilitate the needs of the various operations within your company or organization. There will be new tests in automation with techniques discovered and challenges to solve. The journey to achieving optimum levels of automation in regression testing must start by taking the first step.
Discover more on Regression Testing
Bibliography
Baril, B. B., Gounares, A. G., & Krajec, R. S. (2014). Automated Regression Testing for Software Applications. Retrieved 10 12, 2018, from http://freepatentsonline.com/9355016.html
Briand, L. C., Labiche, Y., & Soccar, G. (2002). Automating impact analysis and regression test selection based on UML designs. Retrieved 10 14, 2018, from http://ieeexplore.ieee.org/document/1167775
Raulamo-Jurvanen, P. (2017). Decision Support for Selecting Tools for Software Test Automation. ACM Sigsoft Software Engineering Notes, 41(6), 1-5. Retrieved 10 12, 2018, from http://dblp.uni-trier.de/db/journals/sigsoft/sigsoft41.html
Tan, S. H., & Roychoudhury, A. (2015). relifix : automated repair of software regressions. Retrieved 10 16, 2018, from http://dblp.uni-trier.de/db/conf/icse/icse2015-1.html
LIKE THIS POST SHARE IT WITH YOUR FRIENDS
Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on email
RECENT POSTS
Guides
- Published in Article
9-step success formula for small QA teams to switch from manual to automated testing in 2019
Do you or your team currently test manually and trying to break into test automation? In this article, we outline how can small QA teams make transition from manual to codeless testing to full fledged automated testing. The transition will not happen overnight but can be successfully achieved much easier than anticipated.
1 – Say no to mundane repetitive manual testing
Your willingness to say no to mundane and boring repetitive manual testing is the first real step towards automated testing! As a team you need to acknowledge that manual testing is haunted by repetitiveness and is error prone. Any team will eventually get bogged down by doing the same thing over and over again impacting team motivation. Some teams will overcome this challenge by automating small bits and pieces of repetitive work. For example, a script to import test data into a database, a utility to generate random test data, etc.
2 – Know impediments to switch to automated testing
Once you acknowledge as a team that you need to move to automated testing, the next step is to know what is stopping your team from making this move. In most cases, it is the fear of complexities involved in automation ie., learning programming. “Can we learn a new programming language and implement a successful test automation project?” are the kind of questions that come to mind. To allay such fears, teams should start small and pick the right tools that suit their testing needs. For example, think before picking a tool that does not work well with iFrames if your application is using iFrames heavily, or start to build out a test automation framework if your team doesn’t have any automation experience, etc.
3 – Start simple and small but make it successful
A good beginning is half the job done. It is very important to pick the simple and small test cases when your team is new to automated testing. Pick the test cases that you manually test very often but are easy to test. Simple and small test cases are easy to automate, debug, maintain and reuse. Don’t go crazy with automation and start with most time taking or complex ones first or you will make your beginning harder and reduce your chances of success. For example, start with a simple login test case, creating a user, etc.
4 – Pick the right tools and frameworks
Making the process easier for your team to adopt is the key to success. It will be easier when you choose combination of tools and frameworks. Yes, you heard it right! It has to be combination of tools. You can no longer rely on one single tool to get success on your test automation. Selenium execution will probably be the foundation as it is the most popular and convenient tool to use with different programming languages. Start with codeless testing tools built on top of Selenium. Codeless testing tools could cover most of your simple to medium complex manual tests.
Discover why is codeless test automation better than conventional test automation?
5 – Learn and practice programming
Pick up the programming language that your team is most comfortable with. Codeless testing might be able to cover most of your manual testing but for complex steps or tests, you would need to write scripts. Learning is not enough, you should put your learning to practice to understand and write good code. But do not go deep where you cannot stand. Remember as a team, your goal is to ensure quality of the software by automating repetitive manual tests.
6 – Be very clear on what to automate
Your team has to prioritize which tests to automate. Just because you have this new-found knowledge of automated testing, does not mean it should be applied to everything — in fact, it is impossible to automate all tests, and many things are better off being done manually. Trying to automate complex and less often used tests is a formula for failure and is not worth your team’s effort. Here is where your manual and exploratory testing skills should be put to use whenever a new feature is released. Run risk analysis to determine parts of your application that should be automated. In addition you will have to pay attention to details like if your application is web based, you will want to create a list of the browsers and devices that are going to be essential to your particular test suite.
7 – Zero tolerance to unreliable automated tests
Just like, as manual testers, you refuse to be content with failing tests, you should not tolerate automated tests that pass at times and fail at other times. Unreliable tests will lose your team’s confidence and is a stepping stone for failure. As an example, if there is a failure in the initial steps of a lengthy test case, you can not be sure if there’s no bug beyond that step. Such uncertainties will be bad for team morale and make the whole automation effort less fruitful.
8 – Do not neglect team collaboration
Successful outcomes for any project are guaranteed by a collaborative team. It is no different for test automation. All your team’s automated tests have to be in a single repository accessible anytime & anywhere. A change log indicating who made change to which test case for traceability and accountability should always exist. The tool you pick should allow for collaboration and also make it easier to categorize, tag, sort and filter the 100’s of tests that you would have created over time.
9 – Get the fundamentals right
Do not forget the testing fundamentals. Whether it is manual or automated testing, testing concepts and fundamentals always apply. Refer these articles to understand the fundamentals of test automation
Automated testing might seem daunting when you start, but all it really takes is a consistent effort to make it a success. Continuous learning and practice using your resources will help. Take comfort in knowing that even the experts don’t know it all. No matter how good an automation engineer you become, there’s always more to learn.
LIKE THIS POST SHARE IT WITH YOUR FRIENDS
Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on email
RECENT POSTS
Guides
- Published in Article
Microservices - The New Kid On The Block
Micro Services – The new kid on the block
As the Agile form of software development is making waves and ruling the roost in the software game, a new player is slowly emerging – microservices. It is similar to the many small iterations that characterize the Agile development module. So what exactly is microservices?
To understand this, let us first take into account the two basic styles of software development. First, we have a monolithic design, which is a single application entirely contained in a single process.
This sort of application has several groups of classes that are interdependent. Thus, if changes are made to one class, it affects all the other classes.
Next, we have the microservices architecture. Here, the application has micro-services that come together to make up the whole or combine their processes to execute a task.
Every single microservice has its own specialized, customized responsibility within the application’s structure. They are not dependent on each other, and thus, can be deployed and tested individually instead of having to rewrite the entire application.
Applications in Testing
Microservices have various applications in the automated testing field. Let us first examine testing in isolation. Since microservices are isolated from the application, the entire application need not be changed when you change a microservice, and therefore you can test a microservice in isolation. This is an easy place to start your automated testing journey as it will not affect your entire product, only a part of it.
This does not mean that you don’t have to test your entire application after testing the microservice in isolation. You still have to do that to ensure the microservice has integrated as well as its predecessor, but this is very easy and doable to start to the automated testing journey that will save you a lot of time in the development field.
In an application that is based on microservices, end-to-end testing becomes complicated. For your end-to-end testing needs, a good idea is to follow the Pareto Principle that states that 80% of the consequences stem from 20% of the causes. Thus, the approach you should take is to identify your core services that are absolutely essential and automate them, as you need the least margin of error in testing there.
Pro-tip: Do your testing in production
If you want to keep the quality of your output high, you need to test while in production to end up with the best possible version of your product. Microservices development module is fluid, as every piece does its own work, and behaves in isolation. Thus, unless you test during production, you will not have a clear idea of how the services are interacting with each other, nor will you be able to test this interaction.
Another important aspect that you will need to incorporate into your development module is an excellent monitoring and alerts infrastructure. This is because you need to quickly get on top of any issues that might crop up. Since every single service needs to work in order for your product to achieve an end result, you need to be able to identify, isolate and fix any problem that comes up with lightning speed.
This is cut down if you have a good testing in production framework that includes monitoring and alerts as well. Finally, if your monitoring and production testing is spot on, then not only will you be able to respond to the issue quickly, but you might be able to devolve to a more stable build even before your users know that a problem has occurred.
If you want to learn more about being more productive with Test Automation, contact us at CloudQA (info@cloudqa.io)
LIKE THIS POST SHARE IT WITH YOUR FRIENDS
Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on email
RECENT POSTS
Guides
- Published in Article
The Secret of Agile Development
Agile Development
CloudQA is back with our What You Should Be Doing series! In this installment, we look at Agile development. First off the bat – what is Agile? Well, to quote AgileNutShell, “Agile is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end.” Cprime further elaborates it as “a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.” The system is based on the Agile Manifesto, which you can look through in various languages here.
The benefits of the Agile development module has been proven time and again. If there is one thing that you should take away from this article, it is that the Agile development module is impossible to do without automated testing. It will be absolutely impossible to meet the high turnover rates in this module without having automated tests and the time management benefits they provide, especially with regard to regression testing.
If you’re already on track with Agile, this article will focus on what you need to do in order to succeed with Agile, by showing you what you should be doing. Without further ado, here are the best practices of Agile software development:
- Follow the fixed-length iterations to a TOne of the most difficult parts about Agile is that it keeps you on your toes. Each agile release is made up of several different iterations, with each iteration being a standalone project by itself. The entire Agile process is extremely dependent on these iterations as they help to streamline the development process and keep the whole team focused towards a set result. The deadlines help move things along at a very rapid pace. It also helps keep goals actionable instead of vague, and keeps everyone’s work measurable. The targets are short term, and easily evaluable. Once the team gets used to working these deadlines, they will fall into a stride, a pace of working that will keep churning things out at a rapid pace. Time, effort and resources will be managed more efficiently.
- Deliver working software One of the main tenets of agile software development is how fast it delivers, and how reliable its results are. Thus, when planning iterations, keep working features as a priority. All improvements, feedback and other factors can be incorporated into the iteration process on a priority basis. This keeps your team on track, and everything organized. You can do your work systematically, and on a priority basis. You don’t need to wait around for reworkings, and you don’t waste time assessing what work you have done, and what you have left. Additionally, you deliver to consumers or clients faster, with greater product reliability.
- Development should be backed by valueAnother one of the main tenets of agile development is the value that it delivers, and how steadily it delivers that. Features and the usability of those features are what the agile development module focuses on, and thus you will always be left with a usable product at the end of the week. Your team needs to be visionary to really fulfill this claim. Don’t be afraid to try new things or take big risks. As you will find out in the next point, failures will not throw off your entire development plan.
- An evolving, adapting product plan as we’ve mentioned before, the agile development module works on feedback and re-workings of any aspect of a project on a priority basis. This means that your plan will have to be built with space for these intact. This also means that your planning needs to be kept dynamic, and it is this dynamic that keeps everything moving at a rapid pace. Dynamic plans deliver better end products because they have a better understanding of what the consumer or client ultimately wants. These plans are constantly open to upgrades and changes, and this helps the team because they don’t have to start from scratch if the end result does not satisfy after completion.
- Your project grows along with youThis is an extremely crucial part of the agile development process, and is an intrinsic part of it as well. In agile development, you get constant feedback at the end of every iteration. This means that your product plan keeps changing as well. There is no set goal to work toward mindlessly, as the feedback you get will make you rethink your goals each time. Your feature list might grow, and be easier to incorporate at early stages than at a later stage. It is a much more interesting environment to work with for programmers and is a more efficient way to deliver products that a customer or client is satisfied with.
- Thatched teamwork The agile development process calls for standalone teams that are assigned to different work, but who ultimately work together to build the final product. This cross-functional or thatched teamwork has several benefits. First, it doesn’t put the entire responsibility of the project in one place. Less stress equals to higher productivity. Additionally, smaller groups are easier to supervise, and work better than larger groups. Everyone on the team knows exactly what they’re doing, what they’re responsible for, and what their contribution is. Keep your agile development teams small, but in constant communication. The benefits of thatched teamwork comes out brilliantly when you have a highly creative, multi-disciplinary team. Everyone brings their own expertise to the table and you get a very well-rounded end product as a result.
- The Devil Is In The DetailsHere is a handy checklist about actionable points
- Make sure unit tests and component tests are done rigorously.
- Make sure that GUI smoke tests are done with every sprint or test cycle.
- Make sure that you respect the tests and the feedback that you get from the testers.
Make sure you add the feedback to the add-on needs for the next cycle.
These small details will ensure that your Agile testing is done efficiently and that your testing plan succeeds. You need to keep your approach to Agile testing on point, and not deviate from the plan that you lay out in the beginning. Together, these will ensure that you succeed with Agile testing.
If you want to learn more about being more productive with Test Automation, contact us at CloudQA (info@cloudqa.io)
LIKE THIS POST SHARE IT WITH YOUR FRIENDS
Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on email
RECENT POSTS
Guides
- Published in Article
Bigger, Better And Faster - Your Favorite Testing Software Just Leveled Up!
Selenium Test Automation
Bigger, Better And Faster – Your Favorite Testing Software Just Leveled Up!
CloudQA is committed to offering its clients the most advanced and the most efficient technologies. We spend a lot of time and effort in R&D, and try to bring the most stable and effective strategies to the market. We know the value of your time and money, and don’t skimp about features and capabilities. Keeping that in mind, we’ve been working our butts off to bring you even better features in your favorite testing software.
Now, using CloudQA, you can customize your execution by recording steps updates! We’ve given you a lot of control over this, and you can now define the speed of execution steps on the basis o your application being tested, and set element wait time at the application level in your app preferences. Besides that, you can now begin your testing before the UI is developed, saving everyone a lot of time, and hastening your software development process.
You can test “get”, “post”, and “delete” HTTP requests easily, as per your requirements. You can also save the API test case, and even reuse them when you need it next. You can also add assertions to confirm the response of the API, and view the response in both raw and JSON formats. Additionally, you can add parameters and headers based on the API you are currently using.
Finally, CloudQA has made monitoring your web application so much easier, it’s child’s play! You can check your URL every 5 minutes (free of cost, we might add) and upload all your URLs in a .csv file. You can test your website’s performance, and view up and down times of your website in both heat map and graph formats. Finally, we’ve also made sharing reports with your team members much easier with shareable links that improve team communication efficiency!
Phew! That’s been a lot of work. But, as they say, no rest for the wicked! We earnestly hope you like all these new updates we’ve rolled out for you. Get in touch if you have any queries about these or any other features of the site, and we’d be more than happy to help (In fact, get in touch with us anyway, we love feedback and communication!). In the meantime, we’ll be over here working on getting you even more awesome new features and updates that will help you get your work done faster, more easily, and more efficiently!
For now – that’s all, folks!
If you want to learn more about being more productive with Test Automation, contact us at CloudQA (info@cloudqa.io)
RECENT POSTS
Guides
- Published in Article
Automated Functional Testing - Why you should seriously consider it
What is Functional Testing?
A properly written functional test ensures that the system is functioning exactly as the USER expects it to. Functional tests target business goals and typically defined and validated by an expert end user. Since it may not be possible for an expert to test the functionality of the system at each and every step of development, the test cases/scenarios are often documented with their help. This document defines the step by step instructions of system interactions along with the expected outcomes for every test case defined by the expert users. It can then help any user (not just the Expert) to be able to follow the steps to test the software and verify if the outcome is exactly as the expert has defined. To ensure completeness, functional tests should cover both the positive and negative scenarios.
Challenges:
Manual functional testing can be a tedious process as it can take quite a while for a tester to step through each of the steps and verify the outcome/results. When the user goes through these steps each time there is a software update, there is a high probability of erroneous information being entered or captured by the tester resulting in incorrect validations. If the number of test cases is extremely large and complex this problem gets magnified. The manual testing process can, therefore, be extremely laborious, monotonous and error-prone and requires highly dedicated and qualified resources to execute.
This can be overcome by automating the functional tests as much as possible. Granted that not every test can be automated, but even a 50% coverage via test automation can bring about huge relief in time, cost and resources. Once a test scenario is “automated”, it can be run on demand after each software release cycle. The feedback from an automated test is extremely fast compared to the same test run manually.
Consider an example where a test scenario requires a user to traverse through multiple screens, enter data into 20+ fields, select various check boxes, radio buttons, pick a value from a drop-down options, enter date in the right format, validate the response on 5 submit buttons, etc.. A real-life scenario like this can easily take the user over 5-10 minutes each time to run this test. For the same scenario, if the test requires a different data set or a negative test, it means another 5-10 minutes. When you look at multiple data sets and 100’s of test scenarios, it translates to weeks of testing that is required after each major software release. This also causes a bottleneck for the development team to move any further before getting a complete feedback from the test users. If all these test scenarios could be automated, it would take only a couple of hours to go through the tests and feedback cycle to the developers would be extremely fast compared to manually testing all the scenarios. That is a huge saving in terms of time. effort and resources and easily justify adopting functional test automation as much as possible.
A lot of companies, as a standard practice, do not thoroughly test their software application after each minor or major release because of the aforementioned manual testing challenges. The risk that they undertake, however, is extremely high if the software fails in a real-world environment – brand reputation, lost clients, fixes that take too long and that potentially break other parts of the software.
Automation Frameworks
One way to speed up functional testing is through web automation tools. Selenium is one of the few software testing automation frameworks for web applications out there which is open source and has a very large following. It has a set of tools to support test automation in multiple browsers. Web test automation with Selenium, however, is a programming activity and people creating tests should be comfortable with one or more of the few programming languages that Selenium supports (Java, C#, Python, etc.). Even though it might take some time (a few hours or days depending on the complexity of the test case), it can greatly reduce manual repetitive/regression testing efforts after each software release cycle.
There are a few companies that are working towards reducing the time to automate the tests with Selenium by providing a “wrapper” solution which essentially means “automating the Selenium test automation” efforts. However, since there are many types of browser interactions in modern web technologies, not everything can be addressed easily. The goal of a tester should always be to evaluate and use tools & methods that can address the maximum number of test cases with minimum effort.
Automation with CloudQA
There are quite a few testing tools that can assist in automating the functional tests but the challenge faced by most tools is the automation coverage (especially in large software applications). CloudQA has been designed to cover a lot of complex test scenarios. The goal of CloudQA is to cover automation of as many functional test cases as possible. It starts with a unique ability of CloudQA to discover as many test cases as possible of the software application via an auto-learning process. This, in itself, can save test managers weeks (if not months) of discovering scenarios that can be possibly tested. Besides that, some of the complex scenarios that CloudQA handles right out of the box includes
* Table data access
* Auto Suggest boxes
* Variable storage of a dynamic data set
* File Upload tests
* Data-driven testing (for multiple data sets)
* Various types of user assertions (check, check not, etc.)
* Various actions – click, alert, screen snapshot, wait
If you are thinking about automating your functional tests, talk to one of the CloudQA specialists (email: info@cloudqa.io)
LIKE THIS POST SHARE IT WITH YOUR FRIENDS
Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on email
RECENT POSTS
Guides
- Published in Article
