Case Study
Bright-Interactive Case Study
About Bright-Interactive:
Bright-Interactive is award-winning, feature-rich, intelligent digital asset management software that makes managing brand media seamless, whatever the size of the organization.
Customer’s digital files are centrally stored and are secure, searchable and easily accessible by anyone you choose – fast.
Challenges faced:
As any company Bright-Interactive ensuring the quality of the production application remained high, i.e. as free from defects as possible. They primarily wanted to eliminate laborious manual testing of the application in staging before pushing code changes to production as manual testing was time-consuming Customers were noticing defects on production. While the team supported a variety of different test automation functions, they never had enough time to invest in automating the User Interface level testing. The team considered Selenium and experimented with it.
The Solution:
Bright-Interactive believes that everyone on the team should be able to write tests and own code quality. Bright-Interactive’s R&D team members analyzed different tools in the market and picked up CloudQA quickly, using it for frontend test automation coverage.
Bright-Interactive was able to create a UI regression suite that gave the team confidence knowing when developers have ‘broken’ existing functionality so they could fix it as soon as possible while allowing them to add, expand, and grow without investing a ton of resources into their UI test automation. The regression test suite is extremely valuable for the app development team as it serves as a safety net they can rely on when they make changes that break things.
Bright-Interactive is now working to leverage CloudQA to not only help with code-coverage but run various test cases in production, thus giving us an app-level production monitoring to mitigate production malfunctions, above & beyond code regressions.
The Results:
Bright-interactive’s team ran for quite some time by doing UI level testing manually. To keep up with customer demands meanwhile, without slowing down their daily releases.
Earlier Bright Interactive would occasionally have a regression at the UI level that forced the team to stop working and go back and fix the issues. Now the team can find the problems quickly and react to them faster, giving them more coverage without slowing down the development pace.
Now with CloudQA they can create tests at a faster pace and can be created by developers and non-developers. Now the quality of the product is maintained, increased in deployment velocity and greater customer satisfaction.
Real Insights. Better Performance
Get Started Now. No Credit Card Required.
- Published in case study
Regression Testing: Tools and Techniques
Regression Testing, by its definition, is a type of software testing to confirm that a recent program or code change has not adversely affected existing features.
It is done to make sure that the existing application is intact with the newly added features and nothing is broken. In order to achieve that, the existing test cases are executed selectively or sometimes completely. Regression testing ensures that the old code still works once the new code changes are done.
Why is it required?
Regression testing is carried out in many cases-
- Changes in the requirement of an existing feature.
- Addition of new feature
- Bug fixes
- Technology change/upgrade
- Performance Fixes
- Code optimization
Regression testing ensures that the changes have not introduced new bugs in the existing features which were working fine before. Sometimes there is a change in requirements of the existing feature itself which may impact other features of the application. In this case, regression testing is carried out for other features.
Regression testing is also required in cases where the underlying technology is changed or upgraded due to old libraries are deprecated. To ensure that this does not have any impact on functionality, testers perform complete regression testing.
When a developer does code optimization or performance fixes then also testers perform regression testing.
Re-testing and Regression Testing- There is a difference between re-testing and regression testing. Retesting is to test the software/ application when a defect is fixed to ensure that the original defect is completely removed while regression testing is performed to make sure that no new defects are introduced when a new feature is developed or existing feature is changed.
Regression Testing Techniques- Usually testers include regression testing in their test plan for each release. As defined, it should be performed to ensure that new features do not have any impact on existing features, it must be included in each release plan. As most of the organizations follow agile methodology where releases are frequent, regression testing is achieved by continuous testing and automation. There are various techniques of regression testing-
- Retest All- This is the technique where test engineers execute all the existing test cases without any miss. This is quite expensive as it requires huge time and resources.
- Regression Test Selection- In this technique, test engineers select a subset of test cases based on the impact analysis. Test chosen cases categorized as
- Reusable Test cases
- Obsolete Test cases
Reusable Test cases used in succeeding Regression cycles. Obsolete Test cases not used in succeeding cycles.
- Prioritization of Test cases- To prioritize test cases depending on a business impact, critical and frequency used functionalists. Selection of test cases based on priority will significantly reduce the regression test suite.
Quickly convert your end-to-end web testing process to run over 80% faster and accurate now.
Types of Regression Testing-
- Selective – Selective regression testing is a type of regression testing where testers select test cases from previously run test suites and test coverage identification. To perform this, test engineers use a sub-set of already run test cases to reduce the cost and effort required in re-testing.
- Complete – Complete regression testing is used when there are changes in the root code of the software. It is also performed when there are multiple changes that have been done to the existing code.
- Corrective – It is performed when there are no changes in the existing software/application. The already existing test cases can be re-used to perform this type of regression testing.
- Partial – This type of regression testing is performed after impact analysis. Test engineers do selective test case execution based on the modules which get impacted due to new code merge.
Can regression testing be done Manually?
Regression testing can be performed manually. But this leads to inefficiency if the application is large and impact is big. Also, it is very boring to execute repetitive test cases again and again for a test engineer.
To perform regression testing, the tester needs to identify the test cases which must be executed.If the no. is big, testers need to find out the best combination and optimize them.
Regression testing Tools- Regression test cases can be automated and executed on a scheduled basis. There are many tools that are reliable and scalable. Let’s have a look some of the most popular tools-
- Winrunner – HP WinRunner software was an automated functional GUI testing tool that allowed a user to record and playback user interface (UI) interactions as test scripts. As a functional test suite, it worked with HP QuickTest Professional and supported enterprise quality assurance.
- QTP – QTP is an automation testing tool by HP which is now called as HPE Unified Functional Testing software. It supports VB scripting language to specify the test procedure and also provides a GUI. To perform more intensive actions the user may need to modify the underlying script.
- Watir – According to Watir website, Watir stands for Web Application Testing In Ruby. It facilitates the writing of automated tests by mimicking the behavior of a user interacting with a website. It supports multiple browsers like Internet Explorer, Chrome, Firefox, Opera and Safari.
Its latest version is watir webdriver which is based on selenium API. - Selenium – Selenium is a set of tools used to automate web applications across platforms. It supports many third party libraries to facilitate a complete framework for automation. It also supports multiple programming languages. Selenium has the support of some of the largest browser vendors who have taken (or are taking) steps to make Selenium a native part of their browser. It is also the core technology in countless other browser automation tools, APIs and frameworks.
- actiWate – actiWATE is a Java-based software platform intended to make the test automation process simple and cost-effective for automation of regression testing of web applications. It consists of actiWATE Framework and additional modules. Currently, only one module is released – actiWATE TWA Framework which is a Java-based library. Automated tests use this library for interacting with web applications. actiWATE executes tests without real Internet browser; instead actiWATE Framework emulates Internet browser on its own. actiWATE tests are fully compatible with JUnit and can be run by any JUnit tests runner.
- Rational Functional Tester – Rational Functional Tester is a tool for automated testing of software applications from the Rational Software division of IBM. It allows users to create tests that mimic the actions and assessments of a human tester. It is primarily used by Software Quality Assurance teams to perform automated regression testing.
- SilkTest –Silk Test is a tool for automated function and regression testing of enterprise applications. It was originally developed by Segue Software which was acquired by Borland in 2006. Borland was acquired by Micro Focus International in 2009.
- TimeShiftX –TimeShiftX is a date and time shift testing software that lets you time travel software into the future or past for temporal testing all date and time-sensitive functionality and code such as end of year-month, daylight savings time, leap year, billing, rates, policies, etc. Perform time travel testing without changing system clocks, editing code, or isolating servers.
- CloudQA- CloudQA provides a unified platform for various testing requirements. They have a record and playback tool with integrated reporting which is quite easy to use for creating and scheduling regression testing suit. It also provides integration with various third-party tools for eg-
- ALM tools (TestRail, TFS, Asana)
- Bug Tracking (Jira, BugTracker)
- CI/CD (Jenkins, CircleCI, TravisCI & DevOps support)
- Open API Integration
- Team communication (Slack, SMS, webhooks)
- Version control tools (Github, TFS)
Regression testing automation FAQ
What is regression testing automation?
Regression testing automation is a software testing technique that utilizes software tools and techniques in testing software after application to be tested has been changed or updated.
What are the advantages of regression testing automation?
Regression testing automation increases our chances of detecting bugs caused by changes to software and application- either enhancements or defect fixes. Regression testing automation also detects undesirable side effects caused always by changing the operating environment like data, operating system, browsers, resolutions, etc.
What are some of the prominent regression testing automation tools?
Here is the list of most popular regression testing automation tools in 2019
1. CloudQA.
2. IBM Rational Functional Tester.
3. Microfocus UFT.
4. Ranorex Studio.
5. SahiPro.
6. Selenium.
7. TestComplete.
8. Tricentis Tosca.
9. Watir.
Why is regression testing automation required?
Regression testing automation is needed to ensure changes in the application do not disrupt currently functioning parts of the application. Given there are tests (e.g. core features, critical functionality) that need to be repeatedly executed in each regression test run, it is required that these regression test cases are automated.
Why regression testing automation is important in Agile software development methodology?
Agile methodology focuses on building a high-quality product, reducing the risk associated with development. Since agile methodology involves frequent changes, it is important to have a regression test automation process for the same
Is regression testing automation part of DevOps?
“Automation” is frequently used in the context of automating a project’s deployment pipeline. Often this is referred to as “DevOps,” or Developer Operations. Continuous Integration, Continuous Deployment, and Continuous testing are all facets of this overarching domain: leveraging regression testing automation tools to quickly test, retest the application changes to eventually deploy into production.
LIKE THIS POST SHARE IT WITH YOUR FRIENDS
Share on facebook
Share on twitter
Share on linkedin
Share on email
Find out now how you can switch from manual to automated testing in less than a week
- Published in Article
How To Select a Regression Testing Automation Tool For Web Applications
Regression testing is an essential component in a web application development cycle. However, it’s often a time-consuming and tedious task in the QA process.
Thankfully, you can improve efficiency, streamline workflows, reduce costs, and shorten the development cycle by automating regression testing.
How should you go about selecting the right regression testing automation tool? What are some available options in the market? What are the best practices that’d help you get the most out of these platforms?
Criteria For Selecting a Regression Testing Automation Tool
After you have decided that the duration and scope of a project are worth the upfront effort needed to set up automation, look for key features in an automation tool that meet the project requirements.
When evaluating an automation tool, you should consider:
- The ability to develop and maintain scripts quickly and easily.
- Ease of test execution by non-technical users.
- Continuous Integration for TFS DevOps integration with builds and deployments.
- Cross-browser and cross-platform (mobile, desktop, web) testing in multiple environments.
- Keyword- and data-driven testing.
- Reliability, maintainability, and scalability.
- The ability to manage the complete QA lifecycle, from test generation to detailed reporting.
- Technical support, including customer service, knowledge base, and community.
The Most Popular Regression Testing Automation Tool For Web Application
Here are some popular regression testing automation tools, each with its unique features that meet the needs of different projects and budgets:
Selenium WebDriver
This open source testing tool integrates with Cucumber/SpecFlow and allows you to write test cases in a variety of programming languages, including C#, Java, Ruby, and Python. It also offers a lot of training and support resources.
Selenium IDE
Record test cases with this Firefox plugin, which is ideal for testing simple web applications since its functionality is rather limited. For instance, it doesn’t support testing for flash video games, music, UI/UX tests or file uploads.
Ranorex
An all-in-one solution for test automation of desktop, web, and mobile apps. Its codeless click-and-go interface makes it easy for beginners and non-technical users to conduct regression testing while its functionalities are powerful enough for automation experts with a full IDE.
Sahi Pro
This tester-focused automation tool is best suited for testing large web applications. It allows you to conduct testing quickly while minimizing maintenance effort. The smart accessor mechanism is designed to ensure that a test script won’t fail even if there are slight changes in the UI.
TestComplete
This platform enables the execution of parallel regression tests using automated builds without any manual intervention. It supports desktop, web, and mobile apps and can be used for GUI testing.
CloudQA
TruRT’s intuitive interface and the codeless platform is easy to use and offers a variety of features such as integrations, remote test executions, cross-browser testing, data-driven testing, advanced notifications, and comprehensive reporting to increase the productivity of your QA team.
Top 7 Automated Regression Testing Best Practices
After you have identified the right tool for the project, optimize the QA process by following these regression testing automation best practices:
- Plan your QA strategy: Build adequate time into the product lifecycle for testing, decide where QA fits into the process, and consider available resources. E.g., will every user story be tested? What kind of testing strategy will be used?
- Identify the test cases to automate: Test cases that can benefit most from automation are repetitive, needed for multiple builds, hard to perform manually, susceptible to human errors, using multiple data sets, or time-consuming when tested manually.
- Test early and often: Bugs caught early in the development process will have less impact on the project. They are cheaper and faster to fix than those discovered later during production or deployment.
- Integrate development and QA teams: Automation and development teams should be working together seamlessly to reduce churn, minimize miscommunications, and increase the efficiency of the entire development cycle.
- Create quality test data: Use external data to make automated tests reusable and easy to maintain. To add testing scenarios, you’d simply extend the files with new data so you don’t have to edit the actual test script.
- Create tests that are resistant to UI changes: Set up the tests such that they don’t rely on location coordinates to find objects by providing unique names for the controls. This allows you to create stable test scripts that won’t break due to UI changes.
- Coordinate development and QA: Often times, testing can be done most effectively when conducted one sprint behind the development cycle. Without such a lag, the code could be too fluid for effective testing and changes could break the automation.
Conclusion
Regression testing automation is essential for today’s fast-paced software deployment processes. It helps shorten the development cycles and reduce the time to market, allowing you to respond to user demands in a nimble manner.
To maximize the effectiveness of your testing process, it’s important to select a regression testing automation tool that meets your project requirements while allowing you to manage the entire QA lifecycle seamlessly.
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
What Is UI Regression Testing, and How Can You Use it for Your Brand?
There’s a lot of value in stressing the importance of iterative improvement in the software development world. When there are so many things that can be made better, and a host of slight tweaks can result in major performance improvement, it’s vital to keep pushing ahead — and knowing that it doesn’t need to happen in one intimidating leap makes it approachable.
That said, the drawback of iterative improvement isn’t discussed as much as it should be. What am I talking about? Well, think about the game of Jenga. Every time you make a move by removing a block and placing it at the top of the structure, you risk the whole thing collapsing. With iterative improvement, every significant change to your system risks the whole thing.
That’s why regression testing is important. Driven by granular analytics and suitable market research, it allows you to proceed with confidence that you’re paving the way ahead without unintentionally destroying the road behind you (in essence, the core goal is sustainable scaling). But why are updates so risky, what does regression testing (for UI in particular) actually involve, and how can you use it to further your brand? Let’s run through it all.
Why every update is a serious threat
Imagine that you get version 1 of your website up and running, overcoming various bugs in the beta stage. Everything looks fine, and all the functions operate as they should. You decide to move to version 1.1, and your first point of order is to change the navigation — but when you roll out the change, you realize that your actions have had unforeseen consequences.
The navigation change that you developed happened to conflict with a bug fix that you generated much earlier, and now you see the resurgence of an issue that you thought you’d eradicated. You’re left with two options:
- Stick with your new change, come up with a fresh fix for that bug, and thoroughly test everything else to make sure that no other issues have arisen.
- Roll back the change in its entirety, then dig deep into the code while writing a replacement to confirm that it won’t cause any problems.
Either way, you’re required to do a lot of testing — and as your system gets more complicated over time, gathering up new modules and patches, there’ll be more at risk whenever you make a change. You don’t want to end up feeling like a late-game Jenga player, fingers trembling as you approach a move that will surely send the whole tower toppling down.
What regression testing involves
Regression testing, in general, is the process of reviewing software to ensure that it can still do everything it was ever designed to do. Unlike standard testing, it doesn’t test only the latest functions — consider it the equivalent of a full-body physical.
This is essential since software relies on both the new and the familiar, with the basics mattering as much as the freshest and most sophisticated features. When something low-level breaks, it has a cascading effect that disrupts everything around it — and everything built on it.
In practical terms, regression testing involves a host of practical tests based on all the intended functions of a system. For instance, one test may be “Convert a file from format A to format B” using a provided conversion form. Another could be “Return a set of products based on user-selected parameters” using a dynamic filter.
Can these tests be carried out manually? Yes, but they shouldn’t be. Think of how many tests of this kind might apply to a substantial website (hundreds, or even thousands), then think of running through each one for every update (possibly on a weekly basis). It’s precisely the kind of work that should be automated, so it is automated wherever viable.
And what of UI regression testing, specifically? UI regression testing is about the end-user experience. The testing isn’t about internal operations, but about the various ways in which a user might interact with a system. Tasks might be things like “Locate product X from the homepage” or “Submit a support ticket”. Automating this type of testing is all about simulating real-world use cases — interacting with websites and utilities much as people do.
How to use UI regression testing for your brand
Becoming a top digital brand, and maintaining that position, is all about keeping up with the times: changing the features you offer and the interface you provide to meet shifting standards and stay ahead of the competition. As noted, this produces a heavy testing workload: when you submit your fresh website design, you can’t risk breaking something vital.
That’s why you need to be using batteries of UI tests to check the health of your website’s interface on a regular basis — and this is what CloudQA’s TruBot was designed to accomplish. Needing no programming skills, you can create testing scenarios for bots to carry out. Simply record the test procedure from the perspective of a user, then carry the steps across.
Bear in mind that it’s useful to carry out UI regression testing even if you don’t update your website frequently. This is due to the influence of SaaS and integrations. If one of the platforms or services your website runs on is updated, or a system your website is integrated with breaks (an Instagram UGC feed, for instance, might break following an API update), then you can be left with a UI that doesn’t work correctly.
The more money you have riding on the reliable performance of your website and software, the more important it is that you carry out UI regression testing on a semi-regular basis. The faster you identify problems, the faster you can address them, and the fewer support tickets you’ll need to deal with.
RECENT POSTS
Guides
- Published in Article
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.
Quickly convert your end-to-end web testing process to run over 80% faster and accurate now.
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 twitter
Share on linkedin
Share on email
Find out now how you can switch from manual to automated testing in less than a week
- Published in Article
