by admin | Mar 26, 2020 | Automation Testing, Fixed, Blog |
In this blog article, we have listed tools and libraries we use for Python Test Automation Services. Few popular tools to automate web and mobile apps are Selenium and Appium.
However, there are few widely used Python Packages which will help you create and manage your automated test scripts effectively.
Let’s see them one by one.
PyCharm-Python IDE
PyCharm is an excellent IDE choice for automation script development. PyCharm comes in Professional and Community editions. We use Community edition since we need it only for automation testing purpose.
Behave BDD Framework
There are many BDD frameworks like (Lettuce, Radish, Freshen, & Behave) which goes hand in hand with Python. We use Behave BDD frameworks for automation testing projects. Behave has all the required features of BDD.
openpyxl
openpyxl is an Excel library to read and write xls & xlsx files. If you want to install and explore openpyxl, please refer the following blog article. How to read & write Excel using Python
Page Object Pattern
When you apply Page Object Pattern, you can enable re-usability and readability. For example: Every test case in your test suite may instruct you to visit login page multiple times. However, when you do this in automation testing, you no need to write Login page steps in multiple test case files. Create a Page Object Class and call the methods whenever you want the login steps. You can write much cleaner test code using Page Object Pattern.
ReportPortal
Creating and maintaining an automation reporting dashboard is never an easy task for a testing team. Writing robust automated tests is a cumbersome task for an automation tester. Creating your own test automation reporting dashboard is an additional effort. We have created many test automation reporting dashboard for our clients. However, nowadays, we have started using ReportPortal instead of reinventing the wheel.
In Conclusion
Python Test Automation is gaining much popularity among automation testers. Follow automation testing best practices, have a right team and use right tools & libraries. This will undoubtedly help you succeed in automation testing.
by admin | Apr 7, 2020 | Automation Testing, Fixed, Blog |
While building any test automation framework and designing scripts at times we might end up having flakiness in scripts if the proper standards and the test data generation are bad. Given the fact that in test automation framework results are vital as they state whether the test passed or failed and ultimately that concludes the stability of the application under test. Holistically result from reports are the ones which help the business stakeholders to understand where we are with respect to the software product launch.
In this blog we are going to talk about the importance of the results and how should we ensure we don’t fake them. False results are capable of creating a big mess in the system and they are quite costly to fix and learn.
Having said about the fake results, let’s understand what we are meaning to say by the word fake.
It can be of something that has a bug in the software system but the test shows it’s passed. By the term of medical science, this can be addressed as false positive, because we have seen a pass result that is not actually true.
On the other hand, there can be a scenario where the functionality in the system could have been in working state, however, the test shows it failed. This behavior being inline with the medical science term called a false negative.
Relation between automation testing and false positive/negative
Glad that we understood a couple of new terms, but it is still a question as to what’s the relationship between them and the automation testing? why only applicable to automation testing?
If we just recall the purpose of automation, it is essential to script the test case and execute it in the future so that the manual effort spent in reduced. So when we are scripting it for future use a high degree of care should be taken and get the things right. The reason for insisting on the promptness and care is we are not going to be visiting the script thoroughly every now and then. If at all due to oversight something wrongly implemented it obviously serves the wrong results and ultimately leads to flakiness it could be either false positive or false negative.
And to answer the question why it doesn’t applicable to functional manual testing, their user applies his sense than some automated process, any wrong input gets corrected during the execution itself hence there is no room for this concept in manual testing.
Importance to look after false positive/negative
As briefed above at a very high level that these false positive and false negative results can cause a great loss in the business as we are purely mistaking the results. It could impact in the following ways.
A false positive can lead to bug leak in the market as it was pursued to be working good at our site, this can greatly impact the reputation and business loss for the company.
A false negative can lead to spending extraneous effort by various people because of the reported problem when it’s not true. The bug has to be initially understood then learn to repeat then spend efforts to triage the same to conclude it. These efforts ultimately affect the deadline of a release.
Reasons for flakiness in scripts and possible solutions
Let’s understand the prime reasons for occurring false positive/ negative
Incorrect test data
Test data is mandatory to input for any test case to execute. We should always generate the test data as per the guidelines set for the fields in the application. Violation of the rules will lead to abrupt script failure this causes the test case to be failing.
The above failure of the false under the category of a false negative, the reason being we were not supposed to see a failure had there been in data issue.
Duplicate test data
In the recent era applications have gained a lot of maturity in order to serve the user better. Certain important fields will not accept the duplicate data, so if we fail to generate the unique data we again hit a false failure this again comes under the category of false negative.
In order to overcome that we should always generate unique data. One possible solution would be to generate random values and append to the actual test data that is being read from the external excel file.
Improper coding standards
While designing the scripts proper coding standards must be followed failing which will lead to the failure of the scripts in the form of a false positive or false negative. Let’s discuss a few key points in coding standards as what we really mean by and what its contribution in leading to failure is.
Wait handling events
When we are especially automating the GUI we expect some delay for a page to load and the elements to generate and attach to DOM. We also have a parameter of the network, considering all these things we should lay out a plan to handle the weight properly. We should also keep in mind that due to the inclusion of waits the order of n of a script should not go too high. We should be very careful enough to select the appropriate wait, to see below there are 3 waits that we can use as per need
Implicit wait
Explicit wait
Fluent wait
Java wait- thread.sleep(1000)
Initiating and closing browser connections
As we know that the test runs in browser hence invoking and quitting the browser is the most common action that we interact with. The opening and closing actions should be managed correctly by the testNG annotation so that we have a new instance created after each test after each execution as desired. The recommendation would be to launch a new instance after every test so that the impact of one test will not be there on the subsequent test.
Also we should ensure that if at all any browser is running in the port even after completion of test we must close those connections before we re-launch the new browser instance for a subsequent test. It is recommended to use driver.quit() to help withclosing all connections as driver.close() only closes the current browser. This way we can avoid any flakiness that browser can contribute.
Not handling the exceptions
Exception handling brings a lot of sense to the code, it helps application from not to terminate abruptly on failure cases. This is being achieved by surrounding the code snippet with try and catch blocks with necessary exceptions hierarchy.
What basically happens is that, if at all we don’t have a mechanism of catching the anticipated exceptions in the corresponding code block when we face that exception, unfortunately, test case interrupts abruptly and no report would capture that failure as we don’t have that execution caught also any finally block to execute certain mandatory information. In this case, we will get a report with the actual result status of the previous test steps (be it pass/ fail) and report generation stops and it flushes. Ultimately the report doesn’t have the proper results printed in it, its creating false positive or negative in this case.
The prominent solution would be to use the try-catch blocks properly with necessary test step information printed so that everyone can understand that the test actually failed.
Not printing the test step description and status in the report
Report is one of the best evidence to check whether a particular test failed or passed. As it’s a bible it’s essential to capture the right information. We should be very diligent while writing the report and capturing the test step information. A small wording mistake can change the meaning of the result and it creates ambiguity.
Conclusion
Since automated tests are executed by a system and given the fact that it has no intelligence thus far rather than performing the assigned task, it’s our responsibility to get the things right on the very first time, so that the verification and analysis would not take much longer to understand while publishing the results. A small mistake can even be costlier based on the priority so nothing can be misjudged or misunderstood.
Hope the information gave some insights on the topic, thanks for reading through.
Happy learning!!!
by admin | Apr 1, 2020 | Automation Testing, Fixed, Blog |
Test automation framework to be explained in laymen terms as the set of guidelines such as coding standards, data handling, report presentation and bringing the repository system into place. With the following of the guidelines, we can make the suite more re-usable with as less maintenance as possible.
What is Test Automation Framework?
Framework is all about defining set protocols, rules and regulations to make the task more standardized.
The framework standard makes us be more procedural oriented. This standard practice will help everyone to understand the way to achieve a specific task and we have great control of tracking things and ultimately we end up have hassle-free maintenance. In the software development life cycle we rely on two we follow two major approaches in order to build a successful software product let’s see what are they and role of the framework.
Let’s quickly discuss the two common framework approaches that are followed most commonly in development and testing streams. These are rule-based approaches for the successful implementation of the task.
Test driven development approach (TDD)
This is one of the best agile development methodologies, in this approach we write tests first then the goal is to make sure the tests go through. This way we can get rid of redundant work and build a very accurate system.
Developers will establish a framework that all unit tests are automated. The code is then added to make sure the tests are passed and then the next implementation takes place. this is the repeated process that takes place until the product is completely built.
Behavior driven development approach
This is also a test-first approach but these acceptance tests were written by either business analysts or testers. Unlike the TDD, this driven approach will try to certify the implemented functionality. BDD Automation Testing approach is built in a fashion that it validates the full functionalities then produces a meaningful report to understand the results.
Role of a framework in test automation
1. Easy to maintain the test suite
2. Easy to transfer knowledge to any new joiner to the team
3. Code re-usability
Components in test automation framework
Thus far we have discussed the framework in a more general way, let’s take a moment to correlate that to the test automation. What are those rules and components that are collectively called as a framework in a test suite?
Dependency management
Whilst creating a project it’s essential to rely on dependency management and build tools to ensure all in the team uses the same version of a particular library. We should never consider loading the libraries from the build path. The omission of this rule can lead to great confusion and we might observe things that are working in one machine, may fairly get failed on other’s end. Also if there are version mismatches due to hardcoding the libraries by every individual we can’t root cause the problems.
Maven & Gradle can help us in resolving the dependencies also to build the code
Reporting results
Results are mandatory to be shared after test execution, so integrating a decent reporting API will help us publishing a report that can be deciphered by all the stakeholders. Report creation must be taken utmost care as it shows how many tests are passed and failed. The failed ones can later be analyzed to see if they are true defects are any script or environment issues.
Best reports that are used are extent reports, allure reports and testing Html reports
Test Runner
In a sophisticated test suite, we will have hundreds to thousand numbers of test cases. Without having a proper test runner tool we can manage the test execution. These tools will help us running the tests with different set options, some are a below
Prioritize the tests
Making one test dependent on other
Execution the same test for the number of times we want
Running the failed test cases
Grouping the test cases and run them in parallel of sequential fashion
Best examples of test runner tools are J-unit, N-unit, testNG, jasmine..etc
Version controlling system
Integration of VCS is essential as we as a team commit a lot of changes to the code base on a daily basis. It’s highly difficult to integrate the changes. Proper education on pulling he code as a first activity before we start our day then pushing at the end of the day after a review will help us maintain the code base up to the date.
Best examples of VCS systems are GIT, BitBucket, SVN..etc
Logging mechanism
Logs are anywhere in the world are treated to be important as that helps greatly in triaging and root cause a problem that’s occurred. We need to write log files to a file for each step we perform during test execution. This log acts as evidence to the malfunction we observe.
Log4j is one of the best log tools to be integrated
Third party tool integration
At times in order to perform specific tasks we might not be able to achieve with the existing framework then we should consider adding any third party tool that can help us doing that, this is how we are making our framework more sophisticated and precise
Example for the third party tools is VNC viewer, AutoIT, winnium…etc. we will need these tools while there is a need to perform some windows actions in selenium framework.
Screenshots capturing
We should have a disciplined screenshot capturing mechanism and storing them in a repository to help with understand the issue that occurred during failures. We can take a call as to whether to capture only on failure cases or on any test step depending upon the memory we have.
Types of test automation frameworks
Given the design implementation and other properties we have various types of test automation frameworks and they are as below
Linear framework
Linear framework is implemented in such a way that the test is directly written in a file as a straight forward test. This test can also be designed by using any record and playback tools. This kind of approach, however, is simpler to design it leaves us doing a lot of maintenance.
Advantages:
1. Easy to develop scripts
2. Not much coding experience is required, only tool experience would do the trick
Disadvantages:
Since the test is written directly, it’s very difficult to maintain the script when there are changes to the applications.
Modular framework
Modular framework is designed in such a way that, tests of common modules were first identified and then design those as reusable or generic methods. Since the common methods were designed as wrapper methods we can very well re-use them in any other test cases.
This kind of approach is followed when the application development is being done as individual microservices. Tests are developed for a specific service and only those can be invoked on demand.
Advantages:
1. Since the common flows have been documented as reusable methods, re-usability increases
2. Less maintenance required
Disadvantages:
Still the data is hardcoded in tests
Data driven framework
Data driven framework has been identified as one of the powerful frameworks across all. In this type, we can service the test data that’s needed via excel, JDBC sources, CSV files. The tests become more generic as the data has been separated from the test code. With the help of various data, script flow can be altered and that way we can achieve more test coverage.
In this we have classified the data as two types as
Parameterization
Any data that looks to be static and we don’t see dynamic changes can be considered as a parameter. The best examples for this kind of data are URLs, JDBC URLs, endpoint details and environment details. We tend to read this data from the properties file or from XML file
Dataprovider
This is the real test data needed for the test case. We basically read this data from the external sources such as Excel workbooks, CSV files, JDBC sources. This data has the ability to alter the flow of the test case. This facilitates us to provide more coverage with minimum code base.
Advantages:
1. Since the data is separated from the tests, tests become more versatile
2. Data can easily be created as per the requirement
3. Easy to maintain the scripts
Key driven framework
In keyword driven framework, the codebase/test case is driven by the action-based keyword. In this framework, we have all the actions identified and list as keywords then map to the application functionality. The keywords again are consumed from an external excel workbook or from a separate java class. This framework can be even developed without application by assuming the functional flow but it needs high expertise and it can lead to a re-work too if things don’t go right.
Advantages:
Since the code base is developed as per actions, methods developed for a particular action can be re-used.
Hybrid framework
Hybrid framework is a customized one, all the best things from the different frameworks are pursued in this. When we say customization, there is no standard practice as such, it’s all about the requirement within a particular project. We might see a mix of data-driven, keyword and modular practices to make the framework more versatile and flexible to maintain.
Behavior-driven development framework
Behavior driven development approach is also known as ATDD (acceptance test-driven development). In this model, the tests are driven by a test step written by either BA or tester in plain English that is understood by everybody. A spec file or feature file is created for a specific test case in gherkin language then the code base is developed accordingly.
How is this model helping?
Ever since the agile model of development has emerged, we started giving more priority to parallel testing and early testing alongside development. There were some challenges in understanding the test case developed in the above discussed other frameworks. Tests appear to be more technical so that it’s getting difficult for non-technical stakeholders to understand. In this approach as the test case written in a specific language which is gherkin (more or less English). Given the design, it’s easy for everyone to say what’s happening with the test also report makes more sense too.
Examples of this kind of frameworks are- cucumber, gauge..etc
Conclusion
There is no wrong in being a process nerd because unless we have protocols defined even in our lives we can’t be sure of the progress and get the things right on the very first opportunity. In the same fashion with the help of above-defined rules we can achieve the tasks hence thanks to the framework and its defined best practices. We should still be under an impression that the best yet to come, given that sense we expect lot more enhancements to make our lives far easier at work. Change is inevitable be ready to adopt.
Thanks for walking through this long, I reckon you would have had some learning.
by admin | Mar 28, 2020 | Automation Testing, Fixed, Blog |
Python behave is a much widely used BDD framework these days. In this blog article, you will get to learn behave BDD framework’s features and how to use it to create automation test scripts. Behave is an open source tool which has 62 contributors who are actively developing new features and fixing the issues. Python Behave is a matured BDD framework.
Implementing readable and business friendly automation testing solution is the need of the hour. When your automation test suites gives provision for non-technical people to collaborate, it will be a value add to your product/project. As an automation testing services company, we get lot of inquiries on implementing business friendly test automation solution of late.
Feature Files
behave is considered to be a clone of Cucumber BDD framework. Most of the features of behave is similar to Cucumber. However, there is a provision for additional flexibility in behave framework. Let’s have a look at them one by one. You can execute feature files in the following ways – by providing feature name, feature directory, at last without providing feature details. When you run behave command without feature path, it will search feature files in features directory by default.
Fixtures
Fixtures aka Hooks are used to call Setup & Cleanup code before and after Test Run, Feature, Scenario, and Tag. You needn’t write a separate method for ‘After’ hooks. Both ‘Before’ and ‘After’ hooks can be implemented inside a single method. Let’s look at the below example.
Feature
@launch.browser
Feature: Codoid Website Feature
Scenario: Contact Codoid Team
Given I am on home page
When I submit contact us form
Then I should see Thank You page with a message
environment.py
from behave import fixture, use_fixture
from selenium import webdriver
@fixture
def launch_browser(context, timeout=30, **kwargs):
context.driver = webdriver.Chrome(executable_path='driverschromedriver.exe')
yield context.driver
context.driver.quit()
def before_tag(context, tag):
if tag == "launch.browser":
the_fixture = use_fixture(launch_browser, context)
step_def.py
from behave import given, when, then
from selenium import webdriver
@given('I am on home page')
def step_impl(context):
context.driver.get("https://codoid.com")
assert True is True
Executing Remaining Steps in a Scenario
By default, scenario execution will be stopped if any of the steps is failed. However, you can override this in behave framework using Hooks and Command line.
Hook
from behave.model import Scenario
def before_all(context):
userdata = context.config.userdata
continue_after_failed = userdata.getbool("runner.continue_after_failed_step", False)
Scenario.continue_after_failed_step = continue_after_failed
Command Line
behave -D runner.continue_after_failed_step=true features/
Filtering Scenarios and Examples using Tag Value
You can select scenarios and examples using Tag and its value. This feature is helpful when you want to select an example based on the environment value for a tag.
Feature:
Scenario Outline: Wow
Given an employee "<name>"
@use.with_stage=develop
Examples: Araxas
| name | birthyear |
| Alice | 1985 |
| Bob | 1975 |
@use.with_stage=integration
Examples:
| name | birthyear |
| Charly | 1995 |
In Conclusion
As a test automation services company, we advocate behave BDD framework for creating readable and understandable automation test suite. It is still widely used by the automation community and its contributors are releasing newer versions frequently based on the market need.
by admin | Feb 4, 2020 | Automation Testing, Fixed, Blog |
Ask yourself, what do you want out of the test automation process? Without identifying your goals for test automation, you can’t succeed. You should define your goals by a set of gauges called success criteria since every team is different. Every stage of maturity in the process of finance, regulation, technology, and skill should be appropriately assessed.
Let’s see how your success criteria can be converted to success with your testing teams shifting to automation. Is it your default practice? Don’t automate every test, but at the same time, it is highly beneficial if you automate tests by answering the question of why we should not automate it. The constant churning of code will help, and many teams experience that in trying to define, redefine, and implement standards for automation, they end up saving time. Learn new skills and automation techniques to create a list of conditions needed to use your current
automation abilities.
Automated tests are nothing but clients of a System Under Test (SUT). Check if your automated tests/test clients execute anywhere and at any time because sometimes constraints can force these tests to run in a specific environment. Automated tests run on different machines and can quickly determine the devices it works on so that you fix it for those it doesn’t. Developers should run tests on their devices and use them for debugging. While testers, analysts, and product managers should be able to access tests and question aspects of the application. If tests are flexible, it will allow information to be gathered about the SUT by having test-client code executed on various devices and teams working through the environmental constraints.
Tests should continue to execute without any human intervention, and you shouldn’t have to push more than one button to get it going. Did you do anything before decision-makers could view the reports or before you started the tests? If yes, then you’re not meeting the set criterion. Run tests frequently because when automation is not run automatically against changing code, it is not an efficient setup, and you won’t get credible results. Have unit tests and test your automation and system often, through scheduled runs. Continuous Integration (CI) should bedone to test automation, just like compilers check code and ensure that tests run publicly. If a test case that failed once passes during a rerun, double-check the defect that showed up in the first instance, because good testers don’t ignore anomalies. Communicate what should be changed in your application by coding tolerance for it. Make your testing reliable and trustworthy for it to be considered successful.
Inferior automation can drive automation engineers to waste time debugging code rather than provide timely, accurate information to developers and other stakeholders. Your automation engineers should focus on building new tests instead of maintaining existing automation. If automation needs codebases, environments, agents, and systems, we should free them up and
not hinder the process by being ready for testing all the time. Sincere and transparent test automation reports will help your developers act quickly. Ensure they produce multiple test cases per day to check if there are problems with the commitment to the automation and testing process.
Reassess agent roles and responsibilities by updating automation goals and treat it as a development activity. Someone on the team must be accountable for fixing issues with automation because when no one owns it, automation fails. Your automation team should use the best practices of software development. Testers should store automation in source code control, maintain existing automation, plan for future automation, and fix failing tests immediately. Consider technical debt for test automation and account for automation by adhering to coding standards and practices.
Create test automation before, or in parallel with test code. A different vision of success for each team will help you assess if your team is ready. If the team is, then you’ll be prepared to work in a Continuous Delivery (CD) world, and your end-users will get reliable, precise, and on-time insight into your applications. QA companies like Codoid , have adapted its practices to help its clients strategize goals to achieve a successful implementation of their automation testing services.
by admin | Feb 2, 2020 | Automation Testing, Fixed, Blog |
This is a blog article which intents to review PractiTest, one of the best test management tools available in the market. It helps you ease the testing and development process. Sharing quick feedback to the team after QA activities is important to deliver high-quality software to the end-users. Sharing the test results in an excel sheet as an attachment has become obsolete. Your managers have to view/analyse the test results quickly in order to take decision. Let’s say you present the test results in a web dashboard, then it makes it easy for the entire team to understand the outcome of your report post successful completion of the testing activity. Let’s see how you can manage test cases and share the test results in PractiTest.
PractiTest is an application life cycle management platform. You can manage the requirements, test plans, test cases, and issues effectively. It helps to share the test results to everyone. If your team has already started developing the application without a test management tool or is fed up with the current tool, you can easily import the existing artifacts in PractiTest and start managing the tests effectively.
You can link the defined requirements with the test cases to achieve traceability. PractiTest provides end-to-end visibility. When you perform test execution, it will reflect the status in Test Library and Requirements modules in PractiTest.
Using a complicated test case management tool always increases maintenance effort. The tool should be simple enough to manage and define test cases. The idea of PractiTest is to divide test cases that are created, imported to and stored in the Test Library, from the Test Sets & Runs where you group those tests according to relevancy (for example – cycle, sprint etc) and run them as instances. Unlike other systems that work with static folders, PractiTest uses dynamic filter trees (based on system and custom fields) to organize all testing data. With filter trees, a user can slice and dice his data according to what he needs and create customized dashboards and reports to other stakeholders based on the data relevant to them.
Jira is a most widely used Project management tool. Test management tool without Jira integration neither adds any value to your team nor your project. In PractiTest, you can import requirements from Jira by just providing Jira Ticket number. When you make any changes to a Jira ticket, the changes will be reflected in ParctiTest immediately. You can also create Jira Bug ticket when executing your test cases. Linking between the test case and the Jira Issue will be established automatically when you create a Jira Bug from PractiTest. PractiTest provides JIRA Two-Way Integration feature. i.e. you can view test execution status in Jira ticket for the linked test cases.
You can set execution time for each test case. This feature is helpful to determine the difference between actual and expected test execution time. When you induct new QA engineers in your team, time duration details will make them to understand how much time need to be spent for individual test case.
One of the main ideas of PractiTest is to enable visibility to the entire testing process including automation. The system integrates with automation using REST API and Fire Cracker. You can update test case status by calling PractiTest API from your automation testing framework. Since this is an API call, you can integrate PractiTest in any test automation codebase. The following test case statuses – PASSED, FAILED, BLOCKED, OT COMPLETED, NO RUN can be sent from automated test script.
Firecracker allows you to take XML report files from any CI/CD tool and upload them into PractiTest. From now on, every time you have new build results, they will be sent to PractiTest where you will be able to see the results of your entire software development and deployment processes in one solution.
PractiTest integrations include the following systems: Jira Cloud, Jira Server & Datacenter, Pivotal Tracker, Bugzilla, Youtrack, Azure DevOps, CA Agile Central (Rally), FogBugz, GitHub, GitLab, Trac, Mantis, Assembla, Lighthouse, Redmine , Slack, SVN, Zapier, AND Jenkins.
PractiTest has Exploratory Testing module which allows you to define test charters & guide points for your exploratory sessions and save those guidelines as test cases for future reusability. When running the ET test case, you can document important points that arises in the annotation section as well as report new issues or links existing issues.
If your team is not using Jira for Agile Development Process, then you can very well use PractiTest to save the artifacts. For example – You can use Requirements module to define User Stories & Test Library module to create Acceptance Tests. You can use the Dashboard to keep your team up to date with the status of the Sprint in General and of each User Storie in particular.
Without a proper testing report, your team cannot take appropriate decision during a release. Spending time to prepare test reports is a waste of time. Quicker and quality feedback help your team. PractiTest provides pre-defined report templates (Tabular Report, Tabular Aggregated Report, and Detailed Report.) You can also modify report columns & graphs based on your needs and schedule the reports to send on daily, weekly or monthly basis.
Let’s say your testers are writing test cases for two functionalities which are almost identical, then you need to reuse the test steps instead of duplicating them. PractiTest allows you to call test steps from another test to enable reusability.
As a leading software testing company, we have used a wide range of software testing tools for our QA projects. If you are planning to evaluate test management tools, then don’t forget to add PractiTest in your list. It comes in three basic versions namely Professional, Enterprise, and Unlimited. You can signup for 15 days Trial period for thorough evaluation. Please note – for automation testing integration, we recommend Enterprise plan.
We hope you’ve enjoyed reading this blog article as much as we’ve enjoyed writing it. Contact Us for your QA needs.
A fool with a tool is still a fool.
