Archive for the ‘Quality Assurance’ Category

Requirement Traceability Matrix – RTM

Monday, June 29th, 2020

What is a Traceability Matrix?

A traceability matrix is a type of document that creates a relation between two-baseline documents which will have many-to-many relation to check the completeness.

Main use of traceability matrix is requirement tracking and current project requirements are meeting or not.

What is the Requirement Traceability Matrix?

RTM captures all requirements proposed by the client or software development team and their traceability in a single document delivered at the conclusion of the life-cycle.

The main purpose of Requirement Traceability Matrix is to ensure that all test cases are covered so that no functionality should be missed while doing testing.

In Agile methodology we don’t prefer to have a requirement traceability matrix as it is having a fast paced work model and the turnaround time is shorter.

Some specific parameters in RTM to make it more efficient as follows :

Parameters of requirement traceability matrix:

  • Requirement ID
  • Risks
  • Requirement Type and Description
  • Trace to design specification
  • Unit test cases
  • Integration test cases
  • System test cases
  • User acceptance test cases
  • Trace to test script

RTM flow:

RTM is used to track or trace the requirement in all perspectives as per the terminologies Forward and Backward.

Forward traceability:

This matrix is used to check whether the project progresses in the desired direction and for the right product. It makes sure that each requirement is applied to the product and that each requirement is tested thoroughly. It maps requirements to test cases.

Backward or reverse traceability:

It is used to ensure whether the current product remains on the right track. The purpose behind this type of traceability is to verify that we are not expanding the scope of the project by adding code, design elements, test or other work that is not specified in the requirements. It maps test cases to requirements.

Types of Traceability Matrix:

Bi-directional traceability (Forward+Backward):This traceability matrix ensures that all requirements are covered by the test cases. It analyzes the impact of a change in requirements affected by a defect in a work product and vice versa.

Let’s Go Ahead and create RTM:

Step 1: Our Test Case is”Verify Login, when correct ID and Password is entered, it should login successfully”

Step 2: Identify the Technical Requirement that this test case is verifying. For our test case, the technical requirement is T94 is being verified.

Step 3: Note this Technical Requirement (T94) in the Test Case.

Step 4: Identify the Business Requirement for which this TR (Technical Requirement-T94) is defined.

Step 5: Note the BR (Business Requirement) in Test Case.

Step 6: Do above for all Test Cases. Later Extract the First 3 Columns from your Test Suite. RTM is Ready!

Before we discuss the details, it’s important to understand the difference between BRD and FRS.

FRS documents detail out the BRD and split each business requirement into multiple functional requirements. Hence in an RTM, you can opt to highlight both the BRD Number and FRS Number to ensure all BR’s are mapped to FR’s. So the table below showcases the same wherein the BR and FR ID’s are mapped.

Below is a sample of the test scenario document:

S. NoTest Scenario IDTest Scenarios
1TS_Sign-up_001Verify whether the user is able to sign-up via sign-up form, facebook, gmail.
2TS_Login_002Verify whether the user is able to login via login form, gmail, facebook.
3TS_User Profile_003Verify whether the user is able to fill all required details and save them.

Test Scenario Document

In the above table, the test scenario document highlights the test scenario ID used in the RTM document. The document will ensure that all the test scenarios should cover all the requirements mentioned in the requirements document. Likewise, a test case document which shows the mapping between the test scenario ID and test cases.

Advantage of Requirement Traceability Matrix

  • It confirms 100% test coverage.
  • It highlights any requirements missing or document inconsistencies.
  • It shows the overall defects or execution status with a focus on business requirements.
  • It helps in analyzing or estimating the impact on the QA team’s work with respect to revisiting or re-working on the test cases.

API Automation with Rest Assured

Monday, June 29th, 2020

Introduction of Rest API

Rest-Assured is a Java-based library that is used to test RESTful Web Services. We can build a customized HTTP Request to send to the Restful server. This allows us to test a variety of Request permutations and in turn test various combinations of main business logic.

Rest-Assured library also provides the capability to authenticate the HTTP Responses accepted from the server. For e.g. we can verify the Status code, Status message, Headers and even the body of the response.

What is Rest Assured?

REST Assured library is the best tool to automate your rest api’s. Rest Assured has a gherkin type syntax.

List of few Rest Assured features:

  • DSL-like syntax
  • XPath-Validation
  • Specification Reuse
  • Easy file uploads 

All these features support in handling api tests in a very well managed way.

Why Are We Using Rest Assured?

REST Assured offers a number of other useful features for writing tests for RESTful APIs. Let’s take a look at some of them.

  • Technical response data validation
  • Data-driven testing
  • Support for authentication mechanisms

The benefits of REST Assured

Aspects of REST Assured which makes it a most appropriate library for API testing:

  • In traditional development we have to write a large amount of code to set up http connection, send a request and receive and parse the response, while with the rest assured a lot of boilerplate code is not required to be written.
  • Since REST Assured is a Java library, integrating it into a continuous integration / continuous delivery setup is a breeze, especially when combined with a Java testing framework such as JUnit or TestNG


Challenges behind API Automation Testing:

Initial Setup

Foremost obstacle in any automation testing is initial setup. If the initial setup is too much complicated, then enthusiasm goes down as the time passes. Most people, even companies, put automation testing on hold or leave in the middle and proceed with the manual testing. This is one of the major blockers in automation of the testing process. If initial setup is easy-going, then implementation of the testing framework / tool will be much easier and highly achievable.

Maintenance

Second major barrier is maintenance. Once you have created your test suites for any release. Then the query comes in your mind, is it easy to maintain those test suites over a period of releases? If improving those test suites takes a good amount of effort, then it is worse than the manual testing. If upgrading time is less than we can easily maintain those test suites.

Management

Third obstacle is management and is to some extent related to maintenance. Management makes the tasks of organizing test suites easier and more maintainable. If you have linked your API test cases with API Specifications, then proper management can give you answers to the questions like whether your API is fully tested or not.

Skilled Resources

Fourth hurdle is skills required to use the library / tool. If we adopt a tool / library, then we should have people having those skills set required for the usage of the tool. In the range of REST API, we can benefit from the tools in which no technical skills are required to validate REST APIs because REST APIs are platform independent and language agnostic.

Integration with existing ecosystem

Fifth hurdle is integration with the existing ecosystem. It is important to know how well the library / tool integrates with your build or defect tracking system (or any other). Whenever you prepare a new build, it should fire the automated test suite first and if all the test cases pass, only then the build is ready to be released in the market. And if the validation fails, then your automated test suite should automatically log bugs against the failed test cases.

What is Jmeter?

Friday, June 19th, 2020

The Apache JMeterTM is pure Java open source software, which was first developed by Stefano Mazzocchi of the Apache Software Foundation, designed to load test functional behavior and measure performance. Apache JMeter is a testing tool used for analyzing and measuring the performance of different software services and products. It is a pure Java open source software used for testing Web Application or FTP application.

It is used to execute performance testing, load testing and functional testing of web applications. JMeter can also simulate a heavy load on a server by creating tons of virtual concurrent users to web server

What is Performance Testing:

Performance Testing is defined as a type of software testing to ensure that software applications will perform well under their expected workload. It focuses on certain factors of a Software Program such as:

  • Speed – It Checks whether the response of the application is fast.
  • Scalability – It determines the maximum user load.
  • Stability – It checks if the application is stable under varying loads.

It is very important to verify whether the product meets expected or required performance. Unfortunately, we figure out this pitfall post-delivery of the product. But performance has become an inevitable factor nowadays, especially for web and mobile applications as the user strength is very huge for each application.

Tools used for Performance Testing:

Performance testing is significant in real time, particularly from a point of view of customer satisfaction. There are several performance testing tools available such as:

  • Apache JMeter
  • LoadRunner
  • WebLOAD
  • LoadUI
  • LoadView
  • NeoLoad

How does JMeter perform Testing?

Let’s have a look at the different steps performed by JMeter during testing:

  • It creates a request and sends to the server.
  • It receives the response from server, collects them and visualizes those details in a chart or graph.
  • It processes the response from the server.
  • It generates the test result in several formats such as text, XML, JSON so that the tester can analyze data.

Apache JMeter – How is works?

The web server handles or carries loads of lots of applications & its user, so there is a need to know how JMeter helps us to handle the performance of Web server to manage simultaneous users or their applications. 

For Example: Online purchasing site, how they handle their sale when there are lots of users are accessing the same page of the product. To handle or check that kind of performance of application or server we must do a high performance or a load testing using JMeter.

There are three different approaches to JMeter testing:

  • Performance Testing – This testing used to test the performance of site configuration of infrastructure & helps us to get results Quickly & easily before we transfer the application in Production environment.
  • Load Testing – This testing is used to check the extreme load of a system that can be aimed to handle.
  • Stress Test – This test tries to break the system by crushing its resources.

Plugins & Protocols:

JMeter works with different plugins & Protocols, Also Off-site developers can simply spread JMeter with custom plugins.

 JMeter works on many protocols which are: 

  • Web Services – SOAP / XML-RPC
  • Service – POP3, IMAP, SMTP, FTP
  • Web – HTTPS sites ‘web 1.0’ web 2.0 (ajax, flex and flex-ws-amf), HTTP 
  • Messaging Oriented service – JMS
  • Database – JDBC drivers, Directory – LDAP

Working features of JMeter:

JMeter works as a number of users send a request for accessing some server & shows the performance by the listeners like tables, graphs etc. 

Characteristics of Apache JMeter

Why People choose Apache JMeter for Performance & Load testing. Here are some characteristics which are mentioned below:

  • Open source application – Apache JMeter is an openly available free tool & it facilitates users or developers to use the code for other development or modification purpose.
  • Platform independent – It can run on any platform & also it is capable enough to check the load & performance of any server requests.
  • User friendly GUI – Its user-friendly, simple & easy to understand.
  • Write your own test – Using Jmeter we can write our own test cases. It uses a text editor to create a test plan and supplies in XML format.
  • Simulation – JMeter can parallelly work with threads to generate a heavy load on the server.
  • Installation – It’s easy to install on different OS like:
    Run the “*.bat” file to use JMeter
    Mac – JMeter can be accessed by typing the Mr. jmeter.sh
    Linux/Unix – JMeter can be accessed by clicking on a JMeter shell script.
    Windows – JMeter can be accessed by starting the JMeter.bat file.
  • Record & Run: JMeter provides the facility to record the steps by using Blaze master add-on & run with any number of threads & listeners.
  • Support multi-protocol: JMeter works on web application testing and database server testing and supports protocols such as JDBC, HTTP, LDAP, SOAP, JMS, and FTP.

JMeter is a pure Java application and should run correctly on any system that has a compatible Java implementation.

Here is the list of an operating system compatible with JMeter:

  • Linux
  • Windows
  • Mac OS
  • Ubuntu

JMeter GUI: Test Plan & Workbench

As soon as you launch JMeter, you will see 2 elements

  • Test Plan
  • Workbench

What is a Test Plan? Test Plan is where you add elements required for your JMeter Test.

It stores all the elements (like ThreadGroup, Timers etc.) and their corresponding settings required to run your desired Tests.

What is WorkBench? The WorkBench simply provides a place to store test elements temporarily. WorkBench has no relation with Test Plan. JMeter will not save the contents of the WorkBench. It only saves the contents of the Test Plan branch.

Hope this blog helps you to make you clearer about the Apache JMeter. Feel free to share your queries OR any feedback for the same.

Decision Making Via Decision Trees in Manual Testing

Friday, June 19th, 2020

Overview

Decision table testing is a software testing technique used to test system behaviour for different input combinations. This is a systematic approach where the different input combinations and their corresponding system behaviour (Output) are captured in a tabular form. That is why it is also called as a Cause-Effect table where Cause and effects are captured for better test coverage.

Why Decision Table Testing is important?

  • In Software Testing, boundary value analysis and equivalent partitioning are other similar techniques used to ensure better coverage.
  • They are used if the system shows the same behaviour for a large set of inputs.
  • However, in a system where for each set of input values the system behaviour is different, boundary value analysis and equivalent partitioning technique are not effective in ensuring good test coverage.
  • In this case, decision table testing is a good option. This technique can make sure of good coverage, and the representation is simple so that it is easy to interpret and use.
  • This table can be used as the reference for the requirement and for the functionality development since it is easy to understand and cover all the combinations.
  • The significance of this technique becomes immediately clear as the number of inputs increases. Number of possible Combinations is given by 2 ^ n, where n is the number of inputs.

Use Case of Decision Table Testing:

How to make Decision Table for Login Screen

Let’s create a decision table for a login screen

Email- ************.com
Login- XYZ

Password-########


The condition is simple if the user provides correct username and password the user will be redirected to the homepage. If any of the input is wrong, an error message will be displayed.

ConditionsCase 1Case 2Case 3Case 4
Username F T F T
Password F F T T
Output E E E H

Notations:

  • T – Correct username/password
  • F – Wrong username/password
  • E – Error message is displayed
  • H – Home screen is displayed

Interpretations:

  • Case 1: Username and password both were wrong. The user is shown an error message.
  • Case 2: Username was correct, but the password was wrong. The user is shown an error message.
  • Case 3: Username was wrong, but the password was correct. The user is shown an error message.
  • Case 4: Username and password both were correct, and the user navigated to homepage.

While converting this to test case, we can create 2 scenarios:

  • Enter correct username and correct password and click on login, and the expected result will be the user should be navigated to homepage.

And one from the below scenarios:

  • Enter wrong username and wrong password and click on login, and the expected result will be the user should get an error message.
  • Enter correct username and wrong password and click on login, and the expected result will be the user should get an error message.
  • Enter correct username and wrong password and click on login, and the expected result will be the user should get an error message.

Conclusion:

When the system behaviour is different for different input and not same for a range of inputs, both equivalent partitioning, and boundary value analysis won’t help, but decision table can be used.

This table will help to make effective combinations and can ensure a better coverage for testing. Any complex business conditions can be easily turned into decision tables.

In a case we are going for 100% coverage typically when the input combinations are low, this technique can ensure the coverage.

Manual Vs Automation Testing

Thursday, June 11th, 2020

In this article we are going to talk about advantages of Automation Testing over Manual testing.

What is Manual Testing and Automation Testing?

Manual testing is performed by hand. Quality Assurance (QA) specialists ensure that applications work properly by following conditions written in test cases. Despite its primitive nature, manual testing is still important, as certain functionality simply cannot be automatically tested. For example, wearables and mobile devices can require field testing in a physical environment. Mobile applications often undergo ‘monkey tests’ that detect bottlenecks during unpredicted stressful conditions. For instance, what happens if a user forgets a mobile device in their pocket with an application running and they tap the screen unintentionally? Is it possible that they’ll crash the app? Only manual testing can account for these scenarios.

Automation testing is a Software testing technique to test and compare the actual outcome with the expected outcome. This can be achieved by writing test scripts or using any automation testing tool. Test automation is used to automate repetitive tasks and other testing tasks which are difficult to perform manually

Now let’s discuss automated and manual testing in detail.

Automation Testing:

As per Industry standards and specialization our QA team automates the following types of testing:

Unit Testing is a level of software testing where individual units/ components of the software are tested. The purpose is to validate that each unit of the software performs as designed. A unit is the smallest testable part of any software. It usually has one or a few inputs and usually a single output.

Functional Testing is Software testing performed in order to detect the actual performance of an application’s functional requirements. Functional testing usually considers accuracy, interoperability, compliance, security, and suitability.

Regression Testing is defined as a type of software testing to confirm that a recent program or code change has not adversely affected existing features. Regression Testing is nothing but a full or partial selection of already executed test cases which are re-executed to ensure existing functionalities work fine

Graphical user interface (GUI) testing of software interfaces to check if the GUI meets all requirements.

These are the most common types of testing that we automate. Manual testing requires people and time, while automated testing reduces the demand on both resources. Also, automatic tests eliminate the risk of human error, making code more reliable. Now let’s see what tasks we can solve by automated testing.

Why you need automated testing?

Automated Testing Saves Time and Money

Software tests have to be repeated often during development cycles to ensure quality. Every time source code is modified software tests should be repeated.  Automated software testing can reduce the time to run repetitive tests from days to hours.

To handle repetitive tasks. If you’re constantly adding the same features or executing the same operations in a project, then the flexible nature of automated tests can be a great time saver.

To eliminate human error. Since automated tests are powered by tools and scripts, the chance of missing a bug or a defect decrease. This makes the testing process more reliable and time efficient.

For advanced GUI testing. Automated GUI tests detect and record differences in behavior between platforms — for example, across different web browsers or operating systems. Also, automated GUI testing effectively finds regression errors.

To test load and performance. There’s essentially no manual alternative for testing load and performance. Automated tests simulate hundreds and thousands of simultaneous users.

Why do you need Manual Testing?

Despite the seemingly broad coverage of automated testing, manual testing shouldn’t be underestimated. In fact, you have to test software manually before you run automated testing. Even though manual testing requires much effort, without it you cannot be sure that automation is possible. One of the key testing principles is that 100% testing automation is impossible. Manual testing is still necessary.

Let’s see which tests cannot be automated (or would take too much effort to automate):

Ad hoc testing is executed without preparation and writing test cases. During ad hoc testing, a QA specialist randomly tests the functionality of the system; his aim is to be creative, “break” the system and discover flaws.

Exploratory testing is defined as simultaneous learning, test design, and test execution. It is an approach to testing that values the tester as an integral part of the test process and shares the same values as the Agile Manifesto: Individuals and interactions over processes and tools. That’s how exploratory testing differs from ad hoc testing: in exploratory testing, you rely on your personal experience and design test cases in the testing process. An ad hoc testing can be done by any person without preparation.

User interface testing – By executing user interface tests, a QA specialist validates the properties and states of interface elements. Also, the QA team ensures that design elements in the interface match elements in the final layout.

As we can see, some tests should be performed manually. This especially relates to tests that focus on user interfaces and usability. Although we could automate basically everything, manual testing still provides an effective and quality check of bugs and improprieties.

The cases where manual testing has no comparison

UI Acceptance- Manual testing comes in handy when you test user interfaces, especially their visual aspects. Automated tests simply cannot detect colors of images or links, font sizes, gestures, and highlighting. Imagine that your application has a bug that causes a link to be so tiny that you can barely see it. Manual testers will immediately detect this bug, but automated tests are not able to notice the defect.

Initial development stage- Manual testing helps testers to detect bottlenecks during the initial development stage which results in less time and resources being spent on fixing bugs. Sometimes it’s not rational to invest money and human resources in automated testing during an unstable phase of a product’s development. However, in some approaches to software development, automated testing is a part of the process at any stage.

Short-term projects-Even though automated tests are aimed at saving time and resources, it takes time and resources to design and maintain them. In some cases, such as building a small promotional website, it can be much more efficient to rely on manual testing.

Non-automatable cases-Some tests cannot be automated; this especially concerns hardware-related tests. Writing scripts for automated checks of sensors, touchpads, and screens are almost impossible and rarely viable. Also, some data can be tested only manually. For example, you can automatically test if printer prints, but checking the quality and content of printed images is best done manually.

Conclusion

Manual Vs Automation Testing each have their strengths and weaknesses. What we want to stress is that no matter how great automated tests are, you cannot automate everything. Manual tests play an important role in software development and come in handy whenever you cannot automate the process.

Test Cases of HOCs containing Query Component using Jest

Thursday, June 4th, 2020

There are a plethora of articles on testing of react components using Jest and Enzymes, but there are fewer in which they talk about testing of complex components. However, this article will help you to walk-through the testing of complex components i.e HOC containing Query components.

The main focus of this article is to reach to the component on which we are able to find wrapper of that component using Jest

Implementation
Let’s take an example of the HOC with a basic query, which returns a new component:

Here we have passed Wrapped Component as an argument and when data is loaded HOC renders this passed component with new data and when loading is true it renders div component Loading… text, and if there is an error it renders div component Error text.

Testing

To test our HOCs I will be using Enzyme and Jest, you can easily add these to your project by npm or yarn task runner.

Click Here to know more

In withQueryDog.test.js, we have 3 test cases, loading, error and return a Component with new props. To check these test cases, we have used mount WithQueryHOC (loaded before each test with some mocked component) and we have used MockedProvider to mock (this allows the tests to be run in isolation and provides consistent results on every run by removing the dependence on remote data)

You may notice the prop being passed to the MockedProvider called addTypename, Reason this is here is because of how Apollo Client normally works. When a request is made with Apollo Client normally, it adds a  __typename field to every object type requested. This is to make sure that Apollo Client’s cache knows how to normalize and store the response.

When we’re making our mocks, though, we’re importing the raw queries without type names from the component files.You may also notice the await wait(0) line, it delays until the next “tick” of the event loop and allows time for that Promise returned from MockedProvider to be fulfilled. After that Promise resolves (or rejects), the component can be checked to ensure it displays the correct information.

About Author

Sagun Saluja is a technology enthusiast with 3+ years of experience working on  JavaScript projects using technologies such as ReactJS, Apollo Graphql, NodeJS, Express, Mongo, Jest.

Cross Browser Testing

Thursday, June 4th, 2020

What Is Cross Browser Testing?

Cross Browser Testing is a type of testing to verify if an application works across different browsers as expected and degrades gracefully.

It is the process of verifying your application’s compatibility with different browsers.

Many times, I have encountered an issue with a website and on calling the technical support, they simply tell me to try it in another browser? When I do, it works and I end up feeling like a total idiot, even though I earn my living working in the software industry. 

Introduction

We all might have observed that some websites are not properly displayed on some browsers and we just think that the website is broken. But, as soon as you open it on a different browser, the website opens just fine. This behavior explains the compatibility of a website with different browsers.

Each browser interprets the information on the website page differently. Thus, some browsers may lack the features that your website is trying to show and make your website look broken on that browser.

With the advancement in technology, there are several options available for browsers, and it’s not just enough to make a website work on one of the browsers.

Users should not be restricted to use any specific browser to access your application. Thus, it becomes necessary to test your website’s compatibility with different browsers. Some of the commonly used browsers include Chrome, Safari, Firefox, Internet Explorer etc.

Why Is It Performed?

For that matter, why is any kind of testing done?

  • To know what is wrong and be able to fix it.
  • To enhance efficiency and user experience and thereby, business.
  • To be informed of any possible pitfalls.

But specifically, if we think: What is the intent of cross-browser testing? – This is twofold.

  • The rendition or appearance of the page in different browsers- is it the same, is it different, if one is better than the other, etc.
  • The functionality and the working of it. (Of course!)

Who Performs cross browser Testing?

  • Are you thinking, “There are a million browsers, versions and platforms out there – which ones to choose?” This, thankfully, is not a decision that is the tester’s responsibility. The client, business analysis team and the marketing teams have a major role in this decision. Also, companies collect usage/traffic statistics to narrow down what browsers, environment and devices are mostly in use.
  • The entire project team should have an invested interest, time, money and infrastructure to support this endeavor.
  • The QA team can be involved in this process or it might be the design team who are keen on knowing how the application fares in multiple browsers.
  • Whether it is performed by QA or any other team- the results are interpreted by the design and development teams and the relevant changes are made.

How to Perform Cross Browser Testing?

First things first- is it done manually or using a tool?

It can surely be done manually- multiple machines, multiple OSs, Multiple browsers, multiple machines and but clearly, this leads to multiple problems, multiple investments and multiple challenges.

Manual Method

In this case, a business identifies the browsers that the application must support. Testers then re-run the same test cases using different browsers and observe the application’s behavior and report bugs if any.

In this type of testing, it is not possible to cover many browsers and, the application might not be tested on major browser versions.

Also, performing cross-browser check manually is costly and time-consuming too.

Automated Method

Cross-browser testing is basically running the same set of test cases multiple times on different browsers.

This type of repeated task is best suited for automation. Thus, it’s more cost and time effective to perform this testing by using tools.

So, lots of tools are available in the market to make this easier.

The tools help us with one or more or all the following depending on the tool itself and the licensing types:

  • They provide a VPN (Virtual Private machine) using which you can connect to remote machines and check the working and rendition of your JAVA, AJAX, HTML, Flash and other pages. Most of these are secure, but since you are submitting your information to a third party, a certain analysis on discretion is advised.
  • Screenshots are provided for the pages and links submitted of how they appear in multiple browsers. This is, of course, static.
  • Multiple browsers are synchronized with respect to operations performed on one and the results are presented browser wise.
  • Show the rendition of a page at multiple screen resolutions.
  • When a problem is encountered, a video or screenshots are recorded to transport the problem for further analysis.
  • Support generally is available for both web and mobile apps.
  • Private pages that require authentication to be accessed can also be tested
  • Local, within a private network/firewall pages, can be tested too.

When to Start this Testing?

The time to start Cross-Browser test completely depends on your testing methodology and your testing timeline.

1. As soon as possible:

Start this testing even when a single page is ready for testing.

Test that page on each browser. When the next page is available, test that also on multiple browsers. This will increase the efforts, but it will help to fix the errors as early as possible in the life cycle. Thus, fixing errors, in this case, is much cost-effective.

2. When the application is complete:

Start this testing when the application development is complete.

This will test the application on different browsers. Fixing the errors won’t be as cost-effective as in the above case but it will still help in fixing the errors before releasing the application to the users.

3. When the application is released:

This is the least favored time for performing a cross-browser test for your application. But it’s better to do it than to not do it and let the end-users have a bad experience.

After the application is released for the end-users, this testing can be performed, and bugs can be fixed as a part of the change requests in the application. This is very costly and requires multiple deployments depending on the bug fixes.

Rigorous cross-browser testing can only be done when the testing team members who have knowledge of tools do this testing. High level or checking some specific browsers can also be done by business users or even developers.

This testing involves testing the application thoroughly using different browsers. Testing thoroughly includes functional and non-functional testing of the application.

In most of the companies, a product team has separate teams for functional and non-functional testing. Thus, this testing needs to be performed by the team(s) who is (are) responsible for functional and non-functional testing of the application.

For this testing, a tester needs the browsers on which the application needs to be tested.

These browsers can either be provided to the tester as:

  • Locally installed on tester’s machine.
  • A virtual machine or different machines which a tester has access to.
  • Tools which provide their own browsers and their versions for testing.
  • On cloud – so that multiple testers can use the browsers as and when required.

This testing is independent of the deployment environments. Thus, it can be done in dev, test, QA or even production environment depending upon the availability of the application in each of these environments.

What to Test?

  • Base Functionality – Links, dialogs, menus etc.
  • Graphical User Interface – Look and feel of the application.
  • Response – How well the application responds to user actions.
  • Performance – Loading of the pages within allowed the time frame.

If your application works well on one browser, that doesn’t imply that it will work well on the other browsers too. Thus, this testing helps you to ensure that an application runs on different browsers without any errors.

To identify what breaks on which browser and to fix the website accordingly we need to perform this testing. If a browser is not at all supported, then the users can easily be informed about it.

To summarize “how” to cross-browser test:

  • Traffic statistics help determine what browsers to test.
  • A detailed analysis should be done on the AUT (Application under test) itself to determine what parts of the application or if all of it must undergo this. It is advisable that all of it be tested on multiple browsers, but again costs and time must be considered.  “A good strategy is to perform 100% testing on one browser per platform and for the other just test the most critical/widely used functionality“.
  • Once the decision of “What” to test and “Where (browsers)” is made- infrastructure decisions are to be made- do we acquire tools or perform this manually etc. Again, the cost must be considered. Viability, risks, security concerns, people to be involved, time, acceptance criteria, issue/defect fixing schedules/process – are few things that must be addressed.
  • Perform the testing. The regular functional testing test cases can be used when validating the efficiency of the system. For look-and-feel/rendition test cases are not necessary.
  • The operation I was talking about at the beginning of this article that failed for me was an online bank transfer. I logged into my bank account, chose the amount for transfer as about one lakh and tried to perform the transfer and a servlet error was showing up no matter how many times I tried.

So, if the transfer operation is chosen for browser compatibility testing, this is how the test script is going to look like.

  • Log in to the online bank account.
  • Select the account from which the transfer is to be done.
  • Enter the transfer amount: 100,000.
  • Select payee and click “Transfer”.
  • Expected result: The transfer should be successful.
  • This will simply be run on all the browsers chosen.

Again, please note that this does not look different to a functional test case. Please check this non-functional testing article for further information on this.

Report the results back to the design team, if they were not involved in the testing process. Change follows.

When is the best time to do this?

Any testing reaps the best benefits when it is done early on. Therefore, the industry recommendation is to start with it as soon as the page designs are available.

But it also can be performed when the site is fully integrated and functional.

If you have missed the bus on performing the cross-browser test during design, development and QA phases, it can still be done while the application is in production. However, this is the costliest of all and risky too.

Where is browser compatibility testing performed?

Usually, the answer to this question would be one of- Dev/QA/Production environments. But for cross-browser checking, this is not a definite and irrelevant (if I may say so). It can be done in any one or all of them.

Conclusion

A few points to note, 

  • Having been a QA teacher for a while now, I can tell what’s coming next and that is –the question, is it functional and non-functional testing? I think it is neither and both.
  • It also should not be confused with Cross-Platform testing, which is testing your application in multiple target environments like Windows, Linux, Mac etc. Although sometimes the two must integrate as some of the older browser versions might be compatible only with the older versions of the platforms.
  • It is also a continues to process as software environments, browsers and devices are evolving every day and to make sure there are no unpleasant surprises, this browser Testing should be added to the repertoire of regression suites.

As you know, each type of testing helps in improving the quality of the application and so does the cross-browser test too.

Cross-browser testing helps in creating a good impression on the users by providing them a consistent experience throughout the application irrespective of the browser or Operating system.

Fixing bugs is cost-effective during the early stages of the development lifecycle, and the same applies to the defects found as a part of this testing too.

This testing helps in improving your business which in turn results in Happy Customers, Happy You!!

This is yet another testament to the concept that QA field or software testing is a multi-dimensional field and there is something for everyone to excel in.

Benefits of Automation Testing

Thursday, June 4th, 2020

Test automation can bring many benefits to your testing cycles, allowing you to test better with less effort. It is less time consuming as well! Many companies still run only manual tests because they don’t know how to properly integrate automated testing in their development process.

Automated testing means that a machine does, what a human used to do, quicker, with less errors, 24/7. Does it sound familiar?

Then, machines started to take over all the repetitive and boring tasks. Humans quickly tend to lose concentration with that kind of work or to overlook things that weren’t right. Machines are more reliable and faster in this.There’s also an obvious big starting investment when introducing change, especially this kind of change. Usually the smaller companies are afraid that the returns won’t be as expected or if there will be a ROI at all.

Back then people needed this kind of automation to produce the exact same parts that match perfectly with other parts so that the assembly could be done in less time and thus enhancing the production.

Well, let’s have a closer look at the top benefits of automated testing.

Benefits of Automation Testing

1. Return on Investment

Let’s start from the beginning: the big initial investment. This may be a hold back for many, but it is proven that the return of that investment is a long-term one and it will also save time.

ROI – benefits of automated testing

2. Early Bug Detection: 

Unlike manual testing, bugs can be detected early during the development phase in an automated testing which saves a lot of time during lifecycle for both developers and testers.

Automation helps you find bugs in the early stages of software development, reducing expenses and working hours to fix these problems as well.

3. Running Tests Anytime, Anywhere:

No matter where you are in the world. You can start the tests when you leave the office and when you get back in the morning you can see the results and keep on working. You can even do that remotely if you don’t have a lot of devices or you don’t have the money to buy it.

4. Fewer Human Resources:

You don’t need a lot of people: you would need a test automation engineer to write your scripts to automate your tests, instead of a lot of people doing boring manual tests repeatedly.

5. Reusability of Scripts:

The scripts are reusable:

You don’t need new scripts all the time, even if the version of the OS on the device changes

It allows you to redo the test the same, without forgetting any steps

6. Testing Capabilities:

Automation testing offers an unmatched and huge testing capability. The mobile app needs to be tested on multiple devices, OS versions, screen sizes etc. which can be efficiently done through automated testing and not by manual testing. In fact, it is almost impossible to get perfect results through manual testing.

7. Reliability:

Automated testing is more reliable and way quicker when running boring repetitive standardized tests which cannot be skipped, ever, but may cause errors when manually tested.

8. Improves Accuracy:

We have been saying this time and again that automation testing overcomes the shortcomings of manual testing. It has improved the accuracy to a great deal by giving error-free results unlike manual testing where testing is error-prone, delays the delivery and increases the cost. It is especially a boon in stress testing where getting error free results in manual testing is almost impossible.

9. Simultaneously:

You can test more devices simultaneously resulting in comparative detailed reports generated in less time with the exact the same parameters, because the exact same scripts were run.

10. Better Test Coverage:

Test automation can easily execute thousands of different complex test cases during every test run providing coverage that is impossible with manual tests. It can only be possible through automated testing as it can run test scripts on multiple computers with varied configurations. It can look inside an application and see memory contents, data tables, file contents, and internal program states to determine if the app is functioning as expected.

11. Continuity:

Automated testing helps testers, such as automation engineers. They can see exactly what other engineers have done, what scripts he has already written and what tests have already been performed and what bugs were already found and fixed, through clear reports.

12. Additional methods:

One of these methods is the stress test in which the capacities of the application and operational infrastructure will be tested to its limits with stress test, which can’t be done manually.

13. Volume:

You can run your tests on more than 500 devices in automation testing which is impossible in manual testing. Testing all of them manually would be impossible!

14. Information Security:

The effectiveness of testing will be largely dependent on the quality of the test data you use. Manually creating quality test data takes time and as a result testing is often performed on copies of live databases. Automation solutions can help with creating, manipulating and protecting your test database, allowing you to re-use your data time and again. The time and cost savings in this area are potentially huge.

Conclusion

Automation testing not only helps in saving time and improving accuracy, it does value addition to all the stakeholders involved in the app development lifecycle. Although testing automation offers such huge benefits, but many organizations have not adopted it in its entirety because of its initial cost associated with its configuration. With Agile testing and DevOps methodologies being widely followed in the IT industry, it is advisable to automate your testing

processes completely with renowned automated testing tools to get the best results.

In conclusion there are benefits and drawbacks to both automated and manual testing. This article had the purpose to show how automated testing can help you to make your testing more efficient.

To achieve the best results, you will need a combination of both types: automated testing for repetitive, simple use-cases; and manual testing for reproducing specific bugs, complicated use cases and to ensure the best user experience possible.

Unit Testing React, D3 with Enzyme and Jest

Friday, January 24th, 2020

Introduction: — This blog is for how to test React component with Enzyme and Jest. In this blog, here we are discussing how to test react components which have d3 content with the help of Enzyme and Jest. This blog helps you to write test cases and also help you to choose the correct testing framework according to your requirement.

In this blog, I am going to cover some of the testing frameworks which are showing below.

  1. Jest
  2. Jasmine
  3. Enzyme

Jest

Jest is an open-source test framework created by Facebook that has great integration with React.js. It is a very powerful testing framework. The most known feature of jest is the snapshot. It is very helpful for testing.

Features of Jest:-

  1. Zero Configuration
  2. Fast and sandboxed
  3. Extensible Framework
  4. Codemods
  5. Snapshot

To know more about please go through with the below mention link:-

https://jestjs.io/docs/en/getting-started

Jasmine

Jasmine is one of the popular JavaScript unit testing frameworks which is capable of testing synchronous and asynchronous JavaScript code. It is used in BDD (behavior-driven development) programming which focuses more on the business value than on the technical details.

Features of Jasmine:-

  1. Jasmine does not depend on any other JavaScript framework.
  2. Jasmine does not require any DOM.
  3. All the syntax used in Jasmine framework is clean and obvious.
  4. Jasmine is heavily influenced by Rspec, JS Spec, and Jspec.
  5. Jasmine is an open-source framework and easily available in different versions like the stand-alone, ruby gem, Node.js, etc.

Suite Block:- Jasmine is a testing framework for JavaScript. A suite is the basic building block of Jasmine framework. The collection of similar type test cases written for a specific file or function is known as one suite. It contains two other blocks, one is “Describe()” and another one is “It()”.

One Suite block can have only two parameters, one “name of that suite” and another “Function declaration” that actually makes a call to our unit functionality that is to be tested.

Example:-

describe(“Hello World”, function () {it(“should Return Hello world”, function () {expect(HelloWorld()).toEqual(‘Hello World’);});});

Skip Block:- Jasmine also allows the developers to skip one or more than one test cases. These techniques can be applied at the Spec level or the Suite level. Depending on the level of application, this block can be called as a Skipping Spec and Skipping Suite respectively .we will skip a specific Spec or Suite using “x” character.

Example:-

describe(“Hello World”, function () {xit(“should Return Hello world”, function () {expect(HelloWorld()).toEqual(‘Hello World’);});});

Before And After Functions:- There are few before and after functions that are supported by jasmine.

  1. BeforeAll
  2. BeforeEach
  3. AfterAll
  4. AfterEach

BeforeAll:- Runs a function before any of the tests in this file run. If the function returns a promise or is a generator, Jest waits for that promise to resolve before running tests.

Optionally, you can provide a timeout (in milliseconds) for specifying how long to wait before aborting. Note: The default timeout is 5 seconds.

Example :-

beforeAll((done) => {
 document.body.appendChild(element);
 barGraph = ReactDOM.render(
 <BarGraph
 configuration={config.verticalNumber}
 data={config.data}
 />,
 element
 )
 setTimeout(() => {
 done();
 }, 1000);
 });

BeforeEach:- Runs a function before each of the tests in this file runs. If the function returns a promise or is a generator, Jest waits for that promise to resolve before running the test.

Optionally, you can provide a timeout (in milliseconds) for specifying how long to wait before aborting.

Example :-

beforeEach( async () => {
 if(global.ZFB_DOWNLOAD_INSTANCE) {
 await clickByIdAfterWait(global.ZFB_DOWNLOAD_INSTANCE);
 }
 });

AfterAll:- Runs a function after all the tests in this file have completed. If the function returns a promise or is a generator, Jest waits for that promise to resolve before continuing.

Optionally, you can provide a timeout (in milliseconds) for specifying how long to wait before aborting.

Example :-

afterAll(‘do logout’, async () => { 
 await clickByIdAfterWait(‘logout’);
 });

AfterEach:- Runs a function after each one of the tests in this file completes. If the function returns a promise or is a generator, Jest waits for that promise to resolve before continuing.

Optionally, you can provide a timeout (in milliseconds) for specifying how long to wait before aborting.

Example:-

afterEach( async () => {
 await wait(300);
 await clickByIdAfterWait(‘editor-button-policygroups’);
 await wait(300);
 await selectEntities(vportPG, entity, [global.PG_INSTANCE_ID_2]);
 });

Spies:- Jasmine spy is another functionality that does the exact same as its name specifies. It will allow you to spy on your application function calls. There are two types of spying technology available in Jasmine. The first methodology can be implemented by using spyOn() and the second methodology can be implemented using createSpy().

Example :-

spyOn(self.mockService, ‘fetch’).and.callThrough();VSDServiceTest.makeRequest = jasmine.createSpy(“makeRequest”).and.callFake(() => {
 return new Promise((resolve, reject) => {
 return resolve(‘Done’);
 })
 });

Enzyme

The enzyme is a JavaScript Testing utility for React that makes it easier to assert, manipulate, and traverse your React Components’ output.

Enzyme’s API is meant to be intuitive and flexible by mimicking jQuery’s API for DOM manipulation and traversal.

Before Installing enzyme please keep these below key points

  1. If you are using react 16.X than you need to install enzyme-adapter-react-16 and enzyme 3.X
  2. If you are using react 15.X than you need to install enzyme-adapter-react-15 and enzyme 2.X

Running Enzyme Tests:- Enzyme is un-opinionated regarding which test runner or assertion library you use, and should be compatible with all major test runners and assertion libraries out there. The documentation and examples for enzyme use mocha and chai, but you should be able to extrapolate to your framework of choice. If you are interested in using enzyme with custom assertions and convenience functions for testing your React components, you can consider using:

This is some overview of the testing framework. Now the time for the main topic.

Testing React and D3 content with the enzyme

It is very difficult to test d3 content with react because enzyme or any other testing framework only render the render method of React. When I was looking for the solution to this problem. I read many of the documents some are supporting d3 testing with jasmine without React and some documents are for jest and with enzyme for React component testing. For testing both react and d3 together I have found one approach. I have rendered the dom with the enzyme but in the enzyme rendering, I am not able to fetch the d3 content. To fetch the d3 content I have used .html() method which provides the HTML of the current component. I have found the HTML but now the question is how to manipulate the HTML and how to test both d3 and React content. After a lot of searches, I found one manipulating library which is Cheerio. It is just like the jquery library. With the help of this, I am able to test together d3 and React. This summary of how I have test React and d3 together. Now I am going to talk in detail how everything works for me.

Issues:- To test React and d3 together it is very complicated. I have faced many issues while testing d3 and React together some of the important issues I am covering here.

  1. The main issue is that d3 content is not rendering with Enzyme.
  2. Find the d3 content with .html() now the problem how to manipulate that html().
  3. The transition is used in the d3.
  4. How to perform click event
  5. How to call React lifecycle methods.

These are some major challenges that I have faced while I am testing the react and d3 together with enzyme and jest.

Solutions

The main issue is that d3 content is not rendering with Enzyme.

Solution:- To render content I have use Enzyme mount method. Mount is used for full dom rendering. In my case, there is one problem which is the d3 content because we are using d3 content with the react content. I am using Enzyme mount with the help of the mount() method I am able to get the React component but I am not able to get the d3 content because the d3 content is mount with the render after the react mounting is done. After a lot of searching, I have found one solution to this problem. I have first got the HTML of the mounted dom and i am able to get complete HTML of the dom.

Example : –

import PieGraph from ‘./index’;
import React from ‘react’;
import { mount } from ‘enzyme’;describe(“PieGrpah”, () => {
 let config;
 beforeAll(async () => {
 config = await getDataAndConfig(‘PieGraph’);
 });it(“OtherOption by Number”, () => {
 const pieGraph = mount(
 <PieGraph
 width={500}
 height={500}
 configuration={config.withoutOtherOption}
 data={config.data}>
 </PieGraph>
 );
 const html = pieGraph.find(‘svg’).html();
 });
 });

With the help of .html() method, I am able to get the d3 content but Now I have another problem that is shown below.

Find the d3 content with .html() now the problem how to manipulate that HTML.

Solution:- Now the problem is how to manipulate the HTML component to resolve the problem i have found one library that is Cheerio. The Cheerio is used for manipulating the HTML data. Cheerio is mainly used for manipulating the HTML content. It provides many cool methods. The Cheerio parses markup and provides an API for traversing/manipulating the resulting data structure.

To know more about cheerio please go through the below link.

https://www.npmjs.com/package/cheerio

Example:-

pieGraph.test.jsimport PieGraph from ‘./index’;
import React from ‘react’;
import { mount } from ‘enzyme’;
import { getDataAndConfig, getHtml, checkSvg } from ‘./helper’;describe(“PieGrpah”, () => {
 let config;
 beforeAll(async () => {
 config = await getDataAndConfig(‘PieGraph’);
 });describe(“OtherOption by Percentage”, () => {
 let pieGraph, $;
 beforeAll(async () => {
 pieGraph = mount(
 <PieGraph
 width={500}
 height={500}
 configuration={config.percentage}
 data={config.data}>
 </PieGraph>
 );
 $ = getHtml(pieGraph, ‘svg’);
 });it(“SVG Dimensions”, () => {
 const result = checkSvg(pieGraph);
 expect(result).toBeTruthy();
 });
 });
});Helper.jsconst cheerio = require(‘cheerio’);export const checkSvg = (component) => {
 const $ = getHtml(component, ‘svg’);
 const svgHeight = $(‘svg’).attr(‘height’);
 const svgWidth = $(‘svg’).attr(‘width’);
 return svgHeight == “500” && svgWidth == “500”;
}export const getHtml = (component, tag) => {
 const cheerioData = cheerio.load(component.find(tag).html());
 return cheerioData;
}

With help of cheerio, I was able to test most of the graph and also able to cover most of the cases but when I was testing the bar graph I was not able to get the HTML. After digging a lot, I was able to get to know what is the problem. The problem is mention below.

The transition is used in the d3.

Solution:- In some cases, they were using d3 transition for animation. Now the problem was that the d3 content was not ready at the time of mounting the component. So d3 content is not available into the HTML. This is a big problem to solve this problem I have used setTimeout. In the timeout section, I have updated the component. After updating the component I am able to solve this problem. I am able to get d3 content.

Example: –

barGraph.test.jsimport BarGraph from ‘./index’;
import React from ‘react’;
import { mount } from ‘enzyme’;
import { getDataAndConfig, getHtml, checkSvg } from ‘./helper’;describe(“Bar Graph”, () => {
 let config;
 beforeAll(async () => {
 config = await getDataAndConfig(‘DynamicBarGraph’);
 });
 describe(“Graph with Brush”, () => {
 let horizontalBrush, $;
 beforeAll(async (done) => {
 horizontalBrush = mount(
 <BarGraph
 width={500}
 height={500}
 configuration={config.horizontalBrush}
 data={config.data}>
 </BarGraph>
 );
 /* Delayed added because the bar is rendered with 300ms animation */
 setTimeout(() => {
 horizontalBrush.update();
 done();
 }, 350);
 });it(“SVG Dimensions”, () => {
 const result = checkSvg(horizontalBrush);
 expect(result).toBeTruthy();
 });});
});Helper.jsconst cheerio = require(‘cheerio’);export const checkSvg = (component) => {
 const $ = getHtml(component, ‘svg’);
 const svgHeight = $(‘svg’).attr(‘height’);
 const svgWidth = $(‘svg’).attr(‘width’);
 return svgHeight == “500” && svgWidth == “500”;
}export const getHtml = (component, tag) => {
 const cheerioData = cheerio.load(component.find(tag).html());
 return cheerioData;
}

How to perform click event.

Solution:- This is the most complicated problem for me because with the help of cheerio I am able to manipulate the HTML but cheerio is not provided the click event functionality. This is a blocker for me without this testing is incomplete. I had searched a lot then I found a solution. To checking the clickEvent I had use react-dom render. With the help of react-dom render I am able to test the click event. I had also used jest mock function for this.

Example:-

import React from ‘react’;
import { mount } from ‘enzyme’;
import ReactDOM from ‘react-dom’;
import PieGraph from ‘.’;describe(“PieGrpah”, () => {
 let config;
 beforeAll(async () => {
 config = await getDataAndConfig(‘PieGraph’);
 });
 describe(“Click Event”, () => {
 let pieGraph;
 const mockCallBack = jest.fn();
 const element = document.createElement(“div”);
 beforeAll((done) => {
 document.body.appendChild(element);
 pieGraph = ReactDOM.render(
 <PieGraph
 width={500}
 height={500}
 configuration={config.withoutOtherOption}
 data={config.data}
 onMarkClick={mockCallBack}
 />,
 element
 )
 setTimeout(() => {
 done();
 }, 1000);
 });afterAll(() => {
 document.body.removeChild(element);
 });it(“Click On PieGraph”, () => {
 element.querySelector(‘path’).click();
 expect(mockCallBack).toHaveBeenCalled();
 });
 });
});

How to call React lifecycle methods.

Solution:- we all already know that React has some lifecycle methods. All the lifecycle methods have some unique functionality and execution time. Some have been called after mounting and some are called before mounting. In the gauge graph, an animation is applied to the needle. All the work is performing into the componentDidmount method. It is very difficult to find the angel of the needle and the percentage because both things are performing into the componentDidmount method. After searching a lot I have found one solution. I have tested this thing with the help of react-dom-render. With the help of this, I am able to get all the content like needle angle and percentage.

Example:-

import React from ‘react’;
import ReactDOM from ‘react-dom’;import { getDataAndConfig } from ‘../testHelper’;
import GaugeGraph from ‘.’;const cheerio = require(‘cheerio’);describe(“GaugeGraph”, () => {
 let config;
 beforeAll(async () => {
 config = await getDataAndConfig(‘GaugeGraph’);
 });describe(“Initial Configurations”, () => {
 let gaugeGraph, $;
 const element = document.createElement(“div”);
 beforeAll((done) => {
 document.body.appendChild(element);
 gaugeGraph = ReactDOM.render(
 <GaugeGraph
 width={500}
 height={500}
 configuration={config.configuration}
 data={config.data}
 />,
 element
 )
 setTimeout(() => {
 done();
 $ = cheerio.load(element.innerHTML);
 }, 3000);
 });afterAll(() => {
 document.body.removeChild(element);
 });it(“SVG Dimensions”, () => {
 const height = $(‘svg’).attr(‘height’);
 const width = $(‘svg’).attr(‘width’);
 expect(height).toEqual(“500”);
 expect(width).toEqual(“500”);
 });
 });
});

API Testing and How to do it?

Thursday, January 23rd, 2020

Introduction

Before getting into what API testing is, it is essential to understand what an API is. An API (Application Programming Interface) indicates how two software programs should integrate with one another.

API (Application programming interfaces) testing is a kind of software testing that involves testing APIs directly and as part of integration testing and to determine if they meet the requirements of functionality, performance, security, and reliability. API testing is a form of Black Box testing and is conducted after the build is ready. The source code is not included here.

The Challenge

To test the APIs and the integrations, they enable a software system.

The solution

To perform API testing, a tool is required to structure and manage the test cases. Another requirement is full traceability of requirements and effective API documentation.

During API testing, certain bugs can be found. These bugs include:

  • Duplicate or missing functionality
  • Incompatibility of the error handling mechanism
  • Reliability issues
  • Security and performance issues
  • Improper messaging
  • Multi-threaded issues

The quality assurance team performs API testing. The testing is conducted after the build is ready. The source code will not be included here.

A request is sent to the API to analyze responses that include:

  • Accuracy of data
  • HTTP status code
  • Error codes of any errors that are returned by API
  • Results of non-functional tests like security and performance
  • Response time
  • Authorization checks

Use a test management tool that will help in API testing by letting you structure and categorize your test cases. The tool should also give you full requirements traceability along with high-level API documentation. During API testing, the following must be kept in mind:

  • The API must be tested to check what happens and what does not happen on a consistent basis.
  • Stress testing on the system must be performed through several API load tests.
  • The API must be tested for failures. Test the API consistently so that it fails consistently.
  • Group all the test cases by category.
  • Mention all the parameters that are selected in the test case.
  • Prioritize API function calls so that testing can be simplified and can be finished on time.
  • Make plans to perform call sequencing.
  • Create test cases for different and all API input combinations that are possible. This way, you can ensure that you get complete test coverage.
  • Reuse the test cases and also monitor the API when in production.
  • It depends on the manual and automated tests if you want better API testing outcomes.

API testing is a very important part of software quality assurance. With the right approach and the right tools, you can ensure it is carried out successfully. The more API testing is structured, the better will be the outcomes of the testing.

Key Insights into the Future of Software Testing — 2020 Vision

Thursday, January 23rd, 2020

With the growth of digital technology and the widespread use it has in our daily lives, the need for reliable and efficient software testing has also increased. Developers need to ensure product quality after an app design agency works on it and before it is rolled out into the market. As such, it is not an exaggeration to say that software testing determines the fate of a product.

Considering the huge role that software testing plays in the success of an app, it is important to know where the industry is headed to in the coming years. Such insights help us understand how better to improve the products that are put out most efficiently.

Before learning about future insights read another article about software testing from the link:- https://medium.com/@successivetech/getting-started-with-testing-react-component-e9e811856f3c

Below, we take a closer look at four main insights that are predicted to dominate the software testing industry in 2020:

Testing both the API layer and UI layer are equally important

Most professionals who are involved in software testing, such as developers, project managers, manual testers, and so on, test both the front and back-end of applications. This indicates that today, testing the API layer is equally important as testing the UI layer. Since testers are tasked with testing multiple layers of software, they must be equipped with the necessary tools so that they can test with ease. In the coming years, more testers will likely focus on both API and UPI layers.

Machine learning-enabled automated testing is the future

By 2020, the number of testers automating more than half of their API tests is expected to grow significantly. This means that automated testing will soon be the norm in the near future. Machine learning has already heavily impacted the way software is developed, and its impact on software testing is also expected to grow. For instance, machine learning can be used to optimize the test suite to search for excessive, or it can be used to predict the main test configurations based on previous checks.

Teams are working on shortening release cycles

Even though teams are not as agile as they wish to be, this trend is likely to change as they are continuously working on deploying more regularly. A huge number of software testers are expected to release either daily or weekly in the coming years, thus shortening their release cycles.

More focus on user experience

High-quality UX has grown to become one of the most important determinants of success for products in the world of software today. Regardless of whether the product is aimed at a simple user or for an experienced software developer, being user-friendly is a crucial key. This is exactly why testing user experience has become such a critical part of software testing, and the need for the best UI/UX design services is growing. This trend is expected to grow in the coming years.

Getting Started with Testing React Component

Thursday, January 23rd, 2020

Introduction and background

ReactJs is a very popular open-source JavaScript library that is used for front-end development. It is extremely flexible and user-friendly, which makes it easy for developers to play around with state and props in React Components. This, in turn, helps to make the app more attractive and interactive.

React is maintained by Facebook, along with a worldwide community of companies and individual developers. It is great for fetching data that changes rapidly and which needs to be recorded and is therefore used as a base in the development of mobile apps and single-page applications.

In simple words, React allows developers to create web applications that are capable of changing data without having to reload the page. The main advantages that React offers include ease of use, simplicity, and scalability. It is also very fast, making it highly efficient.

Challenge

When developers work on a React app, they often play with state and props to make their apps more interactive and appealing. During development, everything may seem to work fine, but in many cases, the app faces issues once it is rolled out into the market when it is used by real people in the real world. This is because, oftentimes, some of the use cases of the app fail.

When you develop a web application, and you don’t run any test, it means that the beta testers will be the users in the real world, which is extremely risky. Besides, if your app fails, you cannot blame others for not trusting an untested code.

Unit testing of apps is required for the following reasons –

  • To ensure that each part of the program is correct individually.
  • To check out input validation logic and data transformation.
  • To check any isolated operation.
  • It helps in writing a test-driven approach.
  • Make sure the right things render when they are meant to.

Solution

To carry out efficient and reliable unit testing, Jest and Enzyme are required. Jest is a JavaScript testing framework that is developed by Facebook, with its main advantage being that it is very easy to use while being fast and safe. Code coverage, great expectations, snapshots, and easy mocking are other benefits. Create React App is then shipped with a ready-to-use Jest setup.

The Enzyme is a JavaScript testing utility for React, which can be used for easily asserting, manipulating, and traversing the output of your React Component. It was created by Airbnb and is quite popular since it adds several additional utility methods that are used for rendering a component(s), as well as finding and interacting with elements.

So, Jest is used as the test runner, assertion library, and mocking library, while Enzyme is used to provide additional testing utilities to interact with elements.

Recent Posts

Recent Comments

Get In Touch

Ask Us Anything !

Do you have experience in building apps and software?

What technologies do you use to develop apps and software?

How do you guys handle off-shore projects?

What about post delivery support?