Escolar Documentos
Profissional Documentos
Cultura Documentos
If there are a lot of bugs to be fixed, which one would you resolve first ?
Based on the severity and priority of the bug we try to fix bugs.
If the Priority of the bug is Critical, it is to be resolved first.
Then the bugs of high priority, and then finally the bugs of low Priority need to be fixed.
What is Error, Bug & Defect?
If their is any mistake in coding then it is called Error.
If the same error is found by a tester while testing then it is called Bug.
If same bug is given to developer to fix it then it is called Defect.
Testers identified a issues called defect
If developers accepts and workout that issues its called Bug
Equivalence Testing
This method divides the input domain of a program into classes of data from which test cases can be derived. Equivalence partitioning strives to define a test case that uncovers classes of errors
and thereby reduces the number of test cases needed. It is based on an evaluation of equivalence classes for an input condition. An equivalence class represents a set of valid or invalid states for
input conditions.
1. If an input condition specifies a range, one valid and two invalid equivalence classes are defined.
2. If an input condition requires a specific value, then one valid and two invalid equivalence classes are defined.
3. If an input condition specifies a member of a set, then one valid and one invalid equivalence class are defined.
4. If an input condition is Boolean, then one valid and one invalid equivalence class are defined.
1. Good test case reduces by more than one the number of other test cases which must be developed
2. Good test case covers a large set of other possible cases
3. Classes of valid inputs
4. Classes of invalid inputs
Boundary testing
This method leads to a selection of test cases that exercise boundary values. It complements equivalence partitioning since it selects test cases at the edges of a class. Rather than focusing on
input conditions solely, BVA derives test cases from the output domain also.
For input ranges bounded by a and b, test cases should include values a and b and just above and just below a and b respectively.
If an input condition specifies a number of values, test cases should be developed to exercise the minimum and maximum numbers and values just above and below these limits.
Q: What is TestDirector?
TestDirector is a test management tool produced by Mercury Interactive. Its four modules - Requirements, Test Plan, Test Lab and Defects Manager - are integrated to enable information to flow
smoothly between different stages of the testing process. Completely Web-enabled, TestDirector supports communication and collaboration among distributed testing teams.
TestDirector has been classified in the following categories:
Defect Tracking
Testing and Analysis
Debugging
Automated Software Quality (ASQ)
Q: After creating the test cases in excel and exported to TD. How does test director know the headings?
To export the test cases from spreadsheet to TD there are 8 steps. In 6th step we need to map the Td fields with corresponding Spreadsheet columns. Hence you are the mapping so you can map
according to your specifications.
Q: TD (Quality Center 9.0) how can you run automated test cases?
While designing your test steps in QC for automation tests in test plan module, Test Script tab is availble. You can generate script here or copy from your automatioon tool. While running your
tests, it will ask for on which host you want to run. You need to select the system in your network. Then run it. Before going to run your script in a system, the automation tool, like WinRunner,
must be installed on that system. Otherwise you will get an error.
Q: Can we add user defined fields to Test Director?
Yes. We can add the user defined fields using TD 8.0, But you need to have admin priviliges to this.
Example:
FilePath = GetAttachment("test.pdf", "C:")
MsgBox "Your file is here:" & FilePath
The GetAttachmentFromTest finds the attachment associated to the given test name and stores it in a local folder.
Example:
FilePath = GetAttachmentFromTest("Attachment", "hello.vbs", "C:aa")
MsgBox "Your file is here:" & FilePath
The database structure in TD is mapping testcase to defects, only if you have created the bug from the apr. test case. Maybe you can update the mapping by using some code in the bug script
module (from the customize project funktion), as fare as I know, its not possible to map defects directly to an req.
Q: Can we export the files from Test director to Excel Sheet? If yes then how?
Design tab -- Right click -> go to save as -> select excel and save it
Requirement tab -- Right click on main req/ click on export/ save as word, excel or other template. This would save all the child requirement.
Test plan tab-- only individual test can be exported. No parent--child export is possible.Select a test script. click on the design steps tab. right click anywhere on the open window. click on export
and save as....
Test lab tab-- select a child group. Click on execution grid if it is not selected. right click anywhere . default save option is excel. but can be saved in doc and other formats. select 'all' or 'selected'
option.
defects tab -- right click anywhere on the window, export all or 'selected' defects and save excel sheet or document.
Q: Can we upload test cases from an excel sheet into Test Director?
Yes, you can do that. Go to Add In menu in TestDirector, find the Excel add in, and install it in you machine. Now open excel, you can find the new menu option export to Test director. Rest of
the procedure is self explanatory
Q: How can we map a single defect to two test scripts? Is there a way in test director so that we can state that defect defect X is same for test script A and test script B?
No way. When you run a script, you find and generate a defect report. In other words, every defect report is unique to a single test script.
Q: How can we create our own Defect Template from Test Director? Is it possible in Test Director? If possible how we can Create our Own Template?
You can not create your own template for defect reporting in Test Director but you can customize the Template in Test Director
An2:
The generation of graphs in the Test Director that to Test Lab module is :
1. Analysis
2. Graph
3. Graph Wizard
4.Select the graph type as Summary and click the Next button.
5.Select the show current tests and click the next button.
6.Select the Define a new filter and click the Filter button.
7. Select the test set and click the Ok button.
8.Select the Plan : subject and click the ok button.
9. Select the Plan: Status
10 Select the test set as x- Axis
11. Click the Finish button.
Q: What is the difference between Master test plan and test plan??
Master test plan is the doccumaent in which each and every functional point is validated.
Test case docuument contains test cases, Test case is the perception with which probability of finding the defect is more.
Q: How will you generate the defect ID in test director? Is it generated automatically or not?
The Defect ID will be generated automatically after the submission of the defect..
Q: How do you ensure that there are no duplication of bugs in Test Director?
In the defect tracking window, at the top we can see the find similar defect icon. If we click after writing our defect, if any of the tester already added the similar defect it will tell. Else we can
add.
It provides the snapshots of your application as it appeared when you performed a certain steps during recording session.
It provides graphical representation of your operations which you have performed with your application.
ERP/ CRM
Java/ J2EE
VB, .NET
Multimedia, XML
Web Objects, ActiveX controls
SAP, Oracle, Siebel, PeopleSoft
Web Services, Terminal Emulator
IE, NN, AOL
F3
F5
F4
Ctrl+Shift+F4
Ctrl+Shift+F3
20. Which keyword used for switch between Tree View and Expert View ?
Ctrl+Tab
You can measure how long it takes to run a section of your test by defining transactions.
You can view the results of the checkpoints in the Test Result Window.
Standard Checkpoints checks the property value of an object in your application or web page.
Image Checkpoint check the value of an image in your application or web page.
Bitmap Checkpoint checks the bitmap images in your web page or application.
Text Checkpoint checks that a test string is displayed in the appropriate place in your application or on web page.
Severity levels
Severity level:
The degree of impact the issue or problem has on the project. Severity 1 usually means the highest level requiring immediate attention. Severity 5 usually represents a documentation defect of
minimal impact.
Severity levels:
* High: A major issue where a large piece of functionality or major system component is completely broken. There is no workaround and testing cannot continue.
* Medium: A major issue where a large piece of functionality or major system component is not working properly. There is a workaround, however, and testing can continue.
* Low: A minor issue that imposes some loss of functionality, but for which there is an acceptable and easily reproducible workaround. Testing can proceed without interruption.
Priority is Relative: the priority might change over time. Perhaps a bug initially deemed P1 becomes rated as P2 or even a P3 as the schedule draws closer to the release and as the test team finds
even more heinous errors. Priority is a subjective evaluation of how important an issue is, given other tasks in the queue and the current schedule. It’s relative. It shifts over time. And it’s a
business decision.
Severity is an absolute: it’s an assessment of the impact of the bug without regard to other work in the queue or the current schedule. The only reason severity should change is if we have new
information that causes us to re-evaluate our assessment. If it was a high severity issue when I entered it, it’s still a high severity issue when it’s deferred to the next release. The severity hasn’t
changed just because we’ve run out of time. The priority changed.
S1 - Urgent/Showstopper. Like system crash or error message forcing to close the window.
Tester's ability to operate the system either totally (System Down), or almost totally, affected. A major area of the users system is affected by the incident and it is significant to business
processes.
S2 - Medium/Workaround. Exist like when a problem is required in the specs but tester can go on with testing. Incident affects an area of functionality but there is a work-around which negates
impact to business process. This is a problem that:
a) Affects a more isolated piece of functionality.
b) Occurs only at certain boundary conditions.
c) Has a workaround (where "don't do that" might be an acceptable answer to the user).
d) Occurs only at one or two customers. or is intermittent
S3 - Low. This is for minor problems, such as failures at extreme boundary conditions that are unlikely to occur in normal use, or minor errors in
layout/formatting. Problems do not impact use of the product in any substantive way. These are incidents that are cosmetic in nature and of no or very low impact to business processes.
What is stub?
Stub is a dummy program or component, the code is not ready for testing, it's used for testing that means, in a project if there are 4 modules and last is remaining and there is no time then we will
use dummy program to complete that fourth module and we will run whole 4 modules also. The dummy program is also known as stub.
1) Functionality Testing
2) Usability testing
3) Interface testing
4) Compatibility testing
5) Performance testing
6) Security testing
1) Functionality Testing:
Test for - all the links in web pages, database connection, forms used in the web pages for submitting or getting information from user, Cookie testing.
Check all the links:
• Test the outgoing links from all the pages from specific domain under test.
• Test all internal links.
• Test links jumping on the same pages.
• Test links used to send the email to admin or other users from web pages.
• Test to check if there are any orphan pages.
• Lastly in link checking, check for broken links in all above-mentioned links.
Forms are the integral part of any web site. Forms are used to get information from users and to keep interaction with them. So what should be checked on these forms?
• First check all the validations on each field.
• Check for the default values of fields.
• Wrong inputs to the fields in the forms.
• Options to create forms if any, form delete, view or modify the forms.
Let’s take example of the search engine project currently I am working on, In this project we have advertiser and affiliate signup steps. Each sign up step is different but dependent on other steps.
So sign up flow should get executed correctly. There are different field validations like email Ids, User financial info validations. All these validations should get checked in manual or automated
web testing.
Cookies testing:
Cookies are small files stored on user machine. These are basically used to maintain the session mainly login sessions. Test the application by enabling or disabling the cookies in your browser
options. Test if the cookies are encrypted before writing to user machine. If you are testing the session cookies (i.e. cookies expire after the session’s ends) check for login sessions and user stats
after session end. Check effect on application security by deleting the cookies. (I will soon write separate article on cookie testing)
2) Usability Testing:
Navigation means how the user surfs the web pages, different controls like buttons, boxes or how user using the links on the pages to surf different pages.
Usability testing includes:
Web site should be easy to use. Instructions should be provided clearly. Check if the provided instructions are correct means whether they satisfy purpose.
Main menu should be provided on each page. It should be consistent.
Content checking:
Content should be logical and easy to understand. Check for spelling errors. Use of dark colors annoys users and should not be used in site theme. You can follow some standards that are used for
web page and content building. These are common accepted standards like as I mentioned above about annoying colors, fonts, frames etc.
Content should be meaningful. All the anchor text links should be working properly. Images should be placed properly with proper sizes.
These are some basic standards that should be followed in web development. Your task is to validate all for UI testing
Like search option, sitemap, help files etc. Sitemap should be present with all the links in web sites with proper tree view of navigation. Check for all links on the sitemap. “Search in the site”
option will help users to find content pages they are looking for easily and quickly. These are all optional items and if present should be validated.
3) Interface Testing:
4) Compatibility Testing:
Compatibility of your web site is very important testing aspect. See which compatibility test to be executed:
• Browser compatibility
• Operating system compatibility
• Mobile browsing
• Printing options
Browser compatibility:
In my web-testing career I have experienced this as most influencing part on web site testing. Some applications are very dependent on browsers. Different browsers have different configurations
and settings that your web page should be compatible with. Your web site coding should be cross browser platform compatible. If you are using java scripts or AJAX calls for UI functionality,
performing security checks or validations then give more stress on browser compatibility testing of your web application. Test web application on different browsers like Internet explorer,
Firefox, Netscape navigator, AOL, Safari, Opera browsers with different versions.
OS compatibility:
Some functionality in your web application is may not be compatible with all operating systems. All new technologies used in web development like graphics designs, interface calls like
different API’s may not be available in all Operating Systems. Test your web application on different operating systems like Windows, Unix, MAC, Linux, Solaris with different OS flavors.
Mobile browsing:
This is new technology age. So in future Mobile browsing will rock. Test your web pages on mobile browsers. Compatibility issues may be there on mobile.
Printing options:
If you are giving page-printing options then make sure fonts, page alignment, page graphics getting printed properly. Pages should be fit to paper size or as per the size mentioned in printing
option.
5) Performance testing:
Web application should sustain to heavy load. Web performance testing should include:
Stress testing: Generally stress means stretching the system beyond its specification limits. Web stress testing is performed to break the site by giving stress and checked how system reacts to
stress and how system recovers from crashes.
Stress is generally given on input fields, login and sign up areas.
In web performance testing web site functionality on different operating systems, different hardware platforms is checked for software, hardware memory leakage errors.
6) Security Testing: