Crop center and resize paperclip image attachment
has_attached_file :profile_image,
storage: :s3,
s3_credentials: {
bucket: Settings.s3_bucket_name,
access_key_id: Settings.aws_access_key_id,
secret_access_key: Settings.aws_secret_access_key
},
default_url: '/assets/default_profile_pic.png',
styles: { square_50: '', square_100: '', square_193: '' },
convert_options: {
square_50: '-gravity center -resize 50x50^ -crop 50x50+0+0',
square_100: '-gravity center -resize 100x100^ -crop 100x100+0+0',
square_193: '-gravity center -resize 193x193^ -crop 193x193+0+0'
}
Date Time Format In RUBY
Format meaning:
%a – The abbreviated weekday name (“Sun”)
%A – The full weekday name (“Sunday”)
%b – The abbreviated month name (“Jan”)
%B – The full month name (“January”)
%c – The preferred local date and time representation
%d – Day of the month (01..31)
%H – Hour of the day, 24-hour clock (00..23)
%I – Hour of the day, 12-hour clock (01..12)
%j – Day of the year (001..366)
%m – Month of the year (01..12)
%M – Minute of the hour (00..59)
%p – Meridian indicator (“AM” or “PM”)
%S – Second of the minute (00..60)
%U – Week number of the current year,
starting with the first Sunday as the first
day of the first week (00..53)
%W – Week number of the current year,
starting with the first Monday as the first
day of the first week (00..53)
%w – Day of the week (Sunday is 0, 0..6)
%x – Preferred representation for the date alone, no time
%X – Preferred representation for the time alone, no date
%y – Year without a century (00..99)
%Y – Year with century
%Z – Time zone name
%% – Literal “%” character
t = Time.now
t.strftime(“Printed on %m/%d/%Y”) #=> “Printed on 27/11/2012”
t.strftime(“at %I:%M%p”) #=> “at 11:06AM”
Get current page URL webdriver 2.0
Get the URL of the current page
@driver.current_url
Install ImageMagick in CentOS
Install ImageMagick in CentOS
$yum install ImageMagick-devel
Elements Locators in Selenium Ruby webdriver
Disable Firewall CentOS / RHEL / RedHat
First login as the root user.
Next enter the following three commands to disable firewall.
# service iptables save
# service iptables stop
# chkconfig iptables off
If you are using IPv6 firewall, enter:
# service ip6tables save
# service ip6tables stop
# chkconfig ip6tables off
get number of links in a page using Selenium IDE
round off the decimal value to decimal places using Selenium IDE
round off the decimal value to decimal places using Selenium IDE
Input:-
Selenium Webdriver with Ruby Unit Example of Google Search
Copy the code and save as google_search.rb and run “ruby google_search.rb”
require “selenium-webdriver”require “test/unit”class GoogleSearch < Test::Unit::TestCasedef setup@driver = Selenium::WebDriver.for :firefox@base_url = “http://www.google.com/”@driver.manage.timeouts.implicit_wait = 30@verification_errors = []enddef teardown@driver.quitassert_equal [], @verification_errorsenddef test_google_search@driver.get(@base_url)@driver.find_element(:name, “q”).clear@driver.find_element(:name, “q”).send_keys “Thiyagarajan Veluchamy”@driver.find_element(:name, “btnK”).clickenddef element_present?(how, what)@driver.find_element(how, what)truerescue Selenium::WebDriver::Error::NoSuchElementErrorfalseenddef verify(&blk)yieldrescue Test::Unit::AssertionFailedError => ex@verification_errors << exendend
Generate random email id in Ruby
Guys,
We can return random email using following method
def emailemailid = (0..8).map{(‘a’..’z’).to_a[rand(26)]}.join+”@yopmail.com”return emailidend
get tomorrow’s Date using javascript for selenium IDE
Selenium.prototype.doGenerateTomorrowDate = function( varName1, varName2 )
{
var currentDate = new Date(new Date().getTime() + 24 * 60 * 60 * 1000);
var day = currentDate.getDate()
var month = currentDate.getMonth() + 1
var year = currentDate.getFullYear()
var monthNames = [ "January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December" ];
var month = monthNames[month];
storedVars[ varName1 ] = day;
storedVars[ varName2 ] = month;
};
<tr>
<td>generateTomorrowDate</td>
<td>x</td>
<td>y</td>
</tr>
<tr>
<td>echo</td>
<td>${x}</td>
<td></td>
</tr>
<tr>
<td>echo</td>
<td>${y}</td>
<td></td>
</tr>if statement in Selenium IDE
open | URL of site
storeTextPresent | any unique text of page a | title
gotoIf | storedVars.title | true
getEval | alert(“page B”);
gotolabel | finish
label | true
getEval | alert(“Page A”);
label | finish
This will check whether title is present or not, and if present control will redirect to label true, else will execute next statement after gotoif.
Get id of div from its class name using JavaScript for Selenium IDE
Get id of div from its class name using JavaScript for Selenium IDE
How to solve the link has target ‘_blank’, which is not supported in Selenium
For the example,
<a target=”_blank” id=”verify_email” href=”https://thiyagarajan.wordpress.com/users/verify/1341484215″>Verify your email</a>
So We can use following,
<tr>
<td>storeAttribute</td>
<td>//a[@id=’verify_email’]/@href</td>
<td>href</td>
</tr>
<tr>
<td>echo</td> ‘ this is only optional to see the link
<td>${href}</td>
<td></td>
</tr>
<tr>
<td>open</td>
<td>${href}</td>
<td></td>
</tr>
Generates a random word using JavaScript in Selenium IDE
Generates a random alphanumeric string using JavaScript Selenium IDE
Locating Elements in Selenium IDE
Locating by Id
Locating by Name
Locating by XPath
Locating Hyperlinks by Link Text
Locating by DOM
Locating by CSS
write the selenium IDE test case for CAPTCHA images
Try prompt a text box for user to key in the captcha, and store in variable
example:
storeEval | prompt(“Enter Captcha:”) | varName
Then type the varName text in to your captcha text box example
type | id=CaptchaText | ${varName}
sendmail settings in rails 3 application
Open “application.rb” file in “config” folder of your application and add the following data to it.
*************************************************************
config.action_mailer.delivery_method = :sendmail
config.action_mailer.sendmail_settings = {
:location => ‘/usr/sbin/sendmail’,
:arguments => ‘-i -t’
}
config.action_mailer.perform_deliveries = true
config.action_mailer.raise_delivery_errors = true
*************************************************************
Taskbar missing in ubuntu
- Press Alt+F2, in text fild type ‘gnome-terminal’ (without quots) and click on ‘Run’.
- In terminal submit the commands below one by one. Select one line at a time and press ‘Enter’.
gconftool –recursive-unset /apps/panel
rm -rf ~/.gconf/apps/panel
pkill gnome-panel
Object Identification In Selenium
The following Identifiers used for object identification,
- id
- name
- dom
- xpath
- link
- css
Preload site before displaying
We can easiest can do this,
<html>
<head>
<script language="javascript" type="text/javascript">
function showpage() {
document.getElementById('loader').style.display = "none";
document.getElementById('main').style.display = "block";
}
</script>
</head>
<body onload="showpage();">
<div style="height:100%; width:100%; display:block;" id="loader">
Some preloading content here
</div>
<div style="height:100%; width:100%; display:none;" id="main">
Main Content Here
</div>
</body>
</html>
Run phpUnit + selenium RC remote test cases to local browser
We can run the test cases from remote server and case will get execute into local machine. We have to follow the below steps,
- Install phpunit and necessary packages in server
- edit the test case and change host as local ip address ( use static ip address )
- run the selenium RC in local server
- run the test case in server
Test case will get execute into local machine.
assert vs verify in selenium
Assert –
When test case fail immediately test get aborted.
Verify –
Will generate failure log after complete the test execution.
Assert Commands –
- assertAlert(pattern)
Verify Commands –
- verifyAlert(pattern)
handle autocomplete in selenium IDE
The type command may not be enough to trigger the autocomplete. My only addition would be that you might need the typeKeys command, which causes slightly different JavaScript events to be fired, which may be more likely to trigger the autocomplete widget.
So we can use the following steps to handle the situation,
- typeKeys
- waitForTextPresent
- mouseOver
- clickAt
Manual Testing Interview Questions and Answers
What makes a good test engineer?
A good test engineer has a ‘test to break’ attitude, an ability to take the point of view of the customer, a strong desire for quality, and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers, and an ability to communicate with both technical (developers) and non-technical (customers, management) people is useful. Previous software development experience can be helpful as it provides a deeper understanding of the software development process, gives the tester an appreciation for the developers’ point of view, and reduce the learning curve in automated test tool programming. Judgment skills are needed to assess high-risk areas of an application on which to focus testing efforts when time is limited.
What makes a good Software QA engineer?
The same qualities a good tester has are useful for a QA engineer. Additionally, they must be able to understand the entire software development process and how it can fit into the business approach and goals of the organization. Communication skills and the ability to understand various sides of issues are important. In organizations in the early stages of implementing QA processes, patience and diplomacy are especially needed. An ability to find problems as well as to see ‘what’s missing’ is important for inspections and reviews.
What makes a good QA or Test manager?
A good QA, test, or QA/Test(combined) manager should:
• be familiar with the software development process
• be able to maintain enthusiasm of their team and promote a positive atmosphere, despite
• what is a somewhat ‘negative’ process (e.g., looking for or preventing problems)
• be able to promote teamwork to increase productivity
• be able to promote cooperation between software, test, and QA engineers
• have the diplomatic skills needed to promote improvements in QA processes
• have the ability to withstand pressures and say ‘no’ to other managers when quality is insufficient or QA processes are not being adhered to
• have people judgement skills for hiring and keeping skilled personnel
• be able to communicate with technical and non-technical people, engineers, managers, and customers.
• be able to run meetings and keep them focused
What’s the role of documentation in QA?
Critical. (Note that documentation can be electronic, not necessarily paper.) QA practices should be documented such that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals, etc. should all be documented. There should ideally be a system for easily finding and obtaining documents and determining what documentation will have a particular piece of information. Change management for documentation should be used if possible.
What’s the big deal about ‘requirements’?
One of the most reliable methods of insuring problems, or failure, in a complex software project is to have poorly documented requirements specifications. Requirements are the details describing an application’s externally-perceived functionality and properties. Requirements should be clear, complete, reasonably detailed, cohesive, attainable, and testable. A non-testable requirement would be, for example, ‘user-friendly’ (too subjective). A testable requirement would be something like ‘the user must enter their previously-assigned password to access the application’. Determining and organizing requirements details in a useful and efficient way can be a difficult effort; different methods are available depending on the particular project. Many books are available that describe various approaches to this task. (See the Bookstore section’s ‘Software Requirements Engineering’ category for books on Software Requirements.)
Care should be taken to involve ALL of a project’s significant ‘customers’ in the requirements process. ‘Customers’ could be in-house personnel or out, and could include end-users, customer acceptance testers, customer contract officers, customer management, future software maintenance engineers, salespeople, etc. Anyone who could later derail the project if their expectations aren’t met should be included if possible.
Organizations vary considerably in their handling of requirements specifications. Ideally, the requirements are spelled out in a document with statements such as ‘The product shall…..’. ‘Design’ specifications should not be confused with ‘requirements’; design specifications should be traceable back to the requirements.
In some organizations requirements may end up in high level project plans, functional specification documents, in design documents, or in other documents at various levels of detail. No matter what they are called, some type of documentation with detailed requirements will be needed by testers in order to properly plan and execute tests. Without such documentation, there will be no clear-cut way to determine if a software application is performing correctly.
‘Agile’ methods such as XP use methods requiring close interaction and cooperation between programmers and customers/end-users to iteratively develop requirements. The programmer uses ‘Test first’ development to first create automated unit testing code, which essentially embodies the requirements.
What steps are needed to develop and run software tests?
The following are some of the steps to consider:
• Obtain requirements, functional design, and internal design specifications and other necessary documents
• Obtain budget and schedule requirements
• Determine project-related personnel and their responsibilities, reporting requirements, required standards and processes (such as release processes, change processes, etc.)
• Identify application’s higher-risk aspects, set priorities, and determine scope and limitations of tests
• Determine test approaches and methods – unit, integration, functional, system, load, usability tests, etc.
• Determine test environment requirements (hardware, software, communications, etc.)
• Determine testware requirements (record/playback tools, coverage analyzers, test tracking, problem/bug tracking, etc.)
• Determine test input data requirements
• Identify tasks, those responsible for tasks, and labor requirements
• Set schedule estimates, timelines, milestones
• Determine input equivalence classes, boundary value analyses, error classes
• Prepare test plan document and have needed reviews/approvals
• Write test cases
• Have needed reviews/inspections/approvals of test cases
• Prepare test environment and testware, obtain needed user manuals/reference documents/configuration guides/installation guides, set up test tracking processes, set up logging and archiving processes, set up or obtain test input data
• Obtain and install software releases
• Perform tests
• Evaluate and report results
• Track problems/bugs and fixes
• Retest as needed
• Maintain and update test plans, test cases, test environment, and testware through life cycle
What’s a ‘test plan’?
A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the ‘why’ and ‘how’ of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it. The following are some of the items that might be included in a test plan, depending on the particular project:
• Title
• Identification of software including version/release numbers
• Revision history of document including authors, dates, approvals
• Table of Contents
• Purpose of document, intended audience
• Objective of testing effort
• Software product overview
• Relevant related document list, such as requirements, design documents, other test plans, etc.
• Relevant standards or legal requirements
• Traceability requirements
• Relevant naming conventions and identifier conventions
• Overall software project organization and personnel/contact-info/responsibilties
• Test organization and personnel/contact-info/responsibilities
• Assumptions and dependencies
• Project risk analysis
• Testing priorities and focus
• Scope and limitations of testing
• Test outline – a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as applicable
• Outline of data input equivalence classes, boundary value analysis, error classes
• Test environment – hardware, operating systems, other required software, data configurations, interfaces to other systems
• Test environment validity analysis – differences between the test and production systems and their impact on test validity.
• Test environment setup and configuration issues
• Software migration processes
• Software CM processes
• Test data setup requirements
• Database setup requirements
• Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs
• Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs
• Test automation – justification and overview
• Test tools to be used, including versions, patches, etc.
• Test script/test code maintenance processes and version control
• Problem tracking and resolution – tools and processes
• Project test metrics to be used
• Reporting requirements and testing deliverables
• Software entrance and exit criteria
• Initial sanity testing period and criteria
• Test suspension and restart criteria
• Personnel allocation
• Personnel pre-training needs
• Test site/location
• Outside test organizations to be utilized and their purpose, responsibilties, deliverables, contact persons, and coordination issues
• Relevant proprietary, classified, security, and licensing issues.
• Open issues
• Appendix – glossary, acronyms, etc.
What’s a ‘test case’?
• A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly. A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results.
• Note that the process of developing test cases can help find problems in the requirements or design of an application, since it requires completely thinking through the operation of the application. For this reason, it’s useful to prepare test cases early in the development cycle if possible.
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 (see the ‘Tools’ section for web resources with listings of such tools). 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.
What is ‘configuration management’?
Configuration management covers the processes used to control, coordinate, and track: code, requirements, documentation, problems, change requests, designs, tools/compilers/libraries/patches, changes made to them, and who makes the changes. (See the ‘Tools’ section for web resources with listings of configuration management tools. Also see the Bookstore section’s ‘Configuration Management’ category for useful books with more information.)
What if the software is so buggy it can’t really be tested at all?
The best bet in this situation is for the testers to go through the process of reporting whatever bugs or blocking-type 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 or insufficient integration testing, poor design, improper build or release procedures, etc.) managers should be notified, and provided with some documentation as evidence of the problem.
How can it be known when to stop testing?
This can be difficult to determine. Many modern software applications are so complex, and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are:
• Deadlines (release deadlines, testing deadlines, etc.)
• Test cases completed with certain percentage passed
• Test budget depleted
• Coverage of code/functionality/requirements reaches a specified point
• Bug rate falls below a certain level
• Beta or alpha testing period ends
What if there isn’t enough time for thorough testing?
Use risk analysis to determine where testing should be focused.
Since it’s rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects. This requires judgement skills, common sense, and experience. (If warranted, formal methods are also available.) Considerations can include:
• Which functionality is most important to the project’s intended purpose?
• Which functionality is most visible to the user?
• Which functionality has the largest safety impact?
• Which functionality has the largest financial impact on users?
• Which aspects of the application are most important to the customer?
• Which aspects of the application can be tested early in the development cycle?
• Which parts of the code are most complex, and thus most subject to errors?
• Which parts of the application were developed in rush or panic mode?
• Which aspects of similar/related previous projects caused problems?
• Which aspects of similar/related previous projects had large maintenance expenses?
• Which parts of the requirements and design are unclear or poorly thought out?
• What do the developers think are the highest-risk aspects of the application?
• What kinds of problems would cause the worst publicity?
• What kinds of problems would cause the most customer service complaints?
• What kinds of tests could easily cover multiple functionalities?
• Which tests will have the best high-risk-coverage to time-required ratio?
What if the project isn’t big enough to justify extensive testing?
Consider the impact of project errors, not the size of the project. However, if extensive testing is still not justified, risk analysis is again needed and the same considerations as described previously in ‘What if there isn’t enough time for thorough testing?’ apply. The tester might then do ad hoc testing, or write up a limited test plan based on the risk analysis.
What can be done if requirements are changing continuously?
A common problem and a major headache.
• Work with the project’s stakeholders early on to understand how requirements might change so that alternate test plans and strategies can be worked out in advance, if possible.
• It’s helpful if the application’s initial design allows for some adaptability so that later changes do not require redoing the application from scratch.
• If the code is well-commented and well-documented this makes changes easier for the developers.
• Use rapid prototyping whenever possible to help customers feel sure of their requirements and minimize changes.
• The project’s initial schedule should allow for some extra time commensurate with the possibility of changes.
• Try to move new requirements to a ‘Phase 2’ version of an application, while using the original requirements for the ‘Phase 1’ version.
• Negotiate to allow only easily-implemented new requirements into the project, while moving more difficult new requirements into future versions of the application.
• Be sure that customers and management understand the scheduling impacts, inherent risks, and costs of significant requirements changes. Then let management or the customers (not the developers or testers) decide if the changes are warranted – after all, that’s their job.
• Balance the effort put into setting up automated testing with the expected effort required to re-do them to deal with changes.
• Try to design some flexibility into automated test scripts.
• Focus initial automated testing on application aspects that are most likely to remain unchanged.
• Devote appropriate effort to risk analysis of changes to minimize regression testing needs.
• Design some flexibility into test cases (this is not easily done; the best bet might be to minimize the detail in the test cases, or set up only higher-level generic-type test plans)
• Focus less on detailed test plans and test cases and more on ad hoc testing (with an understanding of the added risk that this entails).
Selenium Features
1 Multi Platform support
– Windows,Linux,Mac
2 Multi browser support
– Chrome, IE, Firefox, Safari, Netscape
3 Multiple programming Language support
– C#, Java, Ruby, PHP, Perl, Python
4 Xpath, Htmlid, DOM, Css selector
5 Support Ajax
6 ProxyInjection Mode
7 Experimental Browsers provided to test secured sites
8 Easy to use, small learning curve
9 Free-Open source
10 Matured Community
Tips and Tricks for adhoc Testing
The following list will help for adhoc Testing
1.Be well prepared
2.Create a rough draft
3.Test in sessions
4.Target key areas.
5.Learn to use different tools
6.Record your findings
in case web application,
1. check all links in every pages
2. check alt attributes in all images
3. test with different screen resolution
4. browsers compatibility ( test with all major browsers like FireFox, Chrome, IE, Safari …)
5. check with default cursor pointing while page load
6. check the data save option with special characters.
7. check the session
Rails and AJAX Image Upload using jQuery
Hi,
When uploading image in normal method, getting result after page reload. Its quit not looking good. So tried simple method using jquery,
image upload action look like below in controller
@image = Image.new(params[:user_avatar]) @image.save and the view page look like,
<% remote_form_for(:user_avatar, :url => { :controller => "users", :action => :avatar_upload }, :html => { :method => :post, :id => 'uploadForm', :multipart => true }) do |f| %>
Upload a file: <%= file_field_tag "user_avatar", :size => 15 %><%= submit_tag 'Upload' %>
<% end %>
and important below script,
$('#uploadForm input').change(function(){ $(this).parent().ajaxSubmit({ beforeSubmit: function(a,f,o) { o.dataType = 'json'; }, complete: function(XMLHttpRequest, textStatus) { // For example, if you have an image elemtn with id "user_avatar", then $('#user_avatar').attr('src', XMLHttpRequest.responseText); }, }); });
Web apps Functional Testing Checklist
1.1 LINKS
1.1.1 Check that the link takes you to the page it said it would.
1.1.2 Ensure to have no orphan pages (a page that has no links to it)
1.1.3 Check all of your links to other websites
1.1.4 Are all referenced web sites or email addresses hyperlinked?
1.1.5 If we have removed some of the pages from our own site, set up a custom 404 page that redirects your visitors to your home page (or a search page) when the user try to access a page that no longer exists.
1.1.6 Check all mailto links and whether it reaches properly
1.2 FORMS
1.2.1 Acceptance of invalid input
1.2.2 Optional versus mandatory fields
1.2.3 Input longer than field allows
1.2.4 Radio buttons
1.2.5 Default values on page load/reload(Also terms and conditions should be disabled)
1.2.6 Is Command Button can be used for HyperLinks and Continue Links ?
1.2.6 Is all the datas inside combo/list box are arranged in chronolgical order?
1.2.7 Are all of the parts of a table or form present? Correctly laid out? Can you confirm that selected texts are in the “right place?
1.2.8 Does a scrollbar appear if required?
1.3 DATA VERIFICATION AND VALIDATION
1.3.1 Is the Privacy Policy clearly defined and available for user access?
1.3.2 At no point of time the system should behave awkwardly when an invalid data is fed
1.3.3 Check to see what happens if a user deletes cookies while in site
1.3.4 Check to see what happens if a user deletes cookies after visiting a site
2. APPLICATION SPECIFIC FUNCTIONAL REQUIREMENTS
2.1 DATA INTEGRATION
2.1.1 Check the maximum field lengths to ensure that there are no truncated characters?
2.1.2 If numeric fields accept negative values can these be stored correctly on the database and does it make sense for the field to accept negative numbers?
2.1.3 If a particular set of data is saved to the database check that each value gets saved fully to the database. (i.e.) Beware of truncation (of strings) and rounding of numeric values.
2.2 DATE FIELD CHECKS
2.2.1 Assure that leap years are validated correctly & do not cause errors/miscalculations.
2.2.2 Assure that Feb. 28, 29, 30 are validated correctly & do not cause errors/ miscalculations.
2.2.3 Is copyright for all the sites includes Yahoo co-branded sites are updated
2.3 NUMERIC FIELDS
2.3.1 Assure that lowest and highest values are handled correctly.
2.3.2 Assure that numeric fields with a blank in position 1 are processed or reported as an error.
2.3.3 Assure that fields with a blank in the last position are processed or reported as an error an error.
2.3.4 Assure that both + and – values are correctly processed.
2.3.5 Assure that division by zero does not occur.
2.3.6 Include value zero in all calculations.
2.3.7 Assure that upper and lower values in ranges are handled correctly. (Using BVA)
2.4 ALPHANUMERIC FIELD CHECKS
2.4.1 Use blank and non-blank data.
2.4.2 Include lowest and highest values.
2.4.3 Include invalid characters & symbols.
2.4.4 Include valid characters.
2.4.5 Include data items with first position blank.
2.4.6 Include data items with last position blank.
Web App UI Checklist
Following is the checklist that QA team would be testing primarily.
1.1 COLORS
1.1.1 Are hyperlink colors standard?
1.1.2 Are the field backgrounds the correct color?
1.1.3 Are the field prompts the correct color?
1.1.4 Are the screen and field colors adjusted correctly for non-editable mode?
1.1.5 Does the site use (approximately) standard link colors?
1.1.6 Are all the buttons are in standard format and size?
1.1.7 Is the general screen background the correct color?
1.1.8 Is the page background (color) distraction free?
1.2 CONTENT
1.2.1 All fonts to be the same
1.2.2 Are all the screen prompts specified in the correct screen font?
1.2.3 Does content remain if you need to go back to a previous page, or if you move forward to another new page?
1.2.4 Is all text properly aligned?
1.2.5 Is the text in all fields specified in the correct screen font?
1.2.6 Is all the heading are left aligned
1.2.7 Does the first letter of the second word appears in lowercase? Eg:
1.3 IMAGES
1.3.1 Are all graphics properly aligned?
1.3.2 Are graphics being used the most efficient use of file size?
1.3.3 Are graphics optimized for quick downloads?
1.3.4 Assure that command buttons are all of similar size and shape, and same font & font size.
1.3.5 Banner style & size & display exact same as existing windows
1.3.6 Does text wrap properly around pictures/graphics?
1.3.7 Is it visually consistent even without graphics?
1.4 INSTRUCTIONS
1.4.1 Is all the error message text spelt correctly on this screen?
1.4.2 Is all the micro-help text(i.e tool tip) spelt correctly on this screen?
1.4.3 Microhelp text(i.e tool tip) for every enabled field & button
1.4.4 Progress messages on load of tabbed(active screens) screens
1.5 NAVIGATION
1.5.1 Are all disabled fields avoided in the TAB sequence?
1.5.2 Are all read-only fields avoided in the TAB sequence?
1.5.3 Can all screens accessible via buttons on this screen be accessed correctly?
1.5.4 Does a scrollbar appear if required?
1.5.5 Does the Tab Order specified on the screen go in sequence from Top Left to bottom right? This is the default unless otherwise specified.
1.5.6 Is there a link to home on every single page?
1.5.7 On open of tab focus will be on first editable field
1.5.8 When an error message occurs does the focus return to the field in error when the user cancels it?
1.6 USABILITY
1.6.1 Are all the field prompts spelt correctly?
1.6.2 Are fonts too large or too small to read?
1.6.3 Are names in command button & option box names are not abbreviations.
1.6.4 Assure that option boxes, option buttons, and command buttons are logically grouped together in clearly demarcated areas “Group Box”
1.6.5 Can the typical user run the system without frustration?
1.6.6 Do pages print legibly without cutting off text?
1.6.7 Does the site convey a clear sense of its intended audience?
1.6.8 Does the site have a consistent, clearly recognizable “look-&-feel”?
1.6.9 Does User cab Login Member Area with both UserName/Email ID ?
1.6.9 Does the site look good on 640 x 480, 600×800 etc.?
1.6.10 Does the system provide or facilitate customer service? i.e. responsive, helpful, accurate?
1.6.11 Is all terminology understandable for all of the site’s intended users?
Selenium ( web application testing system )
The selenium is one off the most popular free web based automation tool. The following steps will help to install(firefox),
1. go to “http://seleniumhq.org/download/”
2. download “Selenium IDE”
3. execute the downloaded file
4. click install now
Now ready after restart the FireFox browser.
How to write effective “Software Requirements Specifications (SRS)”
The Professional software developers should go through a software requirements gathering process at the beginning of software development projects. Its foremost function is to record the client’s needs and requirements in written form and become the foundation for the rest of the software development process. Once these requirements are compiled, the document becomes the record of both the client’s and developer’s understanding of what the software should accomplish. Usually the client reviews and signs off on the SRS thus beginning the full software design and development phase. This post is presents the high level steps involved in creating this document.
You’ll Need for prepare docs:
- Microsoft Word or openoffice writer or other Text Editors
- Diagramming software like Microsoft Visio
- collect the proper requirements from client side and development side
If your organization do not have template for the SRS document, see the below instructions.
- First thing is collect proper requirements from client.
- write Scope & Objective of the application
- Business Requirements
- Functional Requirements – (All the functional module to be described in the project – nothing can be left out – For example – if we take a Employees module – Employee add/modify/edit – his family details – his work experience details – his previous employment details – his salary part – education part)
- Non Functional Requirements – This is related to Performance, Scalaibility, Security, Useability etc.
- Report specifications
- create use case diagram
- Define the UI (User Interface) and other software interface, hardware interface
- Then define the entire application process flow.
- Then determine any specific client business rules
- Create any diagram needed to depth process flow and key requirements
- Then finally compile the document after review the document.
Now its ready SRS.
First Name, Last Name Validation
It should be
– first and last character must be alphabet
– accepts single character input
– it wont allow any special character and white space at start and end
E-mail address validation
We will discus how to validate email field,
given below,
E-Mail Address = “A@b.c”; — Valid
E-Mail Address = “A@b.cnet”; — Invalid
E-Mail Address = “A@b.c_”; — Invalid
E-Mail Address = “A@bcnn”; — Invalid
E-Mail Address = “Ab.cnn”; — Invalid
E-Mail Address = “A@bc”; — Invalid
E-Mail Address = “A@bat@.cnn”; — Invalid
E-Mail Address = “A@bat/.com”; — Invalid
conditions are,
- Must not be too short and too long
- Only one @ in email address
- Only one period ‘.’ or two periods in email
- No more than 3 characters after the final period (reverse find is 0 based not 1 based) com/ org/net/mil/gov/co.in/co.uk and etc
- Should not have an underscrode after @
- Allowed characters 0-9 A-Z _ . before @
Example E-Mail is thiyagarajannv@yahoo.com
I have devided Email ID in 4 parts in above email id,
- In first part we have to check invalid condition input spaces, Left blank, use special character, symbols etc before email in @.
- In Second part we have to check invalid condition input other specail character [!#$%^&*()_-:;”‘?/|\) at the place of @. left thisfield as blank. input spaces.etc
- In third part we have to check invalid invalid domain.
- In fourth part we have to check only valid suffix(.com,.co.in,.edu,.info,.org,.in etc)
very time EmailID should be in well manner.
like thiyagarajannv@yahoo.com and etc.
File Handling Using QTP
QTP File Handling
Many times we have may need to interact with text files using QTP. Interaction can be (but not limited to) in the form of reading input from a file or writing output to a file.
We can use FSO (FileSystemObject) object to do this.
What is FSO?
FSO stands for File System Object. This is used to support text file creation and manipulation through the TextStream object and is contained in the Scripting type library (Scrrun.dll).
The FSO Object Model has a rich set of properties, methods and events to process folders and files.
How to create a file?
We first create a FSO object using CreateObject.
Secondly we create a text file using CreateTextFile.
For Example: Suppose you want to create a file called “test.txt” located in C:\
Dim fso, file, file_actual_location
file_ actual_location = “C:\file_ actual _location”
Set fso = CreateObject(“Scripting.FileSystemObject”)
Set file = fso.CreateTextFile(file_ actual _location, True)
How to open a file?
Set file= fso.OpenTextFile(“C:\file_ actual_location”, ForWriting, True)
//2nd argument can be ForReading, ForWriting, ForAppending
//3rd argument is “True” if new file has to be created if the specified file doesn’t exist else false, blank signify false.
How to read content from a file?
Use ReadLine() method
For example:
Set file= fso.OpenTextFile(“C:\file_ actual_location”, ForReading, True) //2nd argument should always be “ForReading” in order to read contents from a file
Do while file.AtEndofStream <> True
data = file.ReadLine()
msgbox data
Loop
How to write content to a file?
You can use Write() or WriteLine() Methods to write text into a file. The difference between the Write() and WriteLine() Method is that the latter automatically inserts a new line character while the former doesn’t insert a new line character.
For example:
Set file= fso.OpenTextFile(“C:\file_ actual_location”, ForWriting, True) //2nd argument should always be “ForWriting” in order to write contents to a file
file.Write(“This is test is”)
file.Write(“file created.”)
//Output will be:
This is test is file created.
while
file.WriteLine(“This is test is “)
file.Write(“file created.”)
//Output will be:
This is test is
file created.
How to delete file?
Use DeleteFile() method to delete a file from a particular location
Foe Example:
file_location = “C:\file_actual_location”
Set fso = CreateObject(“Scripting.FileSystemObject”)
fso.DeleteFile(file_ actual_location)
QTP Advantages and Disadvatages
Will be getting the initial focus on development of all new features and supported technologies.
- Ease of use.
- Simple interface.
- Good error handling mechanism
- Presents the test case as a business workflow to the tester (simpler to understand).
- Excellent DDT (Data Driven Testing features)
- Uses a real programming language (Microsoft’s VBScript) with numerous resources available.
- Quick Test Professional is significantly easier for a non-technical person to adapt to and create working test cases, compared to WinRunner.
- Data table integration better and easier to use than WinRunner.
- Test Run Iterations/Data driving a test is easier and better implement with QuickTest.
- Parametrization easier than WinRunner.
- Can enhance existing QuickTest VB scripts without the Application Under Test? being available; by using the ActiveScreen.
- Can create and implement the Microsoft Object Model (Outlook objects, ADO objects, FileSystem objects, supports DOM, WSH, etc.).
- Better object identification mechanism.
- Numerous existing functions available for implementation both from within QuickTest Pro and VBScript.
- QTP supports .NET development environment (currently WinRunner 7.5 does not).
- XML support (currently WinRunner 7.5 does not).
- The Test Report is more robust in QuickTest compared to WinRunner.
- Integrates with TestDirector and WinRunner (can kick off WinRunner scripts from QuickTest).
- Must know VBScript in order to program at all.
- Must be able to program in VBScript in order to implement the real advance testing tasks and to handle very dynamic situations.
- Need training to implement properly.
- The Object Repository (OR) and testing environment? (paths, folders, function libraries, OR) can be difficult to understand and implement initially.
- we can’t done merzeing easly, when compare to winrunner
- we can’t able to check if the Window of Background colour is dynamically changes.
Priority Testing
Generally Priority is Business for the projects. And this will be set by the team lead or the project lead, based on the severity and the time constraint that the module has the priority will be set.
- Must fix the bug as soon as possible. Because bug is blocking further progress in this area.
- Should fix the all issues, before release the product or project.
- fix the issues within time period.
Available Browsers for Linux, Windows, Mac for Testing
A Web browser is a software application, user to display and interact with text, images, music, videos, games & etc typically located on a Web page at a Web site on the World Wide Web or a local area network. A web browser is importing for web application testing … The great number of browsers in the internet,
Web browsers listing for Windows
How To Access Blocked Web Sites
i given blow more proxy sites:
- http://www.hidemyass.com
- http://www.anonymizer.com
- http://www.wujie.net
- http://www.ultrareach.net
- http://surfshield.net
- http://www.guardster.com/subscription/proxy_free.php
- http://anonymouse.ws/anonwww.html
- http://www.browser-x.com
- http://www.spysurfing.com
- http://www.xerohour.org/hideme
- http://www.proxyz.be
- http://www.sc0rian.com/prox
- https://www.proxify.us
- http://kproxy.com/index.jsp
- http://www.brawl-hall.com/pages/proxy.php
- http://www.proxify.net
- http://proxy.computersteroids.com/index0.php
- http://www.unipeak.com
- http://flyproxy.com
- http://alienproxy.com
- http://proxify.com/
- http://www.unfilter.net
- http://www.proxymouse.com
- http://www.surfonym.com/cgi-bin/nph-proxy
- http://www.superproxy.be/browse.pl
- http://www.websiteguru.com/mrnewguy
- http://www.letsproxy.com
- http://www.fsurf.com
- http://indianproxy.com
- http://www.letmeby.com
- http://Boredatschool.net
- http://www.ibypass.org
- http://www.ipzap.com/
- https://proxify.biz
- http://kproxy.com/index.jsp
- http://www.attackcensorship.com/attack-censorship.html
- http://mrnewguy.com
- http://www.evilsprouts.co.uk/defilter
- http://www.proxify.info
- http://www.torify.com
- http://www.switchproxy.com
- http://www.proxifree.com
- http://www.secure-tunnel.com/
- http://www.proxify.cn
- http://www.arnit.net/utilities/webproxy/new
- http://www.proxify.co.uk
- http://www.betaproxy.com
- http://www.proxify.org
- http://www.proxychoice.com
- http://www.proxysnail.com
- http://www.anonypost.com
- http://www.thestrongestlinks.com
- http://www.hujiko.com
- http://www.anonproxy.info
- http://www.peoplesproxy.com
- http://www.freeproxy.us
- http://www.proxyweb.net
- http://www.nopath.com
- http://urlencoded.com
- http://www.pole.ws
- http://www.browseany.com
- http://www.spiderproxy.com
- http://www.clickcop.com
- http://www.sneakysurf.com
- http://www.mywebtunnel.com
- http://www.thewebtunnel.com
- http://www.3proxy.com
- http://www.yourfreeproxy.com
- http://www.proxy7.com
- http://www.fireprox.com
- http://www.stupidcensorship.com
- http://www.letsproxy.com
- http://www.sneak2.com
- http://www.cecid.com
- http://www.freeproxy.ca
- http://www.ibypass.org
- http://www.goproxing.com
- http://www.projectbypass.com/
- http://www.ipsecret.com
- http://www.nomorelimits.net
- http://www.proxify.de
- http://www.bywhat.com
- http://www.snoopblocker.com
- http://www.anonymizer.ru
- http://www.proxyking.net/
- http://www.perlproxy.com
- http://www.proxylord.com
- http://tntproxy.com
- http://satanproxy.com
- http://zombieinvasion.info
- http://demonproxy.com
- http://www.myfreeproxy.com
- http://www.gezcem.com/nph-proxy.pl.old
- http://mpleger.de
- http://www.the-cloak.com/login.html
Top 25 common programming bugs
Insecure Interaction between Components
- Improper Input Validation
- Improper Encoding or Escaping of Output
- Failure to Preserve SQL Query Structure (‘SQL Injection’)
- Failure to Preserve Web Page Structure (‘Cross-site Scripting’)
- Failure to Preserve OS Command Structure (‘OS Command Injection’)
- Clear text Transmission of Sensitive Information
- Cross-Site Request Forgery (CSRF) 8. Race Condition
- Error Message Information Leak
Risky Resource Management
- Failure to Constrain Operations within the Bounds of a Memory Buffer
- External Control of Critical State Data
- External Control of File Name or Path
- Un trusted Search Path
- Failure to Control Generation of Code (‘Code Injection’)
- Download of Code Without Integrity Check
- Improper Resource Shutdown or Release
- Improper Initialization
- Incorrect Calculation
Porous Defenses
- Improper Access Control (Authorization)
- Use of a Broken or Risky Cryptographic Algorithm
- Hard-Coded Password
- Insecure Permission Assignment for Critical Resource
- Use of Insufficiently Random Values
- Execution with Unnecessary Privileges
- Client-Side Enforcement of Server-Side Security
Testing Challenges
It is human (people) nature to respond to any challenges thrown upon them. But what do human mean by a challenge?
Well one of the definition of challenge is ‘a demanding or stimulating situation‘. A challenge could be ‘a call to engage yourself in a contest‘. As a tester we face different challenges in our profession. These situations can be handled in a better way if we have the skills to analyze the problem and off-course by understanding how our fellow testers are tackling a particular problem in their unique context.
As a tester, we have some challenges which are very unique to our profession and some challenges are more generic in nature. A challenge has classified into two broad categories:
Analytical Challenges – These challenges are not unique to our profession and most of the professions require some degree of analytical skills. Analytic can be defined as “Having the ability to analyze” or “Ability to divide into elements and principle“, given the nature of testing it is very important for testers to have good analytical skills. Like any other skill, analytical skill can also be improved by practice. This skill can be improved by practicing different Puzzles, taking challenges or reading different books to improve your aptitude. Best mechanism of improving this skill is to exercise your brain.
Professional Challenges: Every profession has its own challenges. This section explains the different challenges faced in this field and how you can overcome them. These may be the interaction with the developer, attitude of Management towards testing, identification of tools, their usage and training, interaction with the customers, acceptability and entry-exit criteria for the tests and many more.
Web Test Plan Development
- Internet
- Web Browser
- Web Server
- Title of the project:
- Date:
- Prepared by:
- Objective of testing: Why are you testing the application? Who, what, when, where, why, and how should be some of the questions you ask in this section of the test plan.
- Overview of the application: What is the purpose of the application? What are the specifications of the project?
- Responsible parties: Who is responsible and in charge of the testing?
- List of test team: What are the names and titles of the people on the test team?
- Anticipated risks: What types of risks are involved that could cause the test to fail?
- Similar risks from previous releases: Have there been documented risks from previous tests that may be helpful in setting up the current test?
- Possible limitations of testing: Are there any factors that may inhibit the test, such as resources and budget?
- Impossible testing: What are the considerations involved that could prevent the tests that are planned?
- Anticipated output: What are the anticipated outcomes of the test and have they been documented for comparison?
- Anticipated input: What are the anticipated outcomes that need to be compared to the test documentation?
- What are the operating systems that will be used?
- What is the compatibility of all the hardware being used?
Software:
- What data configurations are needed to run the software?
- Have all the considerations of the required interfaces to other systems been used?
- Are the software and hardware compatible?
- Database setup requirements: Does test data need to be generated or will a specific data from production be captured and used for testing?
- Setup requirements: Who will be responsible for setting up the environment and maintaining it throughout the testing process?
- Automated:Will automated tools be used?
- Manual:Will manual testing be done?
- Test cases: Are there test cases already prepared or will they need to be prepared?
- Test scripts: Are there test scripts already prepared or will they need to be prepared?
- Tools: What type of tools will be selected?
- Processes: Who will be involved in the problem tracking process?
- Testing deliverables: What are the deliverables for the test?
- Retests: How will the retesting reporting be documented?
- Training:Will training be provided?
- Implementation: How will training be implemented?
- Appendix:Will samples be included?
- Reference materials:Will there be a glossary, acronyms, and/or data dictionary?
- Verify plan. Make sure the plan is workable, the dates are realistic, and that the plan is published. How will the test plan be implemented and what are the deliverables provided to verify the test?
- Validate changes. Changes should be recorded by a problem tracking system and assigned to a developer to make revisions, retest, and sign off on changes that have been made.
- Acceptance testing. Acceptance testing allows the end users to verify that the system works according to their expectation and the documentation. Certification of the Web site should be recorded and signed off by the end users, testers, and management.
Test reports. Reports should be generated and the data should be checked and validated by the test team and users.
Understanding Software Defects
Understanding Software Defects
-
User interface errors – the system provides something that is different from Interface.
-
Error handling – the way the errors are recognized and treated may be in error .
-
Boundary-related errors – the treatment of values at the edges of their ranges may be incorrect .
-
Calculation errors – arithmetic and logic calculations may be incorrect .
-
Initial and later states – the function fails the first time it is used but not later, or Vice-versa .
-
Control flow errors – the choice of what is done next is not appropriate for the current state .
-
Errors in handling or interpreting data – passing and converting data between systems (and even separate components of the system) may introduce errors.
-
Race conditions – when two events could be processed, one is always accepted prior to the other and things work fine, however eventually the other event may be processed first and unexpected or incorrect results are produced.
-
Load conditions – as the system is pushed to maximum limits problems start to occur, e.g. arrays overflow, disks full .
-
Hardware – interfacing with devices may not operate correctly under certain conditions, e.g. device unavailable .
-
Source and version control – out-of-date programs may be used where correct revisions are available.
-
Documentation – the user does not observe operation described in manuals .
-
Testing errors – the tester makes mistakes during testing and thinks the system is behaving incorrectly.
Web Testing Challenges
Web Testing Challanges
Understanding the Web test process is essential for deciding how to proceed with the selection of a Web test process, automated test tools, and methodologies.
Following are several challenges that need to be considered when deciding on the Web process that is most applicable for your business:
The Web is in a state of constant change. The developer and tester need to understand how changes will affect their development and the Web sitetest process. As technology changes, testers will need to understand how this will affect them and how they will handle their testing responsibilities
When setting up the test scenarios, the tester needs to understand how to implement different scenarios that will meet different types of business requirements. For example, is a tester testing a site with graphic user interface (GUI) buttons and text boxes or testing HyperText MarkupLanguage (HTML) code? Simulating response time by pressing buttons and inputting different values will verify if correct calculations are valid.
The test environment can be a difficult part of the setup for the tester.
You need to be aware of all of the different components that make up the environment; the networking piece can be especially difficult to simulate.
The following several considerations need to be addressed
Multiple server tiers
Firewalls
Databases
Database servers
In the test environment, it is important to know how the different components will interact with each other.
When setting up the Web testing environment, special consideration should be given to how credit card transactions are handled, carried out, and verified. Because testers are responsible for setting up the test scenarios, they will need to be able to simulate the quantity of transactions that are going to be processed on the Web site.
Security is a constant concern for business on the Internet as well as for developers and testers. There are hackers who enjoy breaking the secuiry on a Web site.
Web-based applications Present New Challanges ,Both For Developers and Testers .These challanges include .
- Short Release Cycle
- Constant Changing Technology
- Possible Huge Number Of Users during Initial Website Launch.
- Inability To control The Users Running Environment.
- Twenty Four -24 Hour avilability of web site.
web test plan
Skills of a Tester’s Skull
Understanding Skills
The first and foremost activity of Software Testing is to understand the requirements/ functionalities of the software to be tested. Formal Documents like Software Requirement Specifications, Software Functional Specifications, Use Case Specifications and other Documents like Minutes of Meeting serves as the key references for planning and executing the testing tasks. The testers must have very good understanding skills to read and understand the information written in these documents. Many a times, it is possible to have many interpretations for the information presented in the documents. The testers must be able to identify the duplicate & ambiguous requirements. If the requirements are not clear or ambiguous, the testers must identify the sources of the requirements and get them clarified. The sources of the requirements in most of the project development team should be Business Analysts, Business Users or any other competent authority as identified by the Project Management team. The testers shall analyze and co-relate the information gathered within the perspective of the project.
Listening Skills
Documents are not the only source of reference for the testing activities. The information required for the testing activities may be acquired through offline meetings, seminars, conferences, etc. The minutes of the meetings, conferences, seminars may or may not be recorded in a formal document. The testers must have very good active listening skills in order to collate and co-relate all of that information and refer them for the testing activities. While the requirements or functionalities of the software are discussed over a meeting, many a times, some part of the requirements are missed out. The testers should be able to identify and get them clarified before heading towards the subsequent testing phases.
Test Planning Skills
All software requirements shall be testable. The software shall be designed in such a way that all software requirements shall be testable. The test plan shall be formulated in such a way that paves the way for validating all the software requirements. In the real time scenario, there could be many requirements that are not testable. The tester with his/her test planning skills should be able to find out a workaround to test those non-testable requirements. If there is no way to test them, that shall be communicated clearly to the appropriate authority. There could be many requirements that are very complex to test and the tester should be able to identify the best approach to test them.
Test Design Skills
Software Testing Science preaches many techniques like Equivalence Class Partitioning, Boundary Value Analysis, Orthogonal Array and many more techniques for an effective test design. The testers shall be aware of all those techniques and apply them into their software test designing practice. The tester shall be aware of various formats and templates to author and present the test cases or test procedures in a neat fashion. The tester shall aware of the best practices and the acceptable standards for designing the test cases. The tester shall be aware of the how to write test cases – non-ambiguous, simple, straight to the point.
The test case needs to contain Test Case Description, Test Steps and its corresponding expected results. The tester shall be aware of how to present the content in these three topics effectively in such a way that they can be read without any ambiguity by all the project stakeholders.
Test Execution Skills
Test Execution is nothing but executing the steps that is specified in the test design documents. During the execution, the testers shall capture the actual results and compare against the expected results specified in the test design documents. If there are any deviations between the expected and actual results, the testers shall consider that as a defect. The tester shall analyze the cause of the defect and if it is found and confirmed in the application under test, the same shall be communicated to the developers and it shall get fixed. If the cause of the defect is found with the test case, the same shall be communicated to the test designers and the test cases shall be modified/ amended accordingly. If the testers are not confident about the application functionalities and the test design documents, they may not confidently come to a conclusion about the defect in case of any discrepancies. This will lead to defects being leaked to the next phase and the testers needs to avoid this scenario. The testers shall be confident about the application functionalities and in case of any ambiguity or clarifications; they need to get them sorted out before executing the tests or at least during the test execution.
Defect Reporting Skills
Defect Reports are one of the critical deliverables from a tester. The defect reports are viewed by the development team, business analysts, project managers, technical managers and the quality assurance engineers along with the testers. Hence, the defect reports shall carry enough information about the defect. Steps to reproduce the defect, its expected result and actual result along with other information such as Severity, Priority, Assigned To (developer), Test Environment details are very critical for a defect report without which, the defect report is considered as incomplete. The tester shall be aware of the importance of the defect report and he/she shall create defect report in such a way that it is non-ambiguous. During the course of fixing the defect, the developers may come back to the testing team for more information regarding the defect and the tester shall provide the same without failing.
Test Automation Skills
Test Automation is a wonderful phenomenon by which the testing cost is drastically reduced. The manual test cases upon automation can be executed by running the automated test scripts. This means that the manual effort to run those automated test cases is not necessary and hence the total test effort is reduced drastically. The testers shall be aware of the technique for adopting test automation into the current testing process. Identifying the test automation candidates is very critical for the success of the automation project. Automation candidates shall be identified in such a way that the testing cost towards manual test execution would reduce significantly. This involves lots of thoughts from the financial perspective as well. The testers shall understand the process of do’s & don’ts of automation to make the automation project successful.
Conclusion
The testers shall understand/ learn and be confident about the application functionalities. Test planning, designing, execution and defect reporting are the basic and essential skills that a tester shall possess and develop in his day-to-day career. Professionals who are perfectionist in using these skills are called as “Testing Professionals” or “Testers” or “Testing Engineers”. Hope now, you are a tester…
Good Test Case
What is Test Case? How to write a good test case?
Test Cases are the implementation of a test case design which will help the software tester to detect defects in the application or the system being tested. This should be the primary goal of any test case or set of test cases. When I write a test case, I think of both types of test cases, positive test cases and negative test cases. Positive test cases are those which execute the happy path in the application and make sure that the happy path is working fine. Negative test cases as the name suggests are destructive test cases which are documented with some out-of-box thinking to break the system.
A Test Case should be documented in a manner that is useful for the current test cycle and any future test cycles. At a bare minimum each test case should contain: Sr No, Summary or Title, Description, Steps to reproduce, Expected Results, Actual Results and Status of the test case or remarks.
Test Case Summary or Title
The Summary or title should contain the essence of the test case including the functional area and purpose of the test. Using a common naming convention that groups test cases encourages reuse and help prevents duplicate test cases from occurring.
Test Case Description
The description should clearly state what sequence of events to be executed by the test case. The Test Case description can apply to one or more test cases; it will often take more than one test case to fully test an area of the application.
Test Case Steps to reproduce
Each test case step should clearly state the navigation, test data, and events required to accomplish the step. Using a common descriptive approach encourages reuse and conformity.
Expected Results of Test Case
The expected behavior of the system after any test case step that requires verification / validation – this could include: screen pop-ups, data updates, display changes, or any other discernable event or transaction on the system that is expected to occur when the test case step is executed.
Status or Remarks
The operational status of the test case – Executed or not executed etc.
Tools for Software Test Automation
The following tools are provide automated functional testing and performance testing for environments including Dot Net, Java, CORBA, WWW, WAP, client/server, UNIX, and Windows & Etc …
1 .Segue Software delivers the industry’s premier e-business reliability products and solutions to help you address the risks and complexities that can affect the performance and quality of your e-business system.
- SilkTest – Automated functional and regression testing
- SilkPerformer – Automated load and performance testing
- SilkMonitor – 24×7 monitoring and reporting of Web, application and database servers
- SilkPilot – Unit testing of CORBA objects
- SilkObserver – End-to-end transaction management and monitoring for CORBA applications
- SilkMeter – Access control and usage metering
- SilkRealizer – Scenario testing and system monitoring
- SilkRadar – Automated defect tracking
2. Mercury offers a suite of solutions that automate testing and quality assurance for client/server software and systems, e-business applications, and enterprise resource planning applications.
- QuickTest ProfessionalTM – E-business functional testing
- LoadRunner® – Enterprise load testing
- TestDirectorTM – Integrated test management
- WinRunner® – Test automation for the enterprise
Recover Scenarios in QTP
What are Recover Scenarios?
While executing your scripts you may get some UNEXPECTED/UNPREDICTABLE errors. (like printer out of paper). To “recover” the test (and continue running) from these unexpected errors you use Recovery Scenarios.
Next question arises,
When to use “on error resume next” or programmatic handling of errors VS Recovery Scenarios ?
If you can predict that a certain event may happen at a specific point in your test or component, it is recommended to handle that event directly within your test or component by adding steps such as If statements or optional steps or “on error resume next”, rather than depending on a recovery scenario. Using Recovery Scenarios may result in unusually slow performance of your tests.They are designed to handle a more generic set of unpredictable events which CANNOT be handled programmatically.
For Example:
A recovery scenario can handle a printer error by clicking the default button in the Printer Error message box.
You cannot handle this error directly in your test or component, since you cannot know at what point the network will return the printer error. You could try to handle this event in your test or component by adding an If statement immediately after the step that sent a file to the printer, but if the network takes time to return the printer error, your test or component may have progressed several steps before the error is displayed. Therefore, for this type of event, only a recovery scenario can handle it.
I would not go into details of how to create files and how to define them since they are fully covered in QTP Documentation. Mercury QuickTest Professional User’s Guide > Working with Advanced Testing Features > Defining and Using Recovery Scenarios >
What constitute Recovery Scenarios?
A recovery scenario consists of the following:
- Trigger Event. The event that interrupts your run session. For example, a window that may pop up on screen, or a QTP run error.
- Recovery Operations. The operations to perform to enable QTP to continue running the test after the trigger event interrupts the run session. For example, clicking an OK button in a pop-up window, or restarting Microsoft Windows.
- Post-Recovery Test Run Option. The instructions on how QTP should proceed after the recovery operations have been performed, and from which point in the test QTP should continue, if at all. For example, you may want to restart a test from the beginning, or skip a step entirely and continue with the next step in the test.
Recovery scenarios are saved in recovery scenario files having the extension .rs. A recovery scenario file is a logical collection of recovery scenarios, grouped according to your own specific requirements.
Is there a method to programmatically call them?
By default, QTP checks for recovery triggers when an error is returned during the run session. You can use the Recovery object’s method to force QTP to check for triggers after a specific step in the run session.
For a complete list go to QTP Documentation > Quick Test Advanced References > Quick Test Automation > Recovery Object
