Selenium webdriver architecture

Selenium webdriver architecture mainly divided into three parts

Language level bindings
Selenium Webdriver API
Drivers
1) Language Level Bindings :
We can see at the Left hand side here we’ve got some bindings and these are language level bindings and with which we can implement the Selenium webdriver code. In simple words these the languages in which are making an framework, will interact with the Selenium Webdriver and work on various browsers and other devices. So we have a common API that we use for Selenium that has a common set of commands and we have various bindings for the different languages. So we can see there’s Java, Java, Python, Ruby, there’s also some other bindings and new bindings can be added very easily.
2) Selenium Webdriver API:
Now these bindings communicate with Selenium Webdriver API and and This API send the commands taken from language level bindings interpret it and sent it to Respective driver. API contains set of common library which allow to send command to respective drivers.
3) Drivers:
Drivers here at the right hand side, we see we have various internet browser specific drivers such as IE driver, a Firefox, Chrome, and other drivers such as HTML unit which is an interesting one. It works in headless mode which make text execution faster. It also contains mobile specific drivers as well. But the basic idea here is that each one of these drivers knows how to drive the browser that it corresponds to. So the Chrome driver knows how to handle the low level details of Chome browser and drive it to do things like clicking button, going into pages, getting data from the browser itself, the same thing for Firefox, IE, and so on.

How all blocks work together?
So what’s happening here is we’re going to write our test in let’s say in Java and we’re going to be using common Selenium API and that Java binding is going to be sending command across this common WebDriver API. Now on the other end is going to be listening a driver, It’s going to interpret those commands and it’s going to execute them on the actual browser and then it’s going to return the result backup using the WebDriver API to our code where we can look at that result.

How it's working ?
We are writing our test in Java using common selenium API and that Java binding is sending commands across this common API. Now on the other end is listening a driver, it interpret those commands and executing them on the actual browser and return result backup using the API.

Automation Process

Automation Process

1. Requriment Gathering.
2. Identify the best tool to fit.
3. Proof of Concept(POC).
4. Feasibility Analysis.
5. Estimation
6. Frame Work
7. Develop Automation Script.
8. Failure Analysis.
9. Defect Tracking.
10. Publish Reports.
1. Requriment Gathering.
In this stage Test Engineers will collect the requirement documents and review the documnets and they analyse the documents from where to automate it.

2.Identify the Best tool to fit.
In this stage Test engineers will analyse which tool is the best to automate the application.

3.Proof of Conncept
Here Test engineers will give a proof how to automate the software to the client.
Some times client may give end to end scenarios or we may add end-to-end scenarios.

4.Feasiblity Analysis
It is detailed study of the requirements in order to check whether all the requirements are possible are not.
Test Engineers will check where to automate the application and for example cmd prompt test cases will not be automated.

5.Estimation

Hours
Scripts
Man Hours
Man Days
Function Test Engineers
High Complex
8
100
800
100

Medium Complex
5
500
2500
312

Low Complex
3
400
1200
150

*Based on Man hours we calculate Man days

6.Frame works
There are different types of frame works and test lead will decide the best frame work for the software.
Frame works are Keyword Frame work, Linear Frame work, Modular Frame work, Data driven Frame work, Hybrid Frame Work.

7.Develop Automation Scripts
Here the Test Engineers will develop the scripts by Knowing the requirement document, when the build is released then they debug the scripts and execute it

8.Failure Analysis
Here we should plot the data how it is failed
Why the script is failing?
Resaons for failures
Data issues
Application may schronoize
Object identification Issues
Run time errors,Defects

9.Defect Tracking
Test Engineers will track the defect where it is failed.

10.Publish Results
We should give proper Reason where it is failed and in which part it is effecting.

Bug Life Cycle

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. The life cycle of the bug can be shown diagrammatically as follows:

The different states of a bug can be summarized as follows:
1. New
2. Open
3. Assign
4. Test
5. Verified
6. Deferred
7. Reopened
8. Duplicate
9. Rejected and
10. Closed
Description of Various Stages:
1. New: When the bug is posted for the first time, its state will be “NEW”. This means that the bug is not yet approved.
2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as “OPEN”.
3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to “ASSIGN”.
4. Test/Fixed: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to “TEST”. It specifies that the bug has been fixed and is released to testing team.
5. 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.
6. 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”.
7. 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”.
8. Verified: Once the bug is fixed and the status is changed to “TEST”, the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “VERIFIED”.
9. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “REOPENED”. The bug traverses the life cycle once again.
10. 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.
While defect prevention is much more effective and efficient in reducing the number of defects, most organization conducts defect discovery and removal. Discovering and removing defects is an expensive and inefficient process. It is much more efficient for an organization to conduct activities that prevent defects.
Error:
It is a problem related to the program.
Defect:
If the test engineer with respect to the functionality identifies a problem then it is called defect.
Bug:
If the developer accepts the defect that is called as Bug.

Fault / Failure:
The customer identity the problem, after delivery. It is called Fault / Failure.

TYPES OF TESTING

Types of Testing
TYPES OF TESTING
There are 18 types of testing.
1. Build Verification Testing.
2. Regression Testing.
3. Re – Testing.
4. α - Testing.
5. β - Testing.
6. Static Testing.
7. Dynamic Testing.
8. Installation Testing.
9. Compatibility Testing.
10. Monkey Testing
11. Exploratory Testing.
12. Usability Testing.
13. End – To – End Testing.
14. Port – Testing.
15. Reliability Testing
16. Mutation Testing.
17. Security Testing.
18. Adhoc Testing.

1)Build Verification Testing
It is type of testing in which one will conduct overall testing on the related build in order to conform whether the build is proper or not for conducting detailed Testing.
To do some one will check the following,
1) Whether the build can be properly installed in to environment or not.
2) Whether one can navigate to all the pages of the application or not.
3) Whether all the imported features are all available or not.
4) Whether required connections are properly established or not.
In some companies this type of testing is also called as Smoke Testing.
But in some companies just before releasing the build the developers will check whether the build is proper or not. i.e. is known as Smoke Testing and once the build is released the test engineers will check whether the build is proper or not.
i.e Known Build Acceptance Testing(BAT),Build Verification Testing(BVT), Sanity Testing.

2) Regression Testing
It is a type of testing in which one will perform testing on the already tested functionality again and again this is usually done in scenarios (Situations).
Scenario 1:
When ever the defects are raised by the Test Engineer rectified by the developer and the next build is released to the testing department then the Test Engineer will test the defect functionality and it’s related functionalities once again.
Scenario 2:
When ever some new changes are requested by the customer, those new features are incorporated by the developers, next built is released to the testing department then the test engineers will test the related functionalities of the new features once again which are already tested. That is also known as regression testing.
Note: Testing the new features for the first time is new testing but not the regression testing.

Regression Testing – How to Test?

Like any other Testing Regression Testing Needs proper planning.
For an Effective Regression Testing to be done the following ingredients are necessary:
Create a Regression Test Plan: Test Plan identified Focus Areas, Strategy, Test Entry and Exit Criteria. It can also outline Testing Prerequisites, Responsibilities, etc.
Create Test Cases: Test Cases that cover all the necessary areas are important. They describe what to Test, Steps needed to test, Inputs and Expected Outputs. Test Cases used for Regression Testing should specifically cover the functionality addressed by the change and all components affected by the change. The Regression Test case may also include the testing of the performance of the components and the application after the change(s) were done.
Defect Tracking: As in all other Testing Levels and Types It is important Defects are tracked systematically, otherwise it undermines the Testing Effort.

3) Re – Testing:
It is a type of testing in which one will perform testing on the same function again and again with multiple sets of data in order to come to a conclusion whether the functionality is working fine or not.
1. Re-testing starts from the 1st build and continuous up to the last build.
2. Regression Testing starts from the 2nd build and continuous up to the test buld.
3. During Regression Testing also re-testing will be completed.

4) α - Testing:
It is a type of testing in which one (I.e., out Test Engineer) will perform user acceptance testing in our company in the presents of the customer.
Advantages:
If at all any defects are found there is a chance of rectifying them immediately.

5) Static Testing:
It is a type of testing in which one will perform testing on the application are its related factors without doing any actions.
Ex: GUI Testing, Doc Testing, Code Reviews and etc.

6) Dynamic Testing
It is a type of testing in which one will perform testing on the application are its related factors by doing some actions.
Ex: Functional Testing.

7) Installation Testing.
It is type of testing in which one will install the application in to the environment by the following guidelines provided in the deployment document in order to conform whether those guidelines are perfectly suitable for installing the application in to the environment or not.

8) Compatibility Testing
It is type of testing in which one will install the application to multiple environments prepared with different combination in order to conform whether this application is suitable with those environments or not.
This type testing is more important for products rather than the projects.

9) Monkey Testing
It is a type testing in which one will perform abnormal actions abnormal actions intentionally on the application in order to check its statements.

10) Usability Testing
It is a type of testing in which one performs testing on the user friendliness of that application.

11) Exploratory Testing
It is a type of testing in which domain experts will perform testing on the application without having the knowledge of the requirements and just by parallel exploring the functionality.

12) Port Testing
It is a type of testing in which one will install the application in to customers environment and check whether it is compatible with that environment or not.

13) End to End Testing:
End-to-end testing is similar to system testing,
It is a type of testing in which one will perform testing on all the end to end scenarios of the application.
Ex: Login to Logout of an application

14)Security Testing.
Security/penetration testing is testing how well the system is protected against unauthorized internal or external access, or willful damage. This type of testing usually requires sophisticated testing techniques.
In this the black box test engineers will do the following

1. Authentication Testing
It is a type testing in which one will enter different combinations of user names and passwords in order to conform only authorized users are accessing the application.

2. Direct URL Testing
It is a type of testing in which one will enter direct url’s of the secured pages and will try to access the application in order to check whether the application is properly protecting the secured pages.

3. Fire fall Leakage testing or user privilege testing
In this type of testing one will enter into the application as one level of user and will try to access the application beyond the user limit in order to conform the fire fall technology is working fine or not.

15) Reliability testing (or) Soak Testing.
It is a type of testing in which one will perform testing on the application continuously for long period of time in order to conform to check the stability of the application.

16) Mutation Testing
It is a type of testing in which one will perform testing or its related factors after doing some changes to them.

17) Adhoc Testing.
It is a type of testing in which the test engineers will perform the application in their own style after understanding the requirements very clearly usually this type of testing will be encouraged after formal testing.

Levels of Testing & Environment

Levels of Testing & Environment

Levels of Testing

1. Unit Testing
2. Module Level Testing
3. Integration Testing
4. System Level Testing
5. User Acceptance Testing

Unit Testing
Unit testing is the first level of dynamic testing and is first the responsibility of developers and then that of the test engineers. Unit testing is performed after the expected test results are met or differences are explainable/acceptable.

IT performs testing on a unit then that level of testing is known as unit level testing. It is white box testing usually developers perform it.

Module Level Testing

Module is defined as combination of related features to perform a major task in an application.
In this stage the Black Box test Engineers will perform testing on the functional part of the module.
Integration Testing
The primary objective of integration testing is to discover errors in the interfaces between Modules/Sub-Systems (Host & Client Interfaces).
In this stage the developers will develop the interfaces in order to integrate the modules. The white box testers will test those interfaces are working fine or not.
The developers will follow any one of the following approaches to integrate the modules
Approach:
Top-Down Approach
The integration process is performed in a series of 5 steps
The main control module is used as a test driver, and stubs are substituted for all modules directly subordinate to the main control module.
Depending on the integration approach selected ( depth or breadth-first) subordinate stubs are replaced at a time with actual modules.
Tests are conducted as each module is integrated.
One completion of each set of tests, another stub is replaced with the real-module.
Regression testing may be conducted to ensure that new errors have not been introduced.

Bottom-Up Approach.

A bottom-up integration strategy may be implemented with the following steps:
Low level modules are combined into clusters (Some time called builds) that perform a specific software sub function.
A driver ( control program for testing) is written to coordinate test case input and output.
The cluster is tested.
Drivers are removed and clusters are combined upward in the program structure

Hybrid Approach
This approach is a mixed approach of both Top down and Bottom up approaches.
Big Bang Approach
Once all the modules are ready at a time integrating them finally is known as big bang approach
System Integration Testing:
It is type of testing in which one will perform some action at one module and check for the reflections in all the related areas.
User Acceptance Testing
The same system testing done in the presents of the user is known as user acceptance testing. It is a black box testing usually done by the Test engineers.

TESTING METHODOLOGY (OR) TESTING TECHNIQUES

TESTING METHODOLOGY (OR) TESTING TECHNIQUES

There are 3 methods are there
Black Box Testing.
White Box Testing.
Gray Box Testing.

White Box Testing Methodology.
White box testing strategy deals with the internal logic and structure of the code. White box testing is also called as glass, structural, open box or clear box testing.
In order to implement white box testing, the tester has to deal with the code and hence is needed to possess knowledge of coding and logic i.e. internal working of the code. White box test also needs the tester to look into the code and find out which unit/statement/chunk of the code is malfunctioning.

Advantages of White box testing are:
i) As the knowledge of internal coding structure is prerequisite, it becomes very easy to find out which type of input/data can help in testing the application effectively.
ii) The other advantage of white box testing is that it helps in optimizing the code
iii) It helps in removing the extra lines of code, which can bring in hidden defects.

Disadvantages of white box testing are:
i) As knowledge of code and internal structure is a prerequisite, a skilled tester is needed to carry out this type of testing, which increases the cost.
ii) And it is nearly impossible to look into every bit of code to find out hidden errors, which may create problems, resulting in failure of the application.

Types of testing under White/Glass Box Testing Strategy:
Unit Testing:
The developer carries out unit testing in order to check if the particular module or unit of code is working fine. The Unit Testing comes at the very basic level as it is carried out as and when the unit of the code is developed or a particular functionality is built.

Static and dynamic Analysis:
Static analysis involves going through the code in order to find out any possible defect in the code. Dynamic analysis involves executing the code and analyzing the output.

Statement Coverage:
In this type of testing the code is executed in such a manner that every statement of the application is executed at least once. It helps in assuring that all the statements execute without any side effect.

Branch Coverage:
No software application can be written in a continuous mode of coding, at some point we need to branch out the code in order to perform a particular functionality. Branch coverage testing helps in validating of all the branches in the code and making sure that no branching leads to abnormal behavior of the application.

Security Testing:
Security Testing is carried out in order to find out how well the system can protect itself from unauthorized access, hacking – cracking, any code damage etc. which deals with the code of application. This type of testing needs sophisticated testing techniques.

Mutation Testing:
A kind of testing in which, the application is tested for the code that was modified after fixing a particular bug/defect. It also helps in finding out which code and which strategy of coding can help in developing the functionality effectively.

Besides all the testing types given above, there are some more types which fall under both Black box and White box testing strategies such as: Functional testing (which deals with the code in order to check its functional performance), Incremental integration testing (which deals with the testing of newly added code in the application), Performance and Load testing (which helps in finding out how the particular code manages resources and give performance etc.) etc.

Types of testing

Types of Black Box Testing Techniques: Following techniques are used for performing black box testing

1) Boundary Value Analysis (BVA)

2) Equivalence Class Testing

3) Decision Table based testing

4) Cause-Effect Graphing Technique

1) Boundary Value Analysis (BVA):

This testing technique believes and extends the concept that the density of defect is more towards the boundaries. This is done to the following reasons

a) Usually the programmers are not able to decide whether they have to use <= operator or < operator when trying to make comparisons.

b) Different terminating conditions of For-loops, While loops and Repeat loops may cause defects to move
around the boundary conditions.

c) The requirements themselves may not be clearly understood, especially around the boundaries, thus causing even the correctly coded program to not perform the correct way.

2) Equivalence Class Testing:
The use of equivalence classes as the basis for functional testing is appropriate in situations like

a) When exhaustive testing is desired.

b) When there is a strong need to avoid redundancy.

The above are not handled by BVA technique as we can see massive redundancy in the tables of test cases. In this technique, the input and the output domain is divided into a finite number of equivalence classes.

3) Decision Table Based Testing:

Decision tables are a precise and compact way to model complicated logic. Out of all the functional testing methods, the ones based on decision tables are the most rigorous due to the reason that the decision tables enforce logical rigour.

Decision tables are ideal for describing situations in which a number of combinations of actions are taken under varying sets of conditions.

4) Cause-Effect Graphing Technique:

This is basically a hardware testing technique adapted to software testing. It considers only the desired external behaviour of a system. This is a testing technique that aids in selecting test cases that logically relate Causes (inputs) to Effects (outputs) to produce test cases.

A “Cause” represents a distinct input condition that brings about an internal change in the system. An “Effect” represents an output condition, a system transformation or a state resulting from a combination of causes.

Like

Manual interview question

Interview Questions for Manual Testing
Questions on Bug Life cycle
What is a bug? What types of bugs do you know?
Bug is a error during execution of the program. There are two types of bugs: syntax and logical
2 What bug tracking system did you use?
Again and again, it does not matter what bug tracking system you use if you made your homework and invented the name of such or mentioned a standard one. You may say you've used proprietary bug tracking system (works especially well if you previous company was this way or another dealing with databases) or you may say Test Director, Clarify, ClearCase, VisualTest, Bugzilla, QC etc
3. What should be done after a bug is found?

The bug needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested, and determinations made regarding requirements for regression testing to check that fixes didn't create problems elsewhere. If a problem-tracking system is in place, it should encapsulate these processes. A variety of commercial problem-tracking/management software tools are available
The following are items to consider in the tracking process:

Complete information such that developers can understand the bug, get an idea of it's severity, and reproduce it if necessary.
· Bug identifier (number, ID, etc.)
· Current bug status (e.g., 'Released for Retest', 'New', etc.)
· The application name or identifier and version
· The function, module, feature, object, screen, etc. where the bug occurred
· Environment specifics, system, platform, relevant hardware specifics
· Test case name/number/identifier
· One-line bug description
· Full bug description
· Description of steps needed to reproduce the bug if not covered by a test case or if the developer doesn't have easy access to the test case/test script/test tool
· Names and/or descriptions of file/data/messages/etc. used in test
· File excerpts/error messages/log file excerpts/screen shots/test tool logs that would be helpful in finding the cause of the problem
· Severity estimate (a 5-level range such as 1-5 or 'critical'-to-'low' is common)
· Was the bug reproducible?
· Tester name
· Test date
· Bug reporting date
· Name of developer/group/organization the problem is assigned to
· Description of problem cause
· Description of fix
· Code section/file/module/class/method that was fixed
· Date of fix
· Application version that contains the fix
· Tester responsible for retest
· Retest date
· Retest results
· Regression testing requirements
· Tester responsible for regression tests
· Regression testing results

A reporting or tracking process should enable notification of appropriate personnel at various stages. For instance, testers need to know when retesting is needed, developers need to know when bugs are found and how to get the needed information, and reporting/summary capabilities are needed for managers

4. What if the software is so buggy it can't be tested at all?

In this situation the best way is to have test engineers go through the process of reporting whatever bugs or problems initially show up, with the focus being on critical bugs. Since this type of problem can severely affect schedules and indicates deeper problems in the software development process, such as insufficient unit testing, insufficient integration testing, poor design, improper build or release procedures, managers should be notified and provided with some documentation as evidence of the problem.

5. If a bug has high severity then usually that is treated as high priority,then why do priority given by test engineers/project managers and severity given by testers?
High severity bugs affects the end users ....testers tests an application with the users point of view, hence it is given as high severity. High priority is given to the bugs which affects the production. Project managers assign a high priority based on production point of view.
6. what is meant by Priority and severity?
Priority means "Importance of the defect w.r.t customer requirement"
This is assigned by the Developer.
This is to say how soon the bug as to be fixed in the main code, so that it pass the basic requirement.
Severity means "Seriousness of the defect w.r.t functionality"
This is assigned by the Test Engineer
This is to say how badly it is affecting the other modules of the build or release.
7. When a bug is found what is the 1st action?
Report it in bug tracking tool.

8. What is best bug in your current proj? Which you found??
It’s your project. You should know it
.
9. What is the bug base do you use in your comp.?
The interviewer was asking about Bug tracking tool that you use...

10. Give an example of high priority and low severity, low priority and high severity?

In user interface bugs we are giving low severity
Ex: 1) Improper right alignments (low priority)
2) Spelling mistakes (high priority)
In calculation bug we are giving high severity
Ex: 1) final output is wrong (low priority)
2) Dependent outputs are wrong (high priority)

11. Daily how many bugs will you find and what types are they?
The Bugs I find in a Day could be User Interface defect Bug, boundary related, Database Related,
Error Handling defect, calculation defect Load conditions, hardware failures, Compatibility related.

12. What are the differences between these three words Error, Defect and Bug?

Error: The deviation from the required logic, syntax or standards/ethics is called as error.

There are three types of error. They are:
Syntax error (This is due to deviation from the syntax of the language what supposed to follow).
Logical error (This is due to deviation from the logic of the program what supposed to follow)
Execution error (This is generally happens when you are executing the same program, that time you
get it.)
Defect: When an error found by the test engineer (testing department) then it is called defect

Bug: if the defect is agreed by the developer then it converts into bug, which has to fix by the developer or post point to next version.
13. If the client identified some bugs to whom did he reported?
He will report to the Project Manager. Project Manager will arrange a meeting with all the leads
(Dev. Manager, Test Lead and Requirement Manager) then raise a Change Request and then,
identify which all the screens are going to be impacted by the bug. They will take the code and
correct it and send it to the Testing Team.

14. What are the main bugs which were identified by you and in that how many are considered
as real bugs?
If you take one screen, let’s say, it has got 50 Test conditions, out of which, I have identified 5 defects
which are failed.
I should give the description defect, severity and defect classification. All the defects will be
considered.
Defect Classification are:
GRP : Graphical Representation
LOG : Logical Error
DSN : Design Error
STD : Standard Error
TST : Wrong Test case
TYP : Typographical Error (Cosmotic Error)

15. Define Defect Life Cycle
Defect life cycle includes reporting a new bug to closing a bug. It has below stages:

About Bugzilla
What is Bugzilla?
Bugzilla is a bug tracking tool or issue tracking tool.
What is the use of Bugzilla?
Bugzilla is a centralized location to keep all the bugs. More than none person can access and see the bugs. And it will give the entire change history such who as reported to whom, who has changed the status etc.
How do enter a bug in Bugzilla?
To enter a bug, through "Enter a new bug" link from the main Bugzilla page. This will take you to a product selection screen.
What happens once enter a bug?
After you enter a bug, mail is sent both to you and the QA department. A member of the QA department will verify that they can reproduce your bug.
How do search a bug?
To search a bug, through "Query" link from the main Bugzilla page.
How do submit aattachement?
The new Bugzilla system supports the attachment of patches, test cases, and various other forms of file types directly from the bug report screen. Just click on "Create an attachment"
Are cookies required in Bugzilla?
Yes.
How can you view your assigned bugs?
We can view the assigned bugs though “My Bugs” link.
How can you generate bug report?
We can generate bug report through “Report” link.
When Bugzilla was released?
Bugzilla was released in 1998.
Which language was written Bugzilla first time?
Bugzilla was originally written in "TCL".
Who developed the Bugzilla?
Terry Weissman
Which language Bugzilla written?
"Perl"
What are the Bugzilla fields?
Bugzilla have 11 fields. They are Product, Component, Version, Platform, OS, Priority, Severity, Assigned To, URL, Summary and Description.
How can you edit your account in Bugzilla?
We can use "User Preferences" link.
How can you add new Product in Bugzilla?
We can use "Product" link for adding new product.
How can you add Components of product in Bugzilla?
We can use "Components" link for adding components in Bugzilla.
How can edit version of any product in Bugzilla?
We can use "Edit Versions" link.

ppt about softwaretesting

Create a Label in gmail using TestNG framework

In this example we will create a Label in Gmail. Using TestNG framework in Selenium.

package Webdriverprgs;

import java.awt.AWTException;
import java.awt.Robot;
import java.awt.event.KeyEvent;
import java.util.List;
import java.util.concurrent.TimeUnit;
import org.openqa.selenium.By;
import org.openqa.selenium.JavascriptExecutor;
import org.openqa.selenium.Keys;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.interactions.Actions;
import org.testng.annotations.Test;
import org.testng.annotations.BeforeTest;
import org.testng.annotations.AfterTest;
import org.testng.annotations.Test;
import org.testng.annotations.BeforeTest;
import org.testng.annotations.AfterTest;

public class createlabel {
    public WebDriver driver;
    public WebElement element;
    public Robot robot;
    public Actions actions;
  @Test
  public void f() throws InterruptedException, Exception {
      driver.findElement(By.id("Email")).sendKeys("jan30selenium");
      driver.findElement(By.id("Passwd")).sendKeys("selenium1");
      driver.findElement(By.id("signIn")).click();
      Actions act=new Actions(driver);

      //Thread.sleep(20000);
      driver.manage().timeouts().implicitlyWait(20, TimeUnit.SECONDS);
      element=driver.findElement(By.xpath("html/body/div[7]/div[3]/div/div[2]/div[1]/div[1]/div[1]/div[2]"));
      actions=new Actions(driver);
      actions.moveToElement(element).build().perform();
      driver.findElement(By.xpath(".//*[@id=':j2']/span[2]/div")).click();

      WebElement element = driver.findElement(By.linkText("Create new label"));
      ((JavascriptExecutor)driver).executeScript("arguments[0].scrollIntoView(true);", element);
      Thread.sleep(500);
      driver.findElement(By.linkText("Create new label")).click();
      driver.findElement(By.cssSelector("input.xx")).sendKeys("Aditya");
      driver.findElement(By.name("ok")).click();
      
   
  }
  @BeforeTest
  public void beforeTest() {
      driver=new FirefoxDriver();
      driver.get("http://gmail.com");
      driver.manage().window().maximize();
  }

  @AfterTest
  public void afterTest() {
  }

} 

Copy this code your eclipse IDE and import the required libraries and go for test. Enjoy! Keep posting your comments.

downdown to excel

package prgs;

import java.awt.Label;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.util.List;

import jxl.Sheet;
import jxl.Workbook;
import jxl.write.WritableSheet;
import jxl.write.WritableWorkbook;

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.support.ui.Select;
import org.testng.annotations.Test;
import org.testng.annotations.BeforeTest;
import org.testng.annotations.AfterTest;

public class ebaytoexcel {
    public WebDriver driver;
    FileInputStream fi;
    Workbook w;
    Sheet s;
    FileOutputStream fo;
    WritableWorkbook  wb;
    WritableSheet so;
   
  @Test
  public void f()  throws Exception{
      driver.findElement(By.xpath("//select[@id='gh-cat']")).click();
      Thread.sleep(5000);
   
     
     List<WebElement> str1= new Select(driver.findElement(By.id("gh-cat"))).getOptions();
      System.out.println(str1.size());
   
   
     fo=new FileOutputStream("C:\\Documents and Settings\\admin\\Desktop\\eclipse\\d\\sari\\os\\ebay1.xls");
      wb=Workbook.createWorkbook(fo);
      so=wb.createSheet("abc",0);
   
      for(int i=0;i<str1.size();i++){
          System.out.println(str1.get(i).getText());
          jxl.write.Label ca=new jxl.write.Label(0,i,str1.get(i).getText());
             so.addCell(ca);
      }
   
          
     wb.write();
     wb.close();;
   
     
  }
  @BeforeTest
  public void beforeTest() {
      driver=new FirefoxDriver();
      driver.get("http://ebay.in");
  }

  @AfterTest
  public void afterTest() {
  }

}

All submenu from the menu list

package Webdriverprgs;

import java.awt.List;

import javax.swing.text.TabableView;

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.interactions.Actions;
import org.testng.annotations.Test;
import org.testng.annotations.BeforeTest;
import org.testng.annotations.AfterTest;

import com.google.common.collect.Table;

public class submenu  {
    public WebDriver driver;
  @Test
  public void f() {
      Actions act=new Actions(driver);
      WebElement str=driver.findElement(By.linkText("Series"));
      act.moveToElement(str).build().perform();
      WebElement submenu=driver.findElement(By.id("mgDdRht"));
      java.util.List<WebElement> allrows1=submenu.findElements(By.tagName("tr"));
     for(WebElement row:allrows1){
            java.util.List<WebElement> allcols = row.findElements(By.tagName("td"));
      for (WebElement col : allcols){
      System.out.println(col.getText());
      }     
      }
     
  }
  @BeforeTest
  public void beforeTest() {
      driver=new FirefoxDriver();
      driver.get("http://www.espncricinfo.com/");
      driver.manage().window().maximize();
     
  }

  @AfterTest
  public void afterTest() {
  }

}

Display All Menu Items

package Webdriverprgs;

import java.awt.List;
import java.util.concurrent.TimeUnit;

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.interactions.Actions;
import org.testng.annotations.Test;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.AfterMethod;

public class displayallmenuitems {
    WebDriver driver;
   
  @Test
  public void f() {
   
 
      //int size=driver.findElements(By.xpath("//a[@class='NavLink']")).size();//to write our own xpath
      int size=driver.findElements(By.className("NavLink")).size();
      System.out.println("No of Main Menu's are "+ size );
      for (int i=1;i<size+1;i++){
      String xpath= "(//a[@class='NavLink'])[" + i + "]";
      // System.out.println("Xpath is" + xpath);
      System.out.println("Main Menu " + i+" is" + driver.findElement(By.xpath(xpath)).getText());
              }
  }
  @BeforeMethod
  public void beforeMethod() {
 
  driver=new FirefoxDriver();
  driver.get("http://www.espncricinfo.com/");
driver.manage().window().maximize();
  }

  @AfterMethod
  public void afterMethod() {
  }

}

About Manual Testing

Why Software Testing  is necessary

Software Testing is necessary because we all make mistakes. Some of those mistakes are unimportant, but some of them are expensive or dangerous. We need to check  everything and anything we produce because things can always go wrong – humans make mistakes all the time. 

Since we assume that our work may have mistakes, hence we all need to check our own work. However some mistakes come from bad assumptions and blind spots, so we might make the same mistakes when we check our own work as we made when we did it. So we may not notice the flaws in what we have done.

 Ideally, we should get someone else to check our work because another person is more likely to spot the flaws.

There are several reasons which clearly tells us as why Software  Testing is important and what are the major things that we should consider while testing of any product or application.

Software testing is very important because of the following reasons:

1.    Software testing is really required to point out the defects and errors that were made during the development phases.

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

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

4.    Testing is necessary in order to provide the facilities to the customers like the delivery of high quality product or software application which requires lower maintenance cost and hence results into more accurate, consistent and reliable results.

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

6.    It’s important to ensure that the application should not result into any failures because it can be very expensive in the future or in the later stages of the development.

7.    It’s required to stay in the business.

What is software testing?

Software Testing is the process of executing a program or system with the intent of finding errors. 

Software testing is the process used to help identify the Correctness, Completeness, Security and Quality of the developed Computer Software 

(OR) 

The process of evaluating the software application or program to find the difference between the actual results to the expected result.

Software testing has three main purposes:

1. Verification
2. Validation and
3. Defect finding.

The verification process confirms that the software meets its technical specifications and user requirements. It's a Process based application. 

The Defect is a variance between the expected and actual result. The defect's ultimate source may be traced to a fault introduced in the specification, design, or development (coding) phases. 

Describe the difference between validation and verification

Verification is done by frequent evaluation and meetings to appraise the documents, policy, code, requirements, and specifications. This is done with the checklists, walkthroughs, and inspection meetings.

Validation is done during actual testing and it takes place after all the verifications are being done.

Difference between Test case and Use case?

Use cases are prepared by business analysts from the functional requirement analysis (FRS) according to the user requirements.

Test case are prepared by Test Engineer based on the use case. The test case is a set procedure that guides a tester to execute a test.

Testing Methodology?

Means what kind of approach is following while testing (e.g.) functional testing, Regression testing, Retesting, Confirmation testing.

Exploratory Testing:

With out the knowledge of requirements, testing is done by giving random inputs.

Ad-Hoc testing:

Testing without a formal test plan or outside of a test plan. 

Bug life cycle:

It has the following life cycle such as:

• New: When the bug is posted for the first time is called new.
• Open: After the tester sends the bug, the lead checks if it genuine then it is called as open.
• Assign: After the lead checks, he assigns to the developer and that state is called assign.
• Test: Before the developer releases the software with bug fixed, he changes the state of bug to "TEST".
• Fixed: When the developer resolved the bug the status is fixed.
• Reopen: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to reopen.
• Closed: If the bug is no more the status is closed.Test plan:
  
  Test plan specifies process and scheduling of an application. Test lead 
  Prepares test plan document based on what to test, how to test, when to test, whom to test. It covers the entire testing activity.
  
  SRS: 
  
  Software requirement specification (SRS). It describes what the software will do and how it will be expected to perform.
  
  Requirement Traceability Matrix (RTM):
  
  It is the mapping between customer requirements and prepared test cases. This is used to find whether all the requirements are covered or not.
  
  Different Levels of testing?
  • Unit Testing
  • Integrated Testing
  • System Testing
  • Acceptance Testing
  Unit Testing = (Testing the individual modules)
  
  The testing done to a unit or to a smallest piece of software. Done to verify if it satisfies its functional specification or its intended design structure.
  The Tools used in Unit Testing are debuggers, tracers and is done by Programmers.
  
  Integration Testing
  
  Testing the related modules together for its combined functionality.
  
  System Testing
  
  System testing of software or hardware is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic.
  
  Testing the software for the required specifications.
  
  System integration testing
  
  System integration testing is the process of verifying the synchronization between two or more software systems and which can be performed after software system collaboration is completed.
  
  User Acceptance Testing = (It the testing done with the intent of conforming readiness of the product and Customer acceptance.)
  
  Testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. It is done against requirements and is done by actual users. 
  
  Acceptance Testing: 
  
  Formal testing conducted to determine whether or not a system satisfies its acceptance criteria, which enables a customer to determine whether to accept the system or not.
  
  Compatibility testing
  
  Compatibility testing, part of software non-functional tests, is testing conducted on the application to evaluate the application's compatibility with the computing environment. Computing environment may contain some or all of the below mentioned elements:
  • Computing capacity of Hardware Platform (IBM 360, HP 9000, etc.)
  • Bandwidth handling capacity of networking hardware
  • Compatibility of peripherals (Printer, DVD drive, etc.)
  • Operating systems (MVS, UNIX, Windows, etc.)
  • Database (Oracle, Sybase, DB2, etc.)
  • Other System Software (Web server, networking/ messaging tool, etc.)
  • Browser compatibility (Firefox, Netscape, Internet Explorer, Safari, etc.)
  Installation Testing
  
  System testing conducted once again according to hardware configuration requirements. Installation procedures may also be verified 
  
  Functional Testing
  
  It checks that the functional specifications are correctly implemented. Can also check if Non Functional behavior is as per expectations. 
  
  Stress testing
  
  To evaluate a system beyond the limits of the specified requirements or system resources (such as disk space, memory, processor utilization) to ensure the system do not break unexpectedly
  
  Load Testing
  
  Load Testing, a subset of stress testing, verifies that a web site can handle a particular number of concurrent users while maintaining acceptable response times.
  
  Scalability Testing is used to check whether the functionality and performance of a system are capable to meet the volume and size change as per the requirements.
  
  Scalability testing can be done using load test with various software and hardware configurations changed, where the testing environment settings unchanged.
  
  Regression Testing = (Testing the application to find whether the change in code affects anywhere in the application)
  
  Regression Testing is "selective retesting of a system or component to verify that modifications have not caused unintended effects". It is repetition of tests intended to show that the software's behavior is unchanged. It can be done at each test level. 
  
  Performance Testing
  
  To evaluate the time taken or response time of the system to perform it's required functions in comparison
  
  ALPHA TESTING: Testing is done near the completion of project.
  
  Testing of a software product or system conducted at the developer's site by the customer
  
  BETA TESTING: Testing is done after the completion of project. 
  
  Testing conducted at one or more customer sites by the end user of a delivered software product system.
  
  Usability Testing = (Testing the ease with which users can learn and use a product.)
  Usability testing is a technique used to evaluate a product by testing it on users. This can be seen as an irreplaceable usability practice, since it gives direct input on how real users use the system. This is in contrast with usability inspection methods where experts use different methods to evaluate a user interface without involving users.
  
  OR
  
  It evaluates the Human Computer Interface. Verifies for ease of use by end-users. Verifies ease of learning the software, including user documentation. Checks how effectively the software functions in supporting user tasks. Checks the ability to recover from user errors.
  
  Data Flow Testing 
  
  Selects test paths according to the location of definitions and use of variables. 
  
  1.2.3 Loop Testing 
  
  Loops fundamental to many algorithms. Can define loops as simple, concatenated, nested, and unstructured. 
  
  Examples:
  
  
  Note that unstructured loops are not to be tested. Rather, they are redesigned.
  
  Configuration Testing
  
  It is used when software meant for different types of users. It also checks that whether the software performs for all users. 
  
  Recovery Testing
  
  It is used in verifying software restart capabilities after a "disaster" 
  
  OR
  
  Recovery testing is the activity of testing how well an application is able to recover from crashes, hardware failures and other similar problems.
  
  Examples of recovery testing:
  1. While an application is running, suddenly restart the computer, and afterwards check the validness of the application's data integrity.
  2. While an application is receiving data from a network, unplug the connecting cable. After some time, plug the cable back in and analyze the application's ability to continue receiving data from the point at which the network connection disappeared.
  3. Restart the system while a browser has a definite number of sessions. Afterwards, check that the browser is able to recover all of them.
  Security Testing
  
  Security testing is a process to determine that an information system protects data and maintains functionality as intended.
  
  OR
  
  Security testing is the process that determines that confidential data stays confidential
  
  OR
  
  Testing how well the system protects against unauthorized internal or external access, willful damage, etc?
  
  This process involves functional testing, penetration testing and verification.
  • Test Plan: Test Plan is a document with information on Scope of the project, Approach, Schedule of testing activities, Resources or Manpower required, Risk Issues, Features to be tested and not to be tested, Test Tools and Environment Requirements.
     
  • Test Strategy: Test Strategy is a document prepared by the Quality Assurance Department with the details of testing approach to reach the Quality standards.
     
  • Test Scenario: Test Scenario is prepared based on the test cases and test scripts with the sequence of execution.
     
  • Test Case: Test case is a document normally prepared by the tester with the sequence of steps to test the behavior of feature/functionality/non-functionality of the application. Test Case document consists of Test case ID, Test Case Name, Conditions (Pre and Post
    Conditions) or Actions, Environment, Expected Results, Actual Results, Pass/Fail. The Test cases can be broadly classified as User Interface Test cases, Positive Test cases and Negative Test cases.
     
  • Test Script: Test Script is a program written to test the functionality of the application. It is a set of system readable instructions to automate the testing with the advantage of doing repeatable and regression testing easily.
    
    Test Environment: It is the Hardware and Software Environment where the testing is going to be done. It also explains whether the software under test interacts with Stubs and Drivers.
     
  • Test Procedure: Test Procedure is a document with the detailed instruction for step by step execution of one or more test cases. Test procedure is used in Test Scenario and Test Scripts.
     
  • Test Log: Test Log contains the details of test case execution and the output information.
  What is Fuzz Testing?
  
  Fuzz testing is a Black box testing technique which uses random bad data to attack a program and see what breaks in the application.
  Fuzz testing is mostly used to,
  • Set up a correct file to enter your program
  • Restore some part of the file by using random data
  • Unlock the file with the program
  • Observe what breaks
  Fuzz testing can be automated for maximum effects on large applications. This testing improves the confidence that the application is safe and secure.
  
  Testing strategy:
  1. Black box testing
  2. White box testing
  3. Gray box testing
  Black box testing:
  
  Testing of application without the knowledge of coding. Black box testing (BBT) is also called as Functional testing.
  
  White box testing:
  
  Testing of application with the knowledge of coding to examine outputs.
  
  White box testing (WBT) is also called Structural or Glass box testing.
  
  White box testing involves looking at the structure of the code. When you know the internal structure of a product, tests can be conducted to ensure that the internal operations performed according to the specification. And all internal components have been adequately exercised.
  
  Gray box testing:
  
  It is like monkey testing.
  
  Static: Verifying the documents alone.
  Dynamic: Testing the functionality.
  
  Software testing lifecycle:
  • Requirements gathering: Collecting the project related information.
  • Analyzing: Discussing the collected information whether the requirements can meet.
  • Test plan preparation: It specifies the entire testing activity
  • Test case preparation: It is a document which contains input and corresponding results.
  • Test case execution: Execution of test case results to find bugs
  • Bug Tracking: Monitoring of the bug till closed.
  • Regression testing: Testing the application to find whether the change in code affect anywhere in the application.
  WHAT IS MEAN BY DESIGNING THE APPLICATION AND TESTING THE APPLICATION?
  
  Designing and Testing are two different phases in a software development process (SDLC).
  1. Information Gathering
  2. Analysis
  3. Designing
  4. Coding
  5. Testing
  6. Implementation and Maintenance
  If u want answer in Testing terms means STLC, designing test includes preparing Test Strategy, Test Plan and Test Case documents, and testing means executing the test cases and generating Test Reports.
  
  Designing the application as per the requirements Designing the application is nothing but deriving the functional flow, alternative flow, How many modules that we are handling, data flow etc.
  
  Two types of designs are there:
  
  LLD - Low Level Design Documentation : This level deals with lower level modules. The flow of diagram handled here is data Flow Diagram. Developers handle this Level. 
  
  In this designing team will divide the total application into modules and they will derive logic for each module.
  
  HLD - High Level Design Documentation: This level deals with higher level modules. The flow of diagram handled here is ER - Entity Relationship. Both Developers and Testers handle this Level.
  
  In this designing team will prepare functional architecture i.e. Functional flow.
  
  Coding: writing the source code as per the LLD to meet customer requirements.

DIFFERENCE B/W SMOKE & SANITY TESTING:

SMOKE TESTING:

• Set of the test cases which we getting a new build when we execute the application.
• Smoke testing is verified whether the build is testable or not.
• Testers can reject the application.

SANITY TESTING:

• It is also a set of test cases which is testing major and critical functionality of the application.
• It is one time testing process.

What is Smoke Testing?

A quick-and-dirty test that the major functions of a piece of software work. Originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire. 

Skim Testing:

Skim Testing A testing technique used to determine the fitness of a new build or release.

Mutation testing: (or Mutation analysis or Program mutation) is a method of software testing, which involves modifying programs' source code or byte code in small ways.[1] A test suite that does not detect and reject the mutated code is considered defective. These so-called mutations, are based on well-defined mutation operators that either mimic typical programming errors (such as using the wrong operator or variable name) or force the creation of valuable tests (such as driving each expression to zero). The purpose is to help the tester develop effective tests or locate weaknesses in the test data used for the program or in sections of the code that are seldom or never accessed during execution.

What is Branch Testing? 

Testing in which all branches in the program source code are tested at least once. 

What is security testing 

testing how well the system protects against unauthorized internal or external access, willful damage, etc? 

OR

Security testing is the process that determines that confidential data stays confidential

How do you debug an ASP.NET Web application? 

Attach the aspnet_wp.exe process to the DbgClr debugger. 

What is Backus-Naur Form? 

A Meta language used to formally describe the syntax of a language. 

Difference between Test Efficiency Vs Test Effectiveness 

I've seen that many test engineers are confused with the understanding of Software Test Efficiency and Software Test Effectiveness. Below is the summary of what I understand from Efficiency and Effectiveness.

Software Test Efficiency:

1. It is internal in the organization how much resources were consumed how much of these resources were utilized.
2. Software Test Efficiency is number of test cases executed divided by unit of time (generally per hour).
3. Test Efficiency test the amount of code and testing resources required by a program to perform a particular function.

Here are some formulas to calculate Software Test Efficiency (for different factors):

• Test efficiency = (total number of defects found in unit+integration+system) / (total number of defects found in unit+integration+system+User acceptance testing).
• Testing Efficiency = (No. of defects Resolved / Total No. of Defects Submitted)* 100

Software Test Effectiveness:

Software Test Effectiveness covers three aspects:

• How much the customer's requirements are satisfied by the system.
• How well the customer specifications are achieved by the system.
• How much effort is put in developing the system.

Software Test Effectiveness judge the Effect of the test environment on the application.

Here are some formulas to calculate Software Test Effectiveness (for different factors):

• Test effectiveness = Number of defects found divided by number of test cases executed.
• Test effectiveness = (total number of defects injected +total number of defect found) / (total number of defect escaped)* 100
• Test Effectiveness = Loss due to problems / Total resources processed by the system

What is quality assurance?

Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention'.

What is the difference between QA and testing?

Testing involves operation of a system or application under controlled conditions and evaluating the results. It is oriented to 'detection'.

Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention'.

FRONT END & BACKEND TESTING

Front end testing is testing GUI and functionality.

Back-end focuses on data stored in the database.

WHAT IS SOAK TESTING

Running a system at high load for a prolonged period of time. For example, running several times more transactions in an entire day (or night) than would be expected in a busy day, to identify and performance problems that appear after a large number of transactions have been executed.

Describe the Software Development Life Cycle

It includes aspects such as initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, retesting, phase-out, and other aspects.

What is a Test bed?

Test Bed is an execution environment configured for software testing. It consists of specific hardware, network topology, Operating System, configuration of the product to be under test, system software and other applications. The Test Plan for a project should be developed from the test beds to be used.

What is a Test data?

Test Data is that run through a computer program to test the software. Test data can be used to test the compliance with effective controls in the software.

Why does software have bugs?

Miscommunication or no communication about the details of what an application should or shouldn't do

Programming errors in some cases the programmers can make mistakes.

Changing requirements there are chances of the end-user not understanding the effects of changes, or may understand and request them anyway to redesign, rescheduling of engineers, effects of other projects, work already completed may have to be redone or thrown out.

Time force - preparation of software projects is difficult at best, often requiring a lot of guesswork. When deadlines are given and the crisis comes, mistakes will be made.

What is the Difference between Bug, Error and Defect?

• Bug: It is found in the development environment before the product is shipped to the respective customer.
• Defect: It is found in the product itself after it is shipped to the respective customer's
• Error: It is the Deviation from actual and the expected value.

Difference between defect, error, bug, failure and fault

• Error: A discrepancy between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition. See: anomaly, bug, defect, exception, and fault.
• Failure: The inability of a system or component to perform its required functions within specified performance requirements. See: bug, crash, exception, fault.
• Bug: A fault in a program which causes the program to perform in an unintended or unanticipated manner. See: anomaly, defect, error, exception, fault.
• Fault: An incorrect step, process, or data definition in a computer program which causes the program to perform in an unintended or unanticipated manner. See: bug, defect, error, exception.
• Defect: Mismatch between the requirements.

What is the difference between structural and functional testing?

Structural testing is a "white box" testing and it is based on the algorithm or code.

Functional testing is a "black box" (behavioral) testing where the tester verifies the functional specification.

Describe bottom-up and top-down approaches

• Bottom-up approach: In this approach testing is conducted from sub module to main module, if the main module is not developed a temporary program called DRIVERS is used to simulate the main module.
• Top-down approach: In this approach testing is conducted from main module to sub module. If the sub module is not developed a temporary program called STUB is used for simulate the sub module.

What is Re- test? What is Regression Testing?

Re-test - Retesting means we testing only the certain part of an application again and not considering how it will effect in the other part or in the whole application.

Regression Testing - Testing the application after a change in a module or part of the application for testing that is the code change will affect rest of the application.

Explain Load, Performance and Stress Testing with an Example.

Load Testing and Performance Testing are commonly said as positive testing where as Stress Testing is said to be as negative testing.

Say for example there is an application which can handle 25 simultaneous user logins at a time. In load testing we will test the application for 25 users and check how application is working in this stage, in performance testing we will concentrate on the time taken to perform the operation. Where as in stress testing, we will test with more users than 25 and the test will continue to any number and we will check where the application is cracking.

What is UAT testing? When it is to be done?

UAT stands for 'User acceptance Testing. This testing is carried out with the user perspective and it is usually done before the release.

1. Every System Menu should have Exit/close option.
2. OK and Cancel Buttons should exist.
3. All labels should start with capital alphabets.
4. Alignment of all controls must be same.
5. All controls must be visible.
6. All labels must not overlap

The above six are called as Microsoft six rules standard for user Interface testing. These are very important in GUI testing.

What is Vulnerability Testing?

In computer security, the term "vulnerability is a weakness which allows an attacker to reduce a system's Information Assurance". Vulnerability is the intersection of three elements: a system susceptibility or flaw, attacker access to the flaw, and attacker capability to exploit the flaw. To be vulnerable, an attacker must have at least one applicable tool or technique that can connect to a system weakness. In this frame, vulnerability is also known as the attack surface.

A security risk may be classified as vulnerability. Vulnerability with one or more known instances of working and fully-implemented attacks is classified as an exploit. The window of vulnerability is the time from when the security hole was introduced or manifested in deployed software, to when access was removed, a security fix was available/deployed, or the attacker was disabled.

DIFFERENCE BETWEEN FUNCTIONAL TESTING AND GUI FUNCTIONAL TESTING?

• Functional Testing: Testing the functionality of the Application i.e., (suppose click on login button in login screen it goes to next page or not)
• GUI Functional Testing: Testing the GUI objects along with Functionality.

GUI testing or UI testing is user interface testing. That is, testing how the application and the user interact. This includes how the application handles keyboard and mouse input and how it displays screen text, images, buttons, menus, dialog boxes, icons, toolbars and more.

Functional Testing is done with the intent to identify errors related to the functionality of the Application under test. 

WHAT IS GUI TESTING?

To check whether all the functionalities are working properly or not. It is simply we can say Look And Feel.

In Security testing, what does u mean by:

1. Encryption
2. Authentication
3. Authorization

Encryption: Encryption is the conversion of data into a form, called a cipher text that cannot be easily understood by unauthorized people. 

Authentication: It is the process of establishing the claimed identity of an individual, a device, an object, a system, a component or a process; that claims to be.

Authorization: It is a process of granting access rights to an individual, a device, an object, a system, a component or a process over finite resources for a specific period of time.

Localization testing and internationalization testing are comes into black box testing or white box testing