360Logica.com

Application Testing is an activity that every software tester performs daily in his career. These two words are extremely broad in practical aspect. However, only the core and most important areas will be discussed here. The purpose of this article is to touch all the primary areas so that the readers will get all the basic briefing at a single place.

Categories of Applications

Whether it is a small calculator software with only the basic arithmetic operations, or an online enterprise solution; there are two categories of applications.

• Desktop
• Web

For desktop applications, testing should take into account the UI, business logic, database, reports, roles and rights, integrity, usability and data flow. For web applications, along with all these major areas; testers should give sufficient importance to performance, load and security of the application.

Application Testing Methodologies

This is a well-known and well discussed aspect; there are only 3 universally accepted methodologies:

Black Box: In black-box testing, the AUT is validated against its requirements considering the inputs and expected outputs, regardless of how the inputs are transformed into outputs. Testers are least concerned with internal structure or code that implements the business logic of the application. There are four primary techniques to design test cases for black box testing:

• BVA (Boundary value Analysis)
• EP (Equivalence Partitioning)
• Decision Tables
• State Transition Tables (and diagrams)

White Box: Primary focus of this methodology is to validate, how the business logic of application is implemented by code. Internal structure of the application is tested and the techniques available to do so are:

• Code Coverage
• Path Coverage

Grey Box: Practically speaking, this is a mixture of black box and white box. In this methodology, mainly the tester tests the application as in black box. But, for some business critical or vulnerable modules of application; testing is done as white box.

Application Testing Tools

There are at least 50 testing tools available in market today. These include both paid and open source tools. Moreover, some tools are purpose specific e.g. UI testing, Functional Testing, DB Testing, Load Testing, Performance, Security Testing and Link validation testing etc. However, some tools are strong and provide the facility of testing several major aspects of an application. The general concept of ‘Application Testing’ is its functional testing. So, our focus will be on functional testing tools.

Here is the list of some most important and fundamental features that are provided by almost all of the ‘Functional Testing’ tools.

• Record and Play
• Parametrize the Values
• Script Editor
• Run (the test or script, with debug and update modes)
• Report of Run session

Different vendors provide some specific features that make their product unique to other competitor products. But the five features listed above are the most common and can be found in almost all the functional testing tools.

Following is the list of few widely used Functional Testing tools.

• HP QTP (Quick Test Professional)
• Selenium
• IBM Rational Robot
• Test Complete
• Push to Test
• Telerik

Software Test Plan (STP)

For any activity, some planning is always required and same is true for software testing. Without proper plan there is always high risk of getting distracted during the testing. If this risk becomes a fact, the results could be horrible.

Following are the 5 main parts of a good Test Plan:

Scope

• Overview of AUT
• Features (or areas) to be tested
• Exclusions (features or areas not to be tested) with reason
• Dependencies (of testing activities on each other, if any)

Focus: This section describes what aspect of application will be included in the testing e.g. security, functionality, usability, reliability, performance or efficiency etc.

Approach: This section describes what testing methodology will be adopted for which areas of AUT. For example, in the STP of an ERP application; the approach section may contain the information that black box testing will be approach for payroll. On the other hand, for reports the approach will be grey box testing.

Schedule: This sections describes that who will be doing what and where on the AUT, when and how. Schedule section is, in fact, a ’4Ws and H’ of the STP. Normally it is a simple table, but every organization may have its own customized format according to their own needs. Once the test plan is ready and application is under development; testers design and document the test cases. In the “Application Testing – Methodologies” section above, I have listed the TC design techniques.

Application Testing Cycles

Once the AUT is ready for testing, the practical phase of testing cycle starts in which testers actually execute the test cases on AUT. Keep in mind that here the testing cycle is discussed regardless of Testing Levels (Unit, Module, Integration, System and User Acceptance) and Testing Environments (Dev, QA, Client’s Replica, Live).

Smoke Testing: The very first testing cycle that is wide and shallow in approach. The purpose of smoke testing is to verify that there are no crashes in the application and it is suitable for further testing.

Sanity Testing: The second testing cycle that is narrow and deep in its approach. Its purpose is to verify that a specific module is working properly and is suitable for complete testing.

Tip: Usually there is not ample amount of time available to run these two cycles separately. So, a mixture of both these cycles is adopted in practical.

Functional Testing: The proper and full fledged testing of application is performed in this cycle. The primary focus of this activity is to verify the business logic of the application.

Regression Testing: This is the final cycle of testing in which the bug-fixes and/or updates are verified. Moreover, regression testing also ensures that there is no malfunctioning in other areas of AUT due to fixes and changes.

Bugs are logged in every testing cycle. There is no distinct border line between the testing cycles. For example, in Regression the Functionality is also verified and it may also require smoke, sanity or their merger first.

Application Testing – Best Practices

• Plan Properly
• Test Keenly
• Log the bugs Clearly
• Do Regression Test Efficiently
• Improve above four skills Continuously

Conclusion: Application Testing is a vast subject and the primary activity of any software tester. In this article, we have provided the overview of some most fundamental and necessary areas that fall under this topic. Application Testing involves strategies, phenomena, approaches, tools, technologies and guidelines. However, we have addressed the conceptual and practical insight of its salient concerns.

We will first focus on what exactly cookies are and how they work. It would be easy for you to understand the test cases for testing cookies when you have clear understanding of how cookies work? How cookies are stored on hard drive? And how can we edit cookie settings?

What is Cookie?

Cookie is small information stored in text file on user’s hard drive by web server. This information is later used by web browser to retrieve information from that machine. Generally cookie contains personalized user data or information that is used to communicate between different web pages.

Why Cookies are used?

Cookies are nothing but the user’s identity and used to track where the user navigated throughout the web site pages. The communication between web browser and web server is stateless.

For example if you are accessing domain http://www.example.com/1.html then web browser will simply query to example.com web server for the page 1.html. Next time if you type page as http://www.example.com/2.html then new request is sent to example.com web server for sending 2.html page.

What if you want the previous history of this user communication with the web server? You need to maintain the user state and interaction between web browser and web server somewhere. This is where cookie comes into picture. Cookies serve the purpose of maintaining the user interactions with web server.

How cookies work?

The HTTP protocol used to exchange information files on the web is used to maintain the cookies. There are two types of HTTP protocol. Stateless HTTP and Stateful HTTP protocol. Stateless HTTP protocol does not keep any record of previously accessed web page history. While Stateful HTTP protocol do keep some history of previous web browser and web server interactions and this protocol is used by cookies to maintain the user interactions.

Whenever user visits the site or page that is using cookie, small code inside that HTML page (Generally a call to some language script to write the cookie like cookies in JAVAScript, PHP, Perl) writes a text file on users machine called cookie. Here is one example of the code that is used to write cookie and can be placed inside any HTML page:

Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME;

When user visits the same page or domain later, this cookie is read from disk and used to identify the second visit of the same user on that domain. Expiration time is set while writing the cookie. This time is decided by the application that is going to use the cookie.

Generally two types of cookies are written on user machine.

• Session cookies: This cookie is active till the browser that invoked the cookie is open. When we close the browser this session cookie gets deleted. A session of say 20 minutes can be set to expire the cookie.
• Persistent cookies: The cookies that are written permanently on user machine and lasts for months or years.

Where cookies are stored?

When any web page application writes cookie it get saved in a text file on user hard disk drive. The path where the cookies get stored depends on the browser. Different browsers store cookie in different paths. E.g. Internet explorer stores cookies on path “C:\Documents and Settings\Default User\Cookies”
Here the “Default User” can be replaced by the current user you are logged in as. The cookie path can be easily found by navigating through the browser options. In Mozilla Firefox browser you can even see the cookies in browser options itself. Open the Mozila browser, click on Tools->Options->Privacy and then “Show cookies” button.

How cookies are stored?

Let us take an example of a cookie written by rediff.com on Mozilla Firefox browser:
On Mozilla Firefox browser when you open the page rediff.com or login to your rediffmail account, a cookie will get written on your Hard disk. To view this cookie simply click on “Show cookies” button mentioned on above path. Click on Rediff.com site under this cookie list. You can see different cookies written by rediff domain with different names.

Site: Rediff.com Cookie name: RMID
Name: RMID (Name of the cookie)
Content: 1d11c8ec44bf49e0… (Encrypted content)
Domain: .rediff.com
Path: / (Any path after the domain name)
Send For: Any type of connection
Expires: Thursday, December 31, 2020 11:59:59 PM

Applications where cookies can be used

• To implement shopping cart
  Cookies are used for maintaining online ordering system. Cookies remember what user wants to buy. What if user adds some products in their shopping cart and if due to some reason user doesn't want to buy those products this time and closes the browser window? When next time same user visits the purchase page he can see all the products he added in shopping cart in his last visit.
• Personalized sites
  When user visits certain pages they are asked which pages they don’t want to visit or display. User options get stored in cookie and till the user is online, those pages are not shown to him.
• User tracking
  To track number of unique visitors online at particular time.
• Marketing
  Some companies use cookies to display advertisements on user machines. Cookies control these advertisements. When and which advertisement should be shown? What is the interest of the user? Which keywords he searches on the site? All these things can be maintained using cookies.
• User sessions
  Cookies can track user sessions to particular domain using user ID and password.

Drawbacks of cookies

• Writing Cookie is a great way to maintain user interaction but if user has set browser options to warn before writing any cookie or disabled cookies completely then site containing cookie will be completely disabled and can not perform any operation resulting in loss of site traffic.
• Too many Cookies
  If you are writing too many cookies on every page navigation and if user has turned on option to warn before writing cookie, this could turn away user from your site.
• Security issues
  Some times users personal information is stored in cookies and if someone hacks the cookie then hacker can get access to your personal information. Even corrupted cookies can be read by different domains and lead to security issues.
• Sensitive information
  Some sites may write and store your sensitive information in cookies, which should not be allowed due to privacy concerns.

Some Major Test cases for web application cookie testing

The first obvious test case is to test if your application is writing cookies properly on disk. You can use the Cookie Tester application also if you don’t have any web application to test but you want to understand the cookie concept for testing.

Test Cases

• As a privacy policy make sure from your design documents that no personal or sensitive data is stored in the cookie.
• If you have no option other than saving sensitive data in cookie make sure data stored in cookie is stored in encrypted format.
• Make sure that there is no overuse of cookies on your site under test. Overuse of cookies will annoy users if browser is prompting for cookies more often and this could result in loss of site traffic and eventually loss of business.
• Disable the cookies from your browser settings: If you are using cookies on your site, your sites major functionality will not work by disabling the cookies. Then try to access the web site under test. Navigate through the site. See if appropriate messages are displayed to users like “For smooth functioning of this site make sure that cookies are enabled on your browser”. There should not be any page crash due to disabling the cookies. (Please make sure that you close all browsers, delete all previously written cookies before performing this test).
• Accepts/Reject some cookies: The best way to check web site functionality is not to accept all cookies. If you are writing 10 cookies in your web application then randomly accept some cookies, say accept 5 and reject 5 cookies. For executing this test case you can set browser options to prompt whenever cookie is being written to disk. On this prompt window you can either accept or reject cookie. Try to access major functionality of web site. See if pages are getting crashed or data is getting corrupted.
• Delete cookie: Allow site to write the cookies and then close all browsers and manually delete all cookies for web site under test. Access the web pages and check the behavior of the pages.
• Corrupt the cookies: Corrupting cookie is easy. You know where cookies are stored. Manually edit the cookie in notepad and change the parameters to some vague values and see the site functionality. In some cases corrupted cookies allow to read the data inside it for any other domain. This should not happen in case of your web site cookies. Note that the cookies written by one domain say rediff.com can’t be accessed by other domain say yahoo.com unless and until the cookies are corrupted and someone is trying to hack the cookie data.
• Checking the deletion of cookies from your web application page: Some times cookie written by domain say rediff.com may be deleted by same domain but by different page under that domain. This is the general case if you are testing some ‘action tracking’ web portal. Action tracking or purchase tracking pixel is placed on the action web page and when any action or purchase occurs by user the cookie written on disk get deleted to avoid multiple action logging from same cookie. Check if reaching to your action or purchase page deletes the cookie properly and no more invalid actions or purchase get logged from same user.
• Cookie Testing on Multiple browsers: This is an important case to check if your web application page is writing the cookies properly on different browsers as intended and site works properly using these cookies. You can test your web application on Major browsers like Internet explorer (Various versions), Mozilla Firefox, Chrome, Netscape, Opera etc.
• If your web application is using cookies to maintain the logging state of any user then log in to your web application using some username and password. In many cases you can see the logged in user ID parameter directly in browser address bar. Change this parameter to different value say if previous user ID is 100 then make it 101 and press enter. The proper access message should be displayed to user and user should not be able to see other users account.

These are some Major test cases to be considered while testing website cookies. You can write multiple test cases from these test cases by performing various combinations.

Source: http://www.softwaretestinghelp.com

Have you performed software installation testing? How was the experience? Well, Installation testing (Implementation Testing) is quite interesting part of software testing life cycle.

If your installation is successful on the new system then customer will be definitely happy but what if things are completely opposite. If installation fails then our program will not work on that system; not only this but can also leave user’s system badly damaged. User might require to reinstall the full operating system.

In above case will you make any impression on user? Definitely not! Your first impression to make a loyal customer is ruined due to incomplete installation testing.

What you need to do for a good first impression? Test the installer appropriately with combination of both manual and automated processes on different machines with different configuration. Major concern of installation testing is Time! It requires a lot of time to even execute a single test case. If you are going to test a big application installer then think about time required to perform so many test cases on different configurations.

We will see different methods to perform manual installer testing and some basic guideline for automating the installation process.

To start installation testing first decide on how many different system configurations you want to test the installation. Prepare one basic hard disk drive. Format this HDD with most common or default file system, install most common operating system (Windows) on this HDD. Install some basic required components on this HDD. Each time create images of this base HDD and you can create other configurations on this base drive. Make one set of each configuration like Operating system and file format to be used for further testing.

How we can use automation in this process? We will make some systems dedicated for creating basic images (use software’s like Norton Ghost for creating exact images of operating system quickly) of base configuration. This will save you tremendous time in each test case. For example if time to install one OS with basic configuration is say 1 hour then for each test case on fresh OS you will require 1+ hour. But creating image of OS will hardly require 5 to 10 minutes and you will save approximately 40 to 50 minutes!

You can use one operating system with multiple attempts of installation of installer. Each time uninstalling the application and preparing the base state for next test case. Be careful here that your uninstallation program should be tested before and should be working fine.

Installation testing tips with some broad test cases:

• Use flow diagrams to perform installation testing. Flow diagrams simplify our task.
• If you have previously installed compact basic version of application then in next test case install the full application version on the same path as used for compact version.
• If you are using flow diagram to test different files to be written on disk while installation then use the same flow diagram in reverse order to test uninstallation of all the installed files on disk.
• Use flow diagrams to automate the testing efforts. It will be very easy to convert diagrams into automated scripts.
• Test the installer scripts used for checking the required disk space. If installer is prompting required disk space 1MB, then make sure exactly 1MB is used or whether more disk space is utilized during installation. If yes flag this as error.
• Test disk space requirement on different file system format. Like FAT16 will require more space than efficient NTFS or FAT32 file systems.
• If possible set a dedicated system for only creating disk images. As mentioned above this will save your testing time.
• Use distributed testing environment in order to carry out installation testing. Distributed environment simply saves your time and you can effectively manage all the different test cases from a single machine. The good approach for this is to create a master machine, which will drive different slave machines on network. You can start installation simultaneously on different machines from the master system.
• Try to automate the routine to test the number of files to be written on disk. You can maintain this file list to be written on disk in an excel sheet and can give this list as an input to automated script that will check each and every path to verify the correct installation.
• Use software’s available freely in market to verify registry changes on successful installation. Verify the registry changes with your expected change list after installation.
• Forcefully break the installation process in between. See the behavior of system and whether system recovers to its original state without any issues. You can test this “break of installation” on every installation step.
• Disk space checking: This is crucial in the installation-testing scenario. You can choose different manual and automated methods to do this checking. In manual methods you can check free disk space available on drive before installation and disk space reported by installer script to check whether installer is calculating and reporting disk space accurately. Check the disk space after the installation to verify accurate usage of installation disk space. Run various combination of disk space availability by using some tools to automatically make disk space full while installation. Check system behavior on low disk space conditions while installation.
• As you check installation you can test for uninstallation also. Before each new iteration of installation make sure that all the files written to disk are removed after uninstallation. Some times uninstallation routine removes files from only last upgraded installation keeping the old version files untouched. Also check for rebooting option after uninstallation manually and forcefully not to reboot.

The Client

Our customer for OS compatibilities is http://www.dualalign.com, they developed a products for High Impact Image Applications and all 3 softwares are Desktop applications.

For browser compatibility test requirements, Our customer is leader in Online market Place - www.elance.com .

The Requirements

• DualAlign required to ship their products on different OS Windows, Mac and Linux. 360logica supposed to perform compatibility testing across all different OS and produce compatibility issues.
• Elance is leader in onlinemarket place and asked us to perform regular testing on all available browsers and OS.

The Solution

• Identification of Matrix of all OS and resource scheduling.
• Defined tasks and QA deployed for dedicated OS testing for Dual align products, produce separate reports for each OS results.
• Browser testing for Elance, we identified all popular browser and their old and newer versions. We prepared matrix of those information's and used QA resources for one version of one browser. VM ware helped us to perform testing on different browser on different machines.

The Technology

• OS for Dual align tests : Windows 2000, 2003, NT, VISTA, XP, windows 7, and MAC
• Browsers: Internet explorer versions 6,7,8, Firefox versions 1.5, 2.0 and higher, Opera, Safari on windows and Mac both
• VM ware for virtual machines creation
• MAC OSX

Contribution

• Challenge was to set up different OS and browser environment
• Resource allocation for every combination of OS and browser
• This involved the development of various OS and browser combinations and generating the environments.
• Performing the functional and browser compatibility testing across these combinations of operating systems and browsers.
• Worked closely with customer to understand product
• Establish a bug reporting mechanism for efficient and quick bug fixing.

You can also download the case study here.

The Client

Our Customer is a Internet marketing company exclusively for the travel industry providing online hospitality marketing and consulting service for worldwide hotels, resorts and travel clients.

The Requirements

• Scalability: Platform must be able to support a very high number of concurrent users.
• Efficiency: Customer expectation includes the highly efficient application with minimal page navigation response time.
• Reliability: Platform must scale rapidly to meet the business goals of attracting a larger user base and supporting multiple formats
• Fail Over: Application should be able to behave functionally correct under high load and should have the Fail Over control

The Solution

• Performance testing on HTTP, HTTPS protocols
• Performance Tests on UI, AJAX etc
• Identify Performance bottlenecks and suggest measures to overcomes them
• Performance tests based on number concurrent users
• Monitoring the server parameters like CPU usage, threads count, connections etc.
• Profiling the application through Dot Trace and SQL profiler

The Technology

• Microsoft .NET
• AJAX
• SQL Server
• IIS Server
• Kapow Data Mining

Contribution

• Response time for actions covered under test.
• Server stats analysis and suggesting bottlenecks:
  • Bottleneck due to resource usage of Kapow which is running on the same web server.
  • Suggestion for the optimum threads count.
• Capturing the time consuming Stored Procs.

You can also download the case study here.

Bug life cycles are similar to software development life cycles. Bug life cycle begins when a programmer, software developer, or architect makes a mistake, creates an unintentional software defect, i.e. bug, and ends when the bug is fixed, and the bug is no longer in existence.

The bug life cycle can be summarized as follows:

• A Tester finds a bug. Status --> Open
• Test lead review the bug and authoriza the bug. Stats --> Open
• Development team lead review the defect. Stats --> Open
• The defect can be authorized or unauthorized by the development team. (Here the status of the defect / bug will be Open (For Authorized Defects) and Reject (For Unauthorized Defects).
• Now, the authorized bugs will get fixed or deferred by the development team. Status of the fixed bugs will be Fixed and Status will be Deferred for the bugs which got Deferred.
• The Fixed bugs will be again re-tested by the testing team. Here based on the Closure of the Bug, the status will be made as Closed or if the bug still remains, it will be re-raised and status will be Re-opened.

Source: http://www.softwaretestingvideos.com

Test Specification

It is a detailed summary of what scenarios will be tested, how they will be tested, how often they will be tested, and so on and so forth, for a given feature. Trying to include all Editor Features or all Window Management Features into one Test Specification would make it too large to effectively read.

However, a Test Plan is a collection of all test specifications for a given area. The Test Plan contains a high-level overview of what is tested for the given feature area.

Contents of a Test Specification

Revision History

This section contain information like Who created the test specification? When was it created? When was the last time it was updated?

Feature Description

A brief description of what area is being tested.

What is tested?

An overview of what scenarios are tested.

What is not tested?

Are there any areas that are not being tested. There can be several reasons like being covered by different people or any test limitations etc. If so, include this information as well.

Nightly Test Cases

A list of the test cases and high-level description of what is tested whenever a new build becomes available.

Breakout of Major Test Areas

It is the most interesting part of the test specification where testers arrange test cases according to what they are testing.

Specific Functionality Tests

Tests to verify the feature is working according to the design specification. This area also includes verifying error conditions.

Security Tests

Any tests that are related to security.

Accessibility Tests

Any tests that are related to accessibility.

Performance Tests

This section includes verifying any performance requirements for your feature.

Localization / Globalization

Tests to ensure you’re meeting your product’s Local and International requirements.

Please note that your Test Specification document should be in such a manner that should prioritize the test case easily like nightly test cases, weekly test cases and full test pass etc.

• Nightly - Must run whenever a new build is available.
• Weekly - Other major functionality tests run once every three or four builds.
• Lower Priority - Run once every major coding milestone.

Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. In this video we describe the fundamentals of software testing.

Different types of Software Testing processes are described below:

• Unit Testing
  It is a method by which individual units of source code are tested to determine if they are fit for use.
• Integration Testing
  Here individual software modules are combined and tested as a group.
• Functionality Testing
  It is a type of black box testing that bases its test cases on the specifications of the software component under test.
• Usability Testing
  It is a technique used to evaluate a product by testing it on users.
• System Testing
  It is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements.
• Performance Testing
  It is testing that is performed, to determine how fast some aspect of a system performs under a particular workload.
• Load Testing
  It refers to the practice of modeling the expected usage of a software program by simulating multiple users accessing the program concurrently.
• Stress Testing
  It is a form of testing that is used to determine the stability of a given system or entity.

Get in, get out. That’s the attitude that most developers have in testing and debugging their applications. Few developers look forward to these tasks during the development cycle, and so they want to efficiently get into the code, figure out what’s working and what’s not, fix any problem, and then move on. Given the heterogeneous nature of Web applications, debugging has always been challenging, particularly when trying to work with client–side JavaScript. To address this need, fairly sophisticated debugging tools have emerged over the past few years among the developer community, most notably Firebug and other add–ons for Firefox. However, the problem is that most of these testing tools that Web developers have come to rely on for desktop browsers are not yet compatible with the iPhone, iPad and iPod touch platform.

Many iPhone developers, unsure of where else to turn, end up resorting to alert() debugging — adding alert() throughout the body of the script code to determine programmatic flow and variable values. However, not only is this type of debugging painful, but it can also throw off the timing of the script, making it difficult or impossible to simulate real world results. While the number of debugging and testing tools are indeed limited right now for Mobile Safari, there still are options that either work directly inside Mobile Safari or emulate Mobile Safari on the desktop. Developers will probably want to incorporate aspects of both as part of their regular debugging and testing process.

Some high level test scenarios for iPhone application are given below

• Handset Application Functionality: Perform real iPhone based testing of the application with various scenarios. Test team will test the application based on defined specifications.
• Device Certification: Certify applications on actual device. Test team should test the performance of the application, resource usage, behavior and interactions.
• Performance and Scalability: Backend applications will need to manage the traffic of multiple mobile devices at the same time. This test will identify all the load issues and will help make system more scalable.
• Usability and Compatibility: Verify the effectiveness of Usability of application onto various devices including interoperability with other applications running on the device. Certify the Application on Various mobile devices for the correct behavior and interactions.
• UI Response Application: Verify the response of each function and measure the performance of each response.
• Settings Response: Verify all settings available for the application and test the functionality of each setting.
• Crash Points: Identify all crash points, and will work with development team to resolve them.
• Low Connectivity: Test the behavior of iPhone App in Low connectivity mode and verify proper behavior.
• Response Memory Handling: Measure the memory usage of the application and identify all memory leaks.
• Sleep Mode: Test the application response in sleep mode.
• Accelerometer: Test to ensure that iPhone application properly responds to rotations.
• Battery Usage: Measure the battery usage and will provide feedback on increasing battery life.
• Retrials in Case of Network Disconnection: Test application behavior in case of network disconnection.

This video deals with the problems faced in software testing.

The difficulty in software testing stems from the complexity of software: we can not completely test a program with moderate complexity. Testing is more than just debugging. The purpose of testing can be quality assurance, verification and validation, or reliability estimation. Testing can be used as a generic metric as well. Correctness testing and reliability testing are two major areas of testing. Software testing is a trade-off between budget, time and quality.