What is GUI Testing and Most common GUI Test Cases for Web based Application

What is GUI Testing and Most common GUI Test Cases for Web-based Application:

There are two types of interfaces in a computer application.
1.Command Line Interface is where you type text and computer respond to that command.
2.GUI stands for Graphical User Interface where you interact with the computer using images rather than text.

The term “User Interface” refers to the methods and devices that are used to accommodate interaction between machines and the human beings, users, who use them. User interfaces can take on many forms, but always accomplish two fundamental tasks: communicating information from the product to the user, and communicating information from the user to the product.

The term “Graphical user interface”(GUI) is the layer where the digital product communicated with human and human communicated with the digital product. A well-designed product can fail with an unsuccessful interface. Conversely, a product has not good design values can become successful with its well-designed interface. To get the best interaction between digital product and user, the graphical interface design itself needs to have some design values and requires a systematic approach to the design process. But, to ensure optimum performance, it also requires a model of interaction to understand exactly what is going on in the interaction and identify the likely root of difficulties.

Following are the GUI elements which can be used for interaction between the user and application:

GUI testing involves checking the screens with the controls like menus, buttons, icons, and all types of bars – toolbar, menu bar, dialog boxes and windows, etc.

GUI Testing basically involves

1.Check the all required objects, elements, fields, buttons,labels and links are available
2.Check the URLs of the each page
3.check the page titles of the each page
4.Check all pages for broken links
5. All fields on pages (e.g. text box, radio options, drop-down lists) should be aligned properly with size, position, width, height of the elements.
6.Do buttons follow the project standards for size and position
7.Enough space should be provided between field labels, columns, rows, error messages etc.
8.All mandatory fields should be validated and indicated by asterisk (*) symbol
9.Validation error messages should be displayed properly at correct position
10.Input fields should be checked for maximum field value. Input values greater than specified max limit should not be accepted or stored in database
11.Confirmation messages should be displayed before performing any update or delete operation
12.Tooltip text should be meaningful.
13 COLORS
13.1 Are the field backgrounds the correct color?
13.2 Are the field prompts the correct color?
13.3 Are the screen and field colors adjusted correctly for non-editable mode?
13.4 Are all the buttons are in standard format and size?
13.5 Is the general screen background the correct color?
13.6 Is the page background (color) distraction free?
13.7 Testing the colors of the error messages, warning messages and success messages displayed in different CSS styles for each.
14 CONTENT
14.1 Are all the screen prompts specified in the correct screen font?
14.2 Does content remain if you need to go back to a previous page, or if you move forward to another new page?
14.3 Is all text properly aligned?
14.4 Is the text in all fields specified in the correct screen font?
14.5 Is all the heading are left aligned
14.6 Font size, style and color for headline, description text and labels should be standard as specified in SRS and check the font whether it is readable or not.
14.7 Testing of the spelling, and ensure that you have test cases that look for grammar or spelling errors…
15 IMAGES/ICONS
15.1 Are all graphics properly aligned?
15.2 Are graphics being used the most efficient use of file size?
15.3 Assure that buttons are all of similar size and shape, and same font & font size.
15.4 Banner style & size & display exact same as existing windows
15.5 Does text wrap properly around pictures/graphics?
15.6 Testing the alignment of the images and Check all pages for broken images.

16 NAVIGATION
16.1 Can all screens accessible via buttons on this screen be accessed correctly?
16.2 Does the Tab Order specified on the screen go in sequence from Top Left to bottom right? This is the default unless otherwise specified.
16.3 Is there a link to home on every single page?
16.4 When an error message occurs does the focus return to the field in error when the user cancels it?
16.5 Testing of the scrollbars according to the size of the page if any.
16.6 Pagination should be enabled when there are more results than the default result count per page
16.7 Check for Next, Previous, First and Last page pagination functionality

17 USABILITY
17.1 Are all the field prompts spelled correctly?
17.2 Are fonts too large or too small to read?
17.3 Can the typical user run the system without frustration?
17.4 Do pages print legibly without cutting off text?
17.5 Does the site convey a clear sense of its intended audience?
17.6 Does the site have a consistent, clearly recognizable “look-&-feel”?
17.7 Check the screen in different resolutions with the help of zooming in and zooming out like 640 x 480, 600×800, etc.
17.8 Testing whether the interface is attractive or not.
17.9 Does the system provide or facilitate customer service? i.e. responsive, helpful, accurate?
17.10 Is all terminology understandable for all of the site’s intended users?

Jenkins

JENKINS

What is..?

Jenkins is a tool (web application ) that helps in continuous integration of projects. It is open source and has capability to manage any types of build software. Jenkins can be seamlessly integrated with any testing and deployment environment.

Continuous Integration.

In software developement life cycle, there are various pahses of the software developement. In developement there may be checking in the code, modifying the code, testing, deployment , bug fixes etc. Continous Integration is a practise that requires developers to integrate code into a shared repository at regular intervals. The code can be checked in from various central repository such as GIT, SVN, CVS. They may be modified as per the requirements. Continious Integration is a practise that whenever a code commit occurs, the build process should be triggered.

How to get jenkins.

Jenkins can be downloaded from jenkins.io. Then it may be run from the command line using the java -jar command. It may be put in the application container such as tomcat, jboss, weblogics etc.

Once the Jenkins application is deployed in the machine, it has to be configured with the project repository, build tool (maven, ant etc) build time, testing configuration , email configuration etc.

After the above configuration is set , Jenkins create a disk-space to store all the projects, dependencies etc in a directory ~/.jenkins (default location). We may also change the location by setting the JENKINS_HOME environment variable before launching the servlet container.

 

Email Notification.

Jenkins also sends the email notification when any deployment event occurs. These email feeds can be managed in the email notification area. There is a provision to configure the SMTP settings for sending out emails.

 

Plugins

Jenkins ships in with many plugins to build project, manage project, add security, add user and organization level profile, etc We may also add plugins build for jenkins systems.

Manage Plugins screen helps to install, update and remove plugins.

Importance of Bug Life Cycle in Software Testing

Importance of Bug Life Cycle in Software Testing

Introduction:

Mistakes lead to the introduction of defects (also called bugs).  like all human beings I can make mistakes at any point in time, no matter what I might be working on. So it is on projects, where the business analyst can put a defect into a requirements specification, a tester can put a defect into a test case, a programmer can put a defect into the code, a technical writer can put a defect into the user guide, and so forth. Any work product can and often will have defects because any worker can and will make mistakes! Bug can be defined as the abnormal behavior of the software. No software exists without a bug. The elimination of bugs from the software depends upon the efficiency of testing done on the software.

Bug Life Cycle:

In software development process, the bug has a life cycle. The bug should go through the life cycle to be closed. A specific life cycle ensures that the process is standardized. The bug attains different states in the life cycle. It starts when defect is found and ends when a defect is closed, after ensuring it’s not reproduced.Below find the various states that a defects goes through in its life-cycle. The number of states that a defect goes through varies from project to project. Below life-cycle, covers all possible states.

Testing

Testing

  1. New: When a defect is logged and posted for the first time. It is assigned a status NEW.
  2. Assigned: After the tester has posted the bug, the lead of the tester approves that the bug is genuine and he assigns the bug to corresponding developer and the developer team. It’s state given as Assigned.
  3. Open:  At  this state the developer has started analyzing and working on the defect fix.
  4. Fixed:  When developer makes necessary code changes and verifies the changes then he can make bug status as ‘Fixed’ and the bug is passed to testing team. 
  5. Retest:  At this stage the tester does the retesting of the code at this stage to check whether the defect is fixed by the developer or not and change the status to “Re-test.”
  6. Verified/Resolved:  The tester tests the bug again after it got fixed by the developer. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “verified/Resolved”.
  7. Reopen:  If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “reopened”. Once again the bug goes through the life cycle.
  8. Closed:  Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “closed”. This state means that the bug is fixed, tested and approved.
  9. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “duplicate”
  10. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “rejected”.If the developer feels the defect is not a genuine defect 
  11. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.If the present bug is not of a prime priority and if it is expected to get fixed in the next release, then status “Deferred” is assigned to such bugs
  12. Not a bug:  The state given as “Not a bug” if there is no change in the functionality of the application. For an example: If customer asks for some change in the look and field of the application like change of colour of some text then it is not a bug but just some change in the looks of the  application.If it does not affect the functionality of the application then the status assigned to a bug is “Not a bug”.
  13. Known bug:These are problems known to exist at the time of this (Current)release.It is same as Deferred status.

Conclusion::
While defect prevention is much more effective and efficient in reducing the number of defects, most organization conducts defect discovery and removal.The challenges of following a bug life cycle are far outweighed by the benefits derived. A well planned and closely managed defect database not only tracks current defects against any number of builds and/or products, it also provides a virtual paper trail for the overall progress of a product as it is coded, tested, and released. If sufficient time is provided for building a defect tracker that works for your company, it is more likely you will release a less buggy product, or at least a product where most of the big ones have not gotten away

STLC (Software Test Life Cycle)

STLC (Software Test Life Cycle)

Life-cycle in simple term refers to the sequence of changes from one form to other form. These changes can happen to any tangible or intangible things. Every entity has a life-cycle from its inception to retire / demise.In a similar fashion, Software is also an entity. Just like developing software involves a sequences of steps, testing also has steps which should be executed in a definite sequence.This phenomenon of executing the testing activities in a systematic and planned way is called testing life cycle.

The process of testing a software in a well planned and systematic way is known as software testing life cycle(STLC).Different organizations have different phases in STLC however generic Software Test Life Cycle (STLC) for waterfall development model consists of the following phases.

1. Requirements Analysis
2. Test Planning
3. Test Scenarios and Test Cases Development
4. Test Environment Setup
5. Test Execution and Bug Reporting
6.Test Cycle Closure

STLC Phases

1.Requirements Analysis

In this phase testers analyze the customer requirements and work with developers during the design phase to see which requirements are testable and how they are going to test those requirements.It is very important to start testing activities from the requirements phase itself because the cost of fixing defect is very less if it is found in requirements phase rather than in future phases.

2.Test Planning

In this phase all the planning about testing is done like what needs to be tested, how the testing will be done, test strategy to be followed, what will be the test environment, what test methodologies will be followed, hardware and software availability, resources, risks etc. A high level test plan document is created which includes all the planning inputs mentioned above and circulated to the stakeholders.

3. Test Scenarios and Test Cases Development

The test scenarios and test cases development activity is started once the test planning activity is finished.This is the phase of STLC where testing team write down the detailed test scenarios and test cases. Along with these, testing team also prepare the test data if any required for testing. Once the test cases are ready then these test cases are reviewed by peer members or QA lead. Also the Requirement Trace-ability Matrix (RTM) is prepared. The Requirement Trace-ability Matrix is an industry-accepted format for tracking requirements where each test case is mapped with the requirement. Using this RTM we can track backward & forward trace-ability.

4. Test Environment Setup

Setting up the test environment is vital part of the STLC. Basically test environment decides on which conditions software is tested. This is independent activity and can be started parallel with Test Case Development. In process of setting up testing environment test team is not involved in it. Based on company to company may be developer or customer creates the testing environment. Mean while testing team should prepare the smoke test cases to check the readiness of the test environment setup.

5. Test Execution and Bug Reporting

Once the unit testing is done by the developers and test team gets the test build, The test cases are executed and defects are reported in bug tracking tool, after the test execution is complete and all the defects are reported. Test execution reports are created and circulated to project stakeholders.
After developers fix the bugs raised by testers they give another build with fixes to testers, testers do re-testing and regression testing to ensure that the defect has been fixed and not affected any other areas of software.Testing is an iterative process i.e. If defect is found and fixed, testing needs to be done after every defect fix.After tester assures that defects have been fixed and no more critical defects remain in software the build is given for final testing.

6.Test Cycle Closure

Call out the testing team member meeting & evaluate cycle completion criteria based on Test coverage, Quality, Cost, Time, Critical Business Objectives, and Software. Discuss what all went good, which area needs to be improve & taking the lessons from current STLC as input to upcoming test cycles, which will help to improve bottleneck in the STLC process. Test case & bug report will analyze to find out the defect distribution by type and severity. Once complete the test cycle then test closure report & Test metrics will be prepared. Test result analysis to find out the defect distribution by type and severity.

Importance of the Levels Of Testing

Importance of the Levels Of Testing…
Before releases an application, it undergoes a thorough testing process to ensure that the application is working in the manner in which it was intended.  that need to be completed before releasing the application. To enhance the quality of software testing, The testing process could be abstracted to different levels. There are Five main levels of testing.
Continue reading

What is Software Testing? Why is software testing necessary?

What is Software Testing?

Nowadays, Software testing plays an important role,which helps to improve the quality, reliability and performance of the software applications. Usually software testing is considered as one phase of the software development life cycle (SDLC).

Software testing is the process in which the defects are identified, isolated and subjected for rectification to ensure that the product/project is defect free in order to provide quality to the product/project, hence customer satisfaction.

It includes, a set of activities conducted with the intent of finding defects in software so that it could be corrected before the product is released to the end users.

Why is software testing necessary?

⇒ Software testing is really required to point out the defects  that were made during the development phases, because it can be very expensive in the future or in the later stages of the development.

⇒ It’s essential since it make sure of the Customer’s reliability and their satisfaction in the application.

⇒It is very important to ensure the Quality of the product. Quality product delivered to the customers helps in gaining their confidence.

⇒Testing is required for an effective performance of software application or product.

If the Product released to the market without conducting proper testing then,Software that does not work as expected can have a large impact on an organization. It can lead to many problems including:
⇒ Loss of money : This can include losing customers right through to financial penalties for non-compliance to legal requirements
Loss of time : It will take much time to resolve
Damage to business reputation : If an organization is unable to provide service to their customers due to software problems then the customers will lose confidence or faith in this organization

Software bugs can potentially cause monetary and human loss, history is full of such examples

⇒ The China Airlines Airbus A300 crashing due to a software bug on April 26, 1994 killing 264 innocent lives.
⇒ In April of 1999 ,a software bug caused the failure of a $1.2 billion military satellite launch, the costliest accident in history.
⇒ In May of 1996, a software bug caused the bank accounts of 823 customers of a major U.S. bank to be credited with 920 million US dollars.

⇒ Mariner Bugs Out (1962):Cost: $18.5 million

⇒ Hartford Coliseum Collapse (1978)
Cost: $70 million, plus another $20 million damage to the local economy

⇒ Medical Machine Kills (1985)
Cost: Three people dead, three people critically injured

As you can see, testing is important because software bugs could be expensive or even dangerous.