DESC:DESCRIPTION Technical Field [001] This disclosure relates generally to device testing, and more particularly to method and system for remote testing of a plurality of devices, for example, Android devices. BACKGROUND [002] Test automation frameworks are available that integrate various test components based on unique device and platform configurations, and provide results powered by internal validation algorithms. For example, devices under test may include mobile phones, personal computers (i.e. laptops, desktops, etc.), smartwatches, etc. Further, by way of an example, the devices may be Android-based or iOS-based. However, in scenarios when direct access to the devices is not available, these available test automation frameworks tend to lose their utility. [003] Some remote testing solutions are available that are based on remote desktop techniques and provide for remotely running automation test cases on remote devices. However, the remote testing techniques are slow and inefficient. For example, remote testing using these remote desktop-based techniques may take twice or thrice the time as compared to performing testing otherwise. [004] There is, therefore, a need for efficient and effective remote testing solutions for testing a plurality of devices simultaneously. SUMMARY OF THE INVENTION [005] In one embodiment, a method of testing a plurality of remote devices is disclosed. The method may include receiving a request from a client system to perform testing on a set of remote devices of a plurality of remote devices. The local system and the client system may be connected via a first network connection. The local system may be configured to obtain and store an identity of each of the plurality of remote devices. The plurality of remote devices may be connected to the local system via a second network connection. The method may further include receiving an input from the client system with reference to a test-suite to perform a testing action on the set of remote devices. The test-suite may be uploaded from the client system to the local system. The method may further include generating a test command corresponding to the input to perform the testing action on the set of remote devices and transmitting the test command to each of the set of remote devices. Each of the set of remote devices is to perform the testing action based on the test command. The method may further include receiving a feedback from each of the set of remote devices and transmitting the feedback to the client system. [006] In another embodiment, a system for testing a plurality of remote devices is disclosed. The system may include a processor and a memory coupled to the processor. The memory is configured to store a plurality of processor-executable instructions which, upon execution by the processor, may cause the processor to receive a request from a client system to perform testing on a set of remote device of a plurality of remote devices. The system and the client system may be connected via a first network connection. The system may be configured to obtain and store an identity of each of the plurality of remote devices. The plurality of remote devices may be connected to the system via a second network connection. The plurality of processor-executable instructions may further cause the processor to receive an input from the client system with reference to a test-suite to perform a testing action on the set of remote devices. The test-suite may be uploaded from the client system to the system. The plurality of processor-executable instructions may further cause the processor to generate a test command corresponding to the input to perform the testing action on the set of remote devices and transmit the test command to each of the set of remote devices. Each of the set of remote devices is to perform the testing action based on the test command. The plurality of processor-executable instructions may further cause the processor to receive a feedback from each of the set of remote devices and transmitting the feedback to the client system. BRIEF DESCRIPTION OF THE DRAWINGS [007] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles. [008] FIG. 1 illustrates a block diagram of an environment for testing of a plurality of remote devices, in accordance with some embodiments of the present disclosure; [009] FIG. 2 illustrates a functional block diagram of a client system, in accordance with some embodiments of the present disclosure. [010] FIG. 3 illustrates a functional block diagram of a local system, in accordance with some embodiments of the present disclosure; [011] FIG. 4 illustrates a flowchart of a method of testing a plurality of remote devices, in accordance with some embodiments of the present disclosure; and [012] FIGs. 5A-5C illustrate snapshots of test reports generated upon testing of the remote devices, in accordance with some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE DRAWINGS [013] Exemplary embodiments are described with reference to the accompanying drawings. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the spirit and scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope and spirit being indicated by the following claims. Additional illustrative embodiments are listed. [014] One or more techniques for testing a plurality of remote devices are disclosed. The techniques provide for running automation test cases (i.e. test suites) on remote devices (for example, Android devices) despite the devices being on different networks. The automation test cases may be run from a client system which may be connected to a local system over an Internet connection, via tunneling. The local system may further be connected to the remote devices which are to be tested via a separate network like a USB network or wireless network. Users (i.e. using the client system) can choose any number of remote devices from the list of remote devices connected to the local system for testing. The techniques enable the users to run a test-suite from a browser installed on the client system and view live streaming of the display screens of the remote devices on the client system, while the test execution is in process. The techniques, therefore, provide access to witness the entire test execution in real-time. As such, the techniques provide freedom to create an independent Android device cloud and making it accessible for testing. Further, the techniques provide for generation of test reports based on the test execution that are then made available for downloading at the client system. Moreover, the test reports can also be made publicly available by assigning an IP address and a URL to the test reports, thereby making the test reports shareable and viewable by multiple users who may be distributed across different locations. [015] Referring now to FIG. 1, a block diagram of an environment 100 for testing of a plurality of remote devices is illustrated, in accordance with an embodiment of the present disclosure. As shown in FIG. 1, the environment 100 may include a client system 102, a local system 104, and a plurality of remote devices 106A, 106B, … 106N (hereinafter, collectively, referred to as plurality of remote devices 106). [016] The client system 102 may be a computing device, like a desktop, a laptop, a smartphone, a server, etc. The client system 102 may be configured to connect with the local system 104 over a first network connection 108. The first network connection 108 may be an Internet-based connection. Further, the plurality of remote devices 106 may be connected to the local system 104 over a second network connection 110. In some embodiments, the second network connection 110 may be a Universal Serial Bus (USB) network connection. As such, the local machine 104 may include a plurality of USB ports into which the plurality of remote devices 106 may be plugged in using USB compatible data cables. Alternately, the second network connection 110 may be a wireless network connection. For example, the wireless network may be a Wi-Fi-based network. To this end, the local machine 104 and the each of the plurality of remote devices 106 may have Wi-Fi capability. [017] The client system 102 may be configured to perform one or more functionalities, which may include sending a request to the local system 104 to perform testing on the set of remote device of a plurality of remote devices 106. To this end, the one or more functionalities may further include providing to the local device 104 a selection of identities of the set of remote devices from the plurality of remote devices 106 for performing testing on the set of remote devices. The one or more functionalities may further include receiving an input from a user and forwarding the input to local device 104. The input may be in reference to a test-suite to perform a testing action on the set of remote devices. As such, the one or more functionalities performed by the client system 102 may further include uploading the test-suite to the local system 104. In some embodiments, the one or more functionalities performed by the client system 102 may further include generating a test report corresponding to the remote testing of the set of devices. Further, the one or more functionalities may include displaying the test report via an input/output device. The test report may be downloaded at the client system 102. [018] In order to perform the above-discussed functionalities, the client system 102 may include a processor 102A, a memory 102B, and an input/output device 102C. The processor 102A may include suitable logic, circuitry, interfaces, and/or code that may be configured to perform testing of the plurality of remote devices 106. The processor 102A may be implemented based on temporal and spatial processor technologies, which may be known to one ordinarily skilled in the art. Examples of implementations of the processor 102A may be a Graphics Processing Unit (GPU), a Reduced Instruction Set Computing (RISC) processor, an Application-Specific Integrated Circuit (ASIC) processor, a Complex Instruction Set Computing (CISC) processor, a microcontroller, Artificial Intelligence (AI) accelerator chips, a co-processor, a central processing unit (CPU), and/or a combination thereof. [019] The memory 102B may include suitable logic, circuitry, and/or interfaces that may be configured to store instructions executable by the processor 102A. The memory 102B may store instructions that, when executed by the processor 102A, may cause the processor 102A to perform remote testing of the plurality of devices 106. The memory 102B may be a non-volatile memory or a volatile memory. Examples of non-volatile memory may include, but are not limited to a flash memory, a Read-Only Memory (ROM), a Programmable ROM (PROM), Erasable PROM (EPROM), and Electrically EPROM (EEPROM) memory. Examples of volatile memory may include but are not limited to Dynamic Random-Access Memory (DRAM), and Static Random-Access memory (SRAM). The memory 102B may also store various data that may be captured, processed, and/or required by the system. [020] The client system 102 may further include the input/output device 102C. In some embodiments, the input/output device 102C may further include a display and a user interface. By way of an example, the user interface may include a touchscreen, a keyboard, etc. to receive user inputs. For example, the user input may include selection of identities of one or remote devices (i.e. the set of remote devices) from the plurality of remote devices 106. Further, the display may include a display screen which is capable of displaying the identities of the plurality of remote devices 106, and further display the test report representing the test results of the set of remote devices. [021] The local system 104 may be a computing device, like a desktop, a laptop, a smartphone, a server, etc. The local system 104 may be configured to perform one or more functionalities, which may include receiving a request from the client system 102 to perform testing on a set of remote devices of a plurality of remote devices 106. As mentioned above, the local system 104 and client system 102 may be connected via the first network connection 108. The local system 104 may be configured to obtain and store an identity of each of the plurality of remote devices 106. The plurality of remote devices 106 may be connected to the local system 104 via the second network connection 110. The one or more functionalities may further include receiving an input from the client system 102 with reference to a test-suite to perform a testing action on the set of remote devices. The test-suite may be uploaded from the client system 102 to the local system 104. The one or more functionalities may further include generating a test command corresponding to the input to perform the testing action on the set of remote devices and transmitting the test command to each of the set of remote devices. Each of the set of remote devices may perform the testing action based on the test command. The one or more functionalities may further include receiving a feedback from each of the set of remote devices and transmitting the feedback to the client system 102. [022] In order to perform the above-discussed functionalities, the local system 104 may include a processor 104A and a memory 104B. The processor 104A may include suitable logic, circuitry, interfaces, and/or code that may be configured to perform testing of the plurality of remote devices 106. The processor 104A may be implemented based on temporal and spatial processor technologies, which may be known to one ordinarily skilled in the art. Examples of implementations of the processor 104A may be a Graphics Processing Unit (GPU), a Reduced Instruction Set Computing (RISC) processor, an Application-Specific Integrated Circuit (ASIC) processor, a Complex Instruction Set Computing (CISC) processor, a microcontroller, Artificial Intelligence (AI) accelerator chips, a co-processor, a central processing unit (CPU), and/or a combination thereof. [023] The memory 104B may include suitable logic, circuitry, and/or interfaces that may be configured to store instructions executable by the processor 104A. The memory 104B may store instructions that, when executed by the processor 104A, may cause the processor 104A to perform testing of the plurality of remote devices 106. The memory 104B may be a non-volatile memory or a volatile memory. Examples of non-volatile memory may include, but are not limited to a flash memory, a Read-Only Memory (ROM), a Programmable ROM (PROM), Erasable PROM (EPROM), and Electrically EPROM (EEPROM) memory. Examples of volatile memory may include but are not limited to Dynamic Random-Access Memory (DRAM), and Static Random-Access memory (SRAM). The memory 104B may also store various data that may be captured, processed, and/or required by the system. [024] The first communication network 108 may include a communication medium through which the local system 104 and the client system 102 may communicate with each other. Examples of the first communication network 108 may include, but are not limited to, the Internet, a cloud network, a Wireless Fidelity (Wi-Fi) network, a Personal Area Network (PAN), a Local Area Network (LAN), or a Metropolitan Area Network (MAN). Various devices in the environment 100 may be configured to connect to the first communication network 108, in accordance with various wired and wireless communication protocols. Examples of such wired and wireless communication protocols may include, but are not limited to, a Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), Zig Bee, EDGE, IEEE 802.11, light fidelity(Li-Fi), 802.16, IEEE 802.11s, IEEE 802.11g, multi-hop communication, wireless access point (AP), device to device communication, and cellular communication protocols. [025] Referring now to FIG. 2, a functional block diagram 200 of the client system 102 is illustrated, in accordance with some embodiments of the present disclosure. The client system 102 may include one or more modules configured to perform one or more functionalities as discussed above. By way of an example, the one or more modules may include a test requesting module 202, a selection requesting module 204, an input module 206, a test report generating module, and a display module 210. It should be noted that the functionalities of the above modules may be performed individually by each module, or alternately the functionalities of multiple modules may be combined in a single module. [026] The test requesting module 202 may receive a request from a user to perform testing of the set of remote devices. To this end, the client system 102 may include the input/output device 102C which may provide an interface for allowing a user to make such a request. [027] The selection requesting module 204 may be configured to receive a selection of one or more remote devices to create the set of remote devices which are to be tested. The user may provide the selection of identities of the set of remote devices which are to be tested. The selection requesting module 204 may, therefore, in coordination with the user interface of the input/output device 102C, may allow the user to provide selection of the set of remote devices from the plurality of remote devices 106. [028] The input module 206 may receive an input from the user to perform the testing action on the set of remote devices. It should be noted, in some embodiments, the input may be received with reference to a test-suite to perform a testing action on the set of remote devices. The test-suite may be uploaded from the client system 102 to the local system 104. [029] The test report generating module 208 may generate a test report corresponding to the remote testing of the set of devices upon completion of the remote testing. In some embodiments, the display module 210 may function in coordination with the input/output device 102C to display the test report generated by the test report generating module 208. For example, the test report may be displayed using the display screen of the input/output device 102C. Further, the test report generating module 208 may provide for downloading the test report at the client system 102. Alternately, in some embodiments, the test report may be assigned a public IP address so that the test report can be accessed from any remote location. [030] Referring now to FIG. 3, a functional block diagram 300 of the local system 104 is illustrated, in accordance with some embodiments of the present disclosure. The local system 104 may include one or more modules configured to perform one or more functionalities as discussed above. By way of an example, the one or more modules may include a request receiving module 302, an input receiving module 304, a test command generating module 306, a test command transmitting module 308, and a feedback receiving module 310. In some embodiments, the local system 104 may further include a selection module 312. It should be noted that the functionalities of the above modules may be performed individually by each module, or alternately the functionalities of multiple modules may be combined in a single module. [031] The request receiving module 302 may be configured to receive a request from the client system 102 to perform testing of the set of remote device of the plurality of remote devices 106. The local system 104 and client system 102 may be connected via the first network connection 108. The local system 104 may be configured to obtain and store an identity of each of the plurality of remote devices 106, once the remote devices 106 are connected to the local system 104. For example, the plurality of remote devices 106 may include Android-based devices. [032] In some embodiments, the selection module 312 may be configured to receive, from the client system 102, a selection of identities of the set of remote devices from the plurality of remote devices 106 for performing testing on the set of remote devices. For example, the local system 104 may be connected to N number of remote devices; however, a user may want to perform testing on M number of devices (where, M