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