Professional Documents
Culture Documents
The client is a leading Insurance service provider under Property and Casualty (P&C) Segment.
The client plans to increase the sale of Auto Insurance policy by directly selling to prospective
customer through Internet channel.
Supply chain management was a term invented by Keith Oliver, a consultant belonging to
the firm Booz Allen Hamilton, in the year 1982, to describe the overall process of planning,
implementing, and controlling what goes on at the supply chain in order to satisfy
customers’ needs in a quick, efficient manner. As carried out in practice, supply chain
management can involve everything from overlooking the exchange and storage of raw
materials, taking inventory of all work that is in process, as well as the movement of goods
from their point of origin to the point where they will be consumed.
Images
• Check the type of image(jpg,jpeg,bmp.gif)
• Maximum size
• Compactibility with other browser
• Resolution
• Clarity of the image
• 2 tier applications
• 3 tier applications
CLIENT / SERVER TESTING
This type of testing usually done for 2 tier applications (usually developed for LAN)
Here we will be having front-end and backend.
The application launched on front-end will be having forms and reports which will be
monitoring and manipulating data
E.g: applications developed in VB, VC++, Core Java, C, C++, D2K, PowerBuilder etc.,
The backend for these applications would be MS Access, SQL Server, Oracle, Sybase, Mysql,
Quadbase
The tests performed on these types of applications would be
- User interface testing
- Manual support testing
- Functionality testing
- Compatibility testing & configuration testing
- Intersystem testing
WEB TESTING
This is done for 3 tier applications (developed for Internet / intranet / xtranet)
Here we will be having Browser, web server and DB server.
The applications accessible in browser would be developed in HTML, DHTML, XML,
JavaScript etc. (We can monitor through these applications)
Applications for the web server would be developed in Java, ASP, JSP, VBScript, JavaScript,
Perl, Cold Fusion, PHP etc. (All the manipulations are done on the web server with the help
of these programs developed)
The DBserver would be having oracle, sql server, sybase, mysql etc. (All data is stored in
the database available on the DB server)
For client server application users are well known, whereas for web application any user can
login and access the content, he/she will use it as per his intentions.
So, there are always issues of security and compatibility for web application.
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 sessions 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)
Validate your HTML/CSS:
If you are optimizing your site for Search engines then HTML/CSS validation is very
important. Mainly validate the site for HTML syntax errors. Check if site is crawlable to
different search engines.
Database testing:
Data consistency is very important in web application. Check for data integrity and errors
while you edit, delete, modify the forms or do any DB related functionality.
Check if all the database queries are executing correctly, data is retrieved correctly and also
updated correctly. More on database testing could be load on DB, we will address this in
web load or performance testing below.
2) Usability Testing:
Test for navigation:
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
Other user information for user help:
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:
The main interfaces are:
Web server and application server interface
Application server and Database server interface.
Check if all the interactions between these servers are executed properly. Errors are
handled properly. If database or web server returns any error message for any query by
application server then application server should catch and display these error messages
appropriately to users. Check what happens if user interrupts any transaction in-between?
Check what happens if connection to web server is reset in between?
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:
Web Load Testing
Web Stress Testing
Test application performance on different internet connection speed.
In web load testing test if many users are accessing or requesting the same page. Can
system sustain in peak load times? Site should handle many simultaneous user requests,
large input data from users, Simultaneous connection to DB, heavy load on specific pages
etc.
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:
Following are some test cases for web security testing:
• Test by pasting internal url directly into browser address bar without login. Internal
pages should not open.
• If you are logged in using username and password and browsing internal pages then
try changing url options directly. I.e. If you are checking some publisher site
statistics with publisher site ID= 123. Try directly changing the url site ID parameter
to different site ID which is not related to logged in user. Access should denied for
this user to view others stats.
• Try some invalid inputs in input fields like login username, password, input text
boxes. Check the system reaction on all invalid inputs.
• Web directories or files should not be accessible directly unless given download
option.
• Test the CAPTCHA for automates scripts logins.
• Test if SSL is used for security measures. If used proper message should get
displayed when user switch from non-secure http:// pages to secure https:// pages
and vice versa.
• All transactions, error messages, security breach attempts should get logged in log
files somewhere on web server.
I think I have addressed all major web testing methods. I have worked for around 2
years out of my testing career on web testing. There are some experts who have spent their
whole career life on web testing. If I missed out addressing some important web testing
aspect then let me know in comments below. I will keep on updating the article for latest
testing information.
Who is the target audience? What kind of browsers will they be using? What kind of
connection speeds will they by using? Are they intra- organization (thus with likely high
connection speeds and similar browsers) or Internet-wide (thus with a wide variety of
connection speeds and browser types)?
What kind of performance is expected on the client side (e.g., how fast should pages
appear, how fast should animations, applets, etc. load and run)?
Will down time for server and content maintenance/upgrades be allowed? how much?
What kinds of security (firewalls, encryptions, passwords, etc.) will be required and what is
it expected to do? How can it be tested?
How reliable are the site’s Internet connections required to be? And how does that affect
backup system or redundant connection requirements and testing?
What processes will be required to manage updates to the web site’s content, and
what are the requirements for maintaining, tracking, and controlling page content, graphics,
links, etc.?
Which HTML specification will be adhered to? How strictly? What variations will be allowed
for targeted browsers?
Will there be any standards or requirements for page appearance and/or graphics
throughout a site or parts of a site??
How will internal and external links be validated and updated? how often?
Can testing be done on the production system, or will a separate test system be required?
How are browser caching, variations in browser option settings, dial-up connection
variabilities, and real-world internet ‘traffic congestion’ problems to be accounted for in
testing?
How extensive or customized are the server logging and reporting requirements; are they
considered an integral part of the system and do they require testing?
How are cgi programs, applets, javascripts, ActiveX components, etc. to be maintained,
tracked, controlled, and tested?
Pages should be 3-5 screens max unless content is tightly focused on a single topic. If
larger, provide internal links within the page.
The page layouts and design elements should be consistent throughout a site, so that it’s
clear to the user that they’re still within a site.
All pages should have links external to the page; there should be no dead-end pages.
The page owner, revision date, and a link to a contact person or organization should be
included on each page.
What is Cookie?
Cookie is small information stored in text file on user’s hard drive by web server. This
information is later used by web browser to retrieve information from that machine.
Generally cookie contains personalized user data or information that is used to communicate
between different web pages.
Why Cookies are used?
Cookies are nothing but the user’s identity and used to track where the user navigated
throughout the web site pages. The communication between web browser and web server is
stateless.
For example if you are accessing domain http://www.example.com/1.html then web
browser will simply query to example.com web server for the page 1.html. Next time if you
type page as http://www.example.com/2.html then new request is send to example.com
web server for sending 2.html page and web server don’t know anything about to whom the
previous page 1.html served.
What if you want the previous history of this user communication with the web server? You
need to maintain the user state and interaction between web browser and web server
somewhere. This is where cookie comes into picture. Cookies serve the purpose of
maintaining the user interactions with web server.
When user visits the same page or domain later time this cookie is read from disk and used
to identify the second visit of the same user on that domain. Expiration time is set while
writing the cookie. This time is decided by the application that is going to use the cookie.
1) Session cookies: This cookie is active till the browser that invoked the cookie is open.
When we close the browser this session cookie gets deleted. Some time session of say 20
minutes can be set to expire the cookie.
2) Persistent cookies: The cookies that are written permanently on user machine and
lasts for months or years.
Where cookies are stored?
When any web page application writes cookie it get saved in a text file on user hard disk
drive. The path where the cookies get stored depends on the browser. Different browsers
store cookie in different paths. E.g. Internet explorer store cookies on
path “C:\Documents and Settings\Default User\Cookies”
Here the “Default User” can be replaced by the current user you logged in as. Like
“Administrator”, or user name like “Vijay” etc.
The cookie path can be easily found by navigating through the browser options. In Mozilla
Firefox browser you can even see the cookies in browser options itself. Open the Mozila
browser, click on Tools->Options->Privacy and then “Show cookies” button.
How cookies are stored?
Lets take example of cookie written by rediff.com on Mozilla Firefox browser:
On Mozilla Firefox browser when you open the page rediff.com or login to your rediffmail
account, a cookie will get written on your Hard disk. To view this cookie simply click on
“Show cookies” button mentioned on above path. Click on Rediff.com site under this cookie
list. You can see different cookies written by rediff domain with different names.
Site: Rediff.com Cookie name: RMID
Name: RMID (Name of the cookie)
Content: 1d11c8ec44bf49e0… (Encrypted content)
Domain: .rediff.com
Path: / (Any path after the domain name)
Send For: Any type of connection
Expires: Thursday, December 31, 2020 11:59:59 PM
Applications where cookies can be used:
1) To implement shopping cart:
Cookies are used for maintaining online ordering system. Cookies remember what user
wants to buy. What if user adds some products in their shopping cart and if due to some
reason user don’t want to buy those products this time and closes the browser window?
When next time same user visits the purchase page he can see all the products he added in
shopping cart in his last visit.
2) Personalized sites:
When user visits certain pages they are asked which pages they don’t want to visit or
display. User options are get stored in cookie and till the user is online, those pages are not
shown to him.
3) User tracking:
To track number of unique visitors online at particular time.
4) Marketing:
Some companies use cookies to display advertisements on user machines. Cookies control
these advertisements. When and which advertisement should be shown? What is the
interest of the user? Which keywords he searches on the site? All these things can be
maintained using cookies.
5) User sessions:
Cookies can track user sessions to particular domain using user ID and password.
Drawbacks of cookies:
1) Even writing Cookie is a great way to maintain user interaction, if user has set browser
options to warn before writing any cookie or disabled the cookies completely then site
containing cookie will be completely disabled and can not perform any operation resulting in
loss of site traffic.
2) Too many Cookies:
If you are writing too many cookies on every page navigation and if user has turned on
option to warn before writing cookie, this could turn away user from your site.
3) Security issues:
Some times users personal information is stored in cookies and if someone hack the cookie
then hacker can get access to your personal information. Even corrupted cookies can be
read by different domains and lead to security issues.
4) Sensitive information:
Some sites may write and store your sensitive information in cookies, which should not be
allowed due to privacy concerns.
This should be enough to know what cookies are. If you want more cookie info see Cookie
Central page.
Some Major Test cases for web application cookie testing:
The first obvious test case is to test if your application is writing cookies properly on disk.
You can use the Cookie Tester applicationalso if you don’t have any web application to test
but you want to understand the cookie concept for testing.
Test cases:
1) As a Cookie privacy policy make sure from your design documents that no personal or
sensitive data is stored in the cookie.
2) If you have no option than saving sensitive data in cookie make sure data stored in
cookie is stored in encrypted format.
3) Make sure that there is no overuse of cookies on your site under test. Overuse of
cookies will annoy users if browser is prompting for cookies more often and this could result
in loss of site traffic and eventually loss of business.
4) Disable the cookies from your browser settings: If you are using cookies on your site,
your sites major functionality will not work by disabling the cookies. Then try to access the
web site under test. Navigate through the site. See if appropriate messages are displayed to
user like “For smooth functioning of this site make sure that cookies are enabled on your
browser”. There should not be any page crash due to disabling the cookies. (Please make
sure that you close all browsers, delete all previously written cookies before performing this
test)
5) Accepts/Reject some cookies: The best way to check web site functionality is, not to
accept all cookies. If you are writing 10 cookies in your web application then randomly
accept some cookies say accept 5 and reject 5 cookies. For executing this test case you can
set browser options to prompt whenever cookie is being written to disk. On this prompt
window you can either accept or reject cookie. Try to access major functionality of web site.
See if pages are getting crashed or data is getting corrupted.
6) Delete cookie: Allow site to write the cookies and then close all browsers and manually
delete all cookies for web site under test. Access the web pages and check the behavior of
the pages.
7) Corrupt the cookies: Corrupting cookie is easy. You know where cookies are stored.
Manually edit the cookie in notepad and change the parameters to some vague values. Like
alter the cookie content, Name of the cookie or expiry date of the cookie and see the site
functionality. In some cases corrupted cookies allow to read the data inside it for any other
domain. This should not happen in case of your web site cookies. Note that the cookies
written by one domain say rediff.com can’t be accessed by other domain say yahoo.com
unless and until the cookies are corrupted and someone trying to hack the cookie data.
8 ) Checking the deletion of cookies from your web application page: Some times
cookie written by domain say rediff.com may be deleted by same domain but by different
page under that domain. This is the general case if you are testing some ‘action tracking’
web portal. Action tracking or purchase tracking pixel is placed on the action web page and
when any action or purchase occurs by user the cookie written on disk get deleted to avoid
multiple action logging from same cookie. Check if reaching to your action or purchase page
deletes the cookie properly and no more invalid actions or purchase get logged from same
user.
9) Cookie Testing on Multiple browsers: This is the important case to check if your web
application page is writing the cookies properly on different browsers as intended and site
works properly using these cookies. You can test your web application on Major used
browsers like Internet explorer (Various versions), Mozilla Firefox, Netscape, Opera etc.
10) If your web application is using cookies to maintain the logging state of any
user then log in to your web application using some username and password. In many
cases you can see the logged in user ID parameter directly in browser address bar. Change
this parameter to different value say if previous user ID is 100 then make it 101 and press
enter. The proper access message should be displayed to user and user should not be able
to see other users account.
These are some Major test cases to be considered while testing website cookies.
You can write multiple test cases from these test cases by performing various
combinations. If you have some different application scenario, you can mention
your test cases in comments belo
What is “Vulnerability”?
This is a weakness in the web application. The cause of such a “weakness” can be bugs in
the application, an injection (SQL/ script code) or the presence of viruses.
1. Password cracking:
The security testing on a web application can be kicked off by “password cracking”. In order
to log in to the private areas of the application, one can either guess a username/ password
or use some password cracker tool for the same. Lists of common usernames and
passwords are available along with open source password crackers. If the web application
does not enforce a complex password (e.g. with alphabets, number and special characters,
with at least a required number of characters), it may not take very long to crack the
username and password.
If username or password is stored in cookies without encrypting, attacker can use different
methods to steal the cookies and then information stored in the cookies like username and
password.
Via HTTP GET request user information is passed to server for authentication or fetching
data. Attacker can manipulate every input variable passed from this GET request to server
in order to get the required information or to corrupt the data. In such conditions any
unusual behavior by application or web server is the doorway for the attacker to get into the
application.
3. SQL Injection:
The next thing that should be checked is SQL injection. Entering a single quote (‘) in any
textbox should be rejected by the application. Instead, if the tester encounters a database
error, it means that the user input is inserted in some query which is then executed by the
application. In such a case, the application is vulnerable to SQL injection.
SQL injection attacks are very critical as attacker can get vital information from server
database. To check SQL injection entry points into your web application, find out code from
your code base where direct MySQL queries are executed on database by accepting some
user inputs.
If user input data is crafted in SQL queries to query the database, attacker can inject SQL
statements or part of SQL statements as user inputs to extract vital information from
database. Even if attacker is successful to crash the application, from the SQL query error
shown on browser, attacker can get the information they are looking for. Special characters
from user inputs should be handled/escaped properly in such cases.
Attacker can use this method to execute malicious script or URL on victim’s browser. Using
cross-site scripting, attacker can use scripts like JavaScript to steal user cookies and
information stored in the cookies.
Many web applications get some user information and pass this information in some
variables from different pages.
E.g.: http://www.examplesite.com/index.php?userid=123&query=xyz
Attacker can easily pass some malicious input or <script> as a ‘&query’ parameter which
can explore important user/server data on browser.
Important: During security testing, the tester should be very careful not to modify any of
the following:
• Configuration of the application or the server
• Services running on the server
• Existing user or customer data hosted by the application
Additionally, a security test should be avoided on a production system.
The purpose of the security test is to discover the vulnerabilities of the web application so
that the developers can then remove these vulnerabilities from the application and make
the web application and data safe from unauthorized actions.
WEB TESTING
While testing a web application you need to consider following Cases:
• Functionality Testing
• Performance Testing
• Usability Testing
• Server Side Interface
• Client Side Compatibility
• Security
Functionality:
In testing the functionality of the web sites the following should be tested:
• Links
i. Internal Links
ii. External Links
iii. Mail Links
iv. Broken Links
• Forms
i. Field validation
ii. Error message for wrong input
iii. Optional and Mandatory fields
• Database
* Testing will be done on the database integrity.
• Cookies
* Testing will be done on the client system side, on the temporary Internet files.
Performance :
Performance testing can be applied to understand the web site’s scalability, or to benchmark
the performance in the environment of third party products such as servers and middleware
for potential purchase.
• Connection Speed:
Tested over various networks like Dial Up, ISDN etc
• Load:
i. What is the no. of users per time?
ii. Check for peak loads and how system behaves
iii. Large amount of data accessed by user
• Stress:
i. Continuous Load
ii. Performance of memory, CPU, file handling etc..
Usability:
Usability testing is the process by which the human-computer interaction characteristics of a
system are measured, and weaknesses are identified for correction.
• Ease of learning
• Navigation
• Subjective user satisfaction
• General appearance
Server Side Interface:
In web testing the server side interface should be tested. This is done by verify that
communication is done properly. Compatibility of server with software, hardware, network
and database should be tested.
Client Side Compatibility:
The client side compatibility is also tested in various platforms, using various browsers etc.
Security:
The primary reason for testing the security of a web is to identify potential vulnerabilities
and subsequently repair them.
• Network Scanning
• Vulnerability Scanning
• Password Cracking
• Log Review
• Integrity Checkers
• Virus Detection
Writing effective test casesis a skill and that can be achieved by some experience and in-
depth study of the application on which test cases are being written.
Here I will share some tips on how to write test cases, test case procedures and
some basic test case definitions.
What is a test case?
“A test case has components that describes an input, action or event and an expected
response, to determine if a feature of an application is working correctly.” Definition
by Glossary
There are levels in which each test case will fall in order to avoid duplication efforts.
Level 1: In this level you will write the basic test cases from the available
specification and user documentation.
Level 2: This is the practical stage in which writing test cases depend on actual functional
and system flow of the application.
Level 3: This is the stage in which you will group some test cases and write a test
procedure. Test procedure is nothing but a group of small test cases maximum of 10.
Level 4: Automation of the project. This will minimize human interaction with system
and thus QA can focus on current updated functionalities to test rather than remaining busy
with regression testing.
So you can observe a systematic growth from no testable item to a Automation suit.
Verify
Using [tool name, tag name, dialog, etc]
With [conditions]
To [what is returned, shown, demonstrated]
Verify: Used as the first word of the test case statement.
Using: To identify what is being tested. You can use ‘entering’ or ‘selecting’ here instead of
using depending on the situation.
For any application basically you will cover all the types of test cases including
functional, negative and boundary value test cases.
Keep in mind while writing test cases that all your test cases should be simple and easy
to understand. Don’t write explanations like essays. Be to the point.
Try writing the simple test cases as mentioned in above test case format.
Generally I use Excel sheets to write the basic test cases. Use any tool like ‘Test
Director’ when you are going to automate those test cases.
But when you entered into your application by logging in and navigated to USERS menu >
New user, entered all the required information to create new user and clicked on SAVE
button. BANG! The application crashed and you got one error page on screen. (Capture this
error message window and save as a Microsoft paint file)
Now this is the bug scenario and you would like to report this as a BUG in your bug-
tracking tool.
How will you report this bug effectively?
Here is the sample bug report for above mentioned example:
(Note that some ‘bug report’ fields might differ depending on your bug tracking system)
SAMPLE BUG REPORT:
Bug Name: Application crash on clicking the SAVE button while creating a new user.
Bug ID: (It will be automatically created by the BUG Tracking tool once you save this bug)
Area Path: USERS menu > New Users
Build Number: Version Number 5.0.1
Severity: HIGH (High/Medium/Low) or 1
Priority: HIGH (High/Medium/Low) or 1
Assigned to: Developer-X
Reported By: Your Name
Reported On: Date
Reason: Defect
Status: New/Open/Active (Depends on the Tool you are using)
Environment: Windows 2003/SQL Server 2005
Description:
Application crash on clicking the SAVE button while creating a new
user, hence unable to create a new user in the application.
Steps To Reproduce:
1) Logon into the application
2) Navigate to the Users Menu > New User
3) Filled all the user information fields
4) Clicked on ‘Save’ button
5) Seen an error page “ORA1090 Exception: Insert values Error…”
6) See the attached logs for more information (Attach more logs related to bug..IF any)
7) And also see the attached screenshot of the error page.
Expected result: On clicking SAVE button, should be prompted to a success message “New
User has been created successfully”.
(Attach ‘application crash’ screen shot.. IF any)
Save the defect/bug in the BUG TRACKING TOOL. You will get a bug id, which you can use
for further bug reference.
Default ‘New bug’ mail will go to respective developer and the default module owner (Team
leader or manager) for further action.
Related: If you need more information about writing a good bug report read our previous
post “How to write a good bug report“.
122 Comments
If you want to detect and resolve the defect in early development stage, defect tracking and
software development phases should start simultaneously.
We will discuss more on Writing effective bug report in another article. Let’s concentrate
here on bug/defect life cycle.
The figure is quite complicated but when you consider the significant steps in bug life cycle
you will get quick idea of bug life.
On successful logging the bug is reviewed by Development or Test manager. Test manager
can set the bug status as Open, can Assign the bug to developer or bug may be deferred
until next release.
When bug gets assigned to developer and can start working on it. Developer can set bug
status as won’t fix, Couldn’t reproduce, Need more information or ‘Fixed’.
If the bug status set by developer is either ‘Need more info’ or Fixed then QA responds with
specific action. If bug is fixed then QA verifies the bug and can set the bug status as verified
closed or Reopen.
From the SRS (software requirement specification) project plan is developed. The
responsibility of testers is to create software test plan from this SRS and project plan.
Developers start coding from the design. The project work is devided into different modules
and these project modules are distributed among the developers. In meantime testers
responsibility is to create test scenario and write test casesaccording to assigned modules.
We try to cover almost all the functional test cases from SRS. The data can be maintained
manually in some excel test case templates or bug tracking tools.
When developers finish individual modules, those modules are assigned to testers. Smoke
testing is performed on these modules and if they fail this test, modules are reassigned to
respective developers for fix. For passed modules manual testing is carried out from the
written test cases. If any bug is found that get assigned to module developer and get
logged in bug tracking tool. On bug fix tester do bug verification and regression testing of all
related modules. If bug passes the verification it is marked as verified and marked as
closed. Otherwise above mentioned bug cycle gets repeated.(I will cover bug life cycle in
other post)
Different tests are performed on individual modules and integration testing on module
integration. These tests includes Compatibility testing i.e testing application on different
hardware, OS versions, software platform, different browsers etc. Load and stress testing is
also carried out according to SRS. Finally system testing is performed by creating virtual
client environment. On passing all the test cases test report is prepared and decision is
taken to release the product!
So this was a brief outline of process of project life cycle.
Here is detail of each step what testing exactly carried out in each software
quality and testing life cycle specified by IEEE and ISO standards:
Review of the software requirement specifications
Objectives is set for the Major releases
Target Date planned for the Releases
Detailed Project Plan is build. This includes the decision on Design Specifications
Develop Test Plan based on Design Specifications
Test Plan : This includes Objectives, Methodology adopted while testing, Features to
be tested and not to be tested, risk criteria, testing schedule, multi-
platform support and the resource allocation for testing.
Test Specifications
This document includes technical details ( Software requirements )
required prior to the testing.
Writing of Test Cases
Smoke(BVT) test cases
Sanity Test cases
Regression Test Cases
Negative Test Cases
Extended Test Cases
Development – Modules developed one by one
Installers Binding: Installers are build around the individual product.
Build procedure :
A build includes Installers of the available products – multiple platforms.
Testing
Smoke Test (BVT) Basic application test to take decision on further testing
Testing of new features
Cross-platform testing
Stress testing and memory leakage testing.
Bug Reporting
Bug report is created
Development – Code freezing
No more new features are added at this point.
Testing
Builds and regression testing.
Decision to release the product
Post-release Scenario for further objectives.
Smoke testing and sanity testing – Quick and
simple differences
Despite of hundreds of web articles on Smoke and sanity testing, many people still have
confusion between these terms and keep on asking to me. Here is a simple and
understandable difference that can clear your confusion between smoke testing and
sanity testing.
Here are the differences you can see:
SMOKE TESTING:
• Smoke testing originated in the hardware testing practice of turning on a new piece
of hardware for the first time and considering it a success if it does not catch fire and
smoke. In software industry, smoke testing is a shallow and wide approach whereby
all areas of the application without getting into too deep, is tested.
• A smoke test is scripted, either using a written set of tests or an automated test
• A Smoke test is designed to touch every part of the application in a cursory way. It’s
shallow and wide.
• Smoke testing is conducted to ensure whether the most crucial functions of a
program are working, but not bothering with finer details. (Such as build
verification).
• Smoke testing is normal health check up to a build of an application before taking it
to testing in depth.
SANITY TESTING:
• A sanity test is a narrow regression test that focuses on one or a few areas of
functionality. Sanity testing is usually narrow and deep.
• A sanity test is usually unscripted.
• A Sanity test is used to determine a small section of the application is still working
after a minor change.
• Sanity testing is a cursory testing, it is performed whenever a cursory testing is
sufficient to prove the application is functioning according to specifications. This level
of testing is a subset of regression testing.
• Sanity testing is to verify whether requirements are met or not, checking all features
breadth-first.
Hope these points will help you to clearly understand the Smoke and sanity tests and will
help to remove any confusion.
Thanks to VijayD for answering this question in simple way for our readers.
If you have more points on smoke and sanity testing to elaborate on, please comment
below.
What is Boundary value analysis and Equivalence
partitioning?
Boundary value analysis and Equivalence partitioning, explained with simple
example:
Boundary value analysis and equivalence partitioning both are test case design strategies in
black box testing.
Equivalence Partitioning:
In this method the input domain data is divided into different equivalence data classes. This
method is typically used to reduce the total number of test cases to a finite set of
testable test cases, still covering maximum requirements.
In short it is the process of taking all possible test cases and placing them into classes. One
test value is picked from each class while testing.
E.g.: If you are testing for an input box accepting numbers from 1 to 1000 then there is no
use in writing thousand test cases for all 1000 valid input numbers plus other test cases for
invalid data.
Using equivalence partitioning method above test cases can be divided into three sets of
input data called as classes. Each test case is a representative of respective class.
So in above example we can divide our test cases into three equivalence classes of some
valid and invalid inputs.
Test cases for input box accepting numbers between 1 and 1000 using Equivalence
Partitioning:
1) One input data class with all valid inputs. Pick a single value from range 1 to 1000 as a
valid test case. If you select other values between 1 and 1000 then result is going to be
same. So one test case for valid input data should be sufficient.
2) Input data class with all values below lower limit. I.e. any value below 1, as a invalid
input data test case.
3) Input data with any value greater than 1000 to represent third invalid input class.
So using equivalence partitioning you have categorized all possible test cases into three
classes. Test cases with other values from any class should give you the same result.
We have selected one representative from every input class to design our test cases. Test
case values are selected in such a way that largest number of attributes of equivalence class
can be exercised.
Test cases for input box accepting numbers between 1 and 1000 using Boundary
value analysis:
1) Test cases with test data exactly as the input boundaries of input domain i.e. values 1
and 1000 in our case.
2) Test data with values just below the extreme edges of input domains i.e. values 0 and
999.
3) Test data with values just above the extreme edges of input domain i.e. values 2 and
1001.
Boundary value analysis is often called as a part of stress and negative testing.
Note: There is no hard-and-fast rule to test only one value from each equivalence class you
created for input domains. You can select multiple valid and invalid values from each
equivalence class according to your needs and previous judgments.
E.g. if you divided 1 to 1000 input values in valid data equivalence class, then you can
select test case values like: 1, 11, 100, 950 etc. Same case for other test cases having
invalid data classes.
This should be a very basic and simple example to understand the Boundary value analysis
and Equivalence partitioning concept.
No matter which career path you want to choose below are the best tips to help you land
your dream job.
1. Always do your homework well before walking into an interview. Make sure you have
complete knowledge about the company and the role.
2. Know yourself. Remember first impression is the last impression. Demonstrate your
capabilities and qualities and how well you can serve them. Don’t be overconfident and
aggressive.
3. You should know your competency and transferable skills. Competency skills are the
skills matching your job profile and transferable skills which you acquired through other
jobs, personal activities.
4. Social networking sites like Facebook, Orkut, Linkedin can be used for work
opportunities and conversing with other people improving your interpersonal skills.
5. Be clear about what you want to achieve in life and about your career objective. It will
keep you focused. You don’t have to do anything for the heck of it.
6. Your CV is vital for a successful interview. Never bluff, include all your skills and
experience to give you a competitive edge.
7. Prepare well for an interview. You can make notes of interview questions which are most
likely to be asked. Practice your answers.This will boost your confidence.
8. Work on your communication skills. Remember having a good technical knowledge
without effective interpersonal skills will not take you anywhere. Be expressive and a good
conversationalist. Dazzle the interviewers with eloquent speech.
9. Make sure you can support your strengths by giving examples. You can prepare
before but don’t falter while talking. It will not create a good impression.
10. When asked about your weaknesses acknowledge them. If you are not able to
describe, it signifies that you lack self awareness. You can’t be perfect in everything.
11. Always be presentable while dressing for the interview. Your attire should be
according to the role, culture and yourself. Please no tacky and brash clothing and
accessories. You don’t need to be glammed up.
12. Spend time on personal grooming. This will keep you calm. You don’t have to present
yourself as a person full of nervous energy and fidgets.
13. On the D day, relax. Be comfortable and wear a smile. And Voila! You will definitely
crack the interview.
14. Your body language is very important. Your facial expressions, hand movements,
posture, voice and pace should send the same message.
15. Don’t forget to make an eye contact. Your voice should be enthusiastic and do not
stammer. Lack of enthusiasm will put off the interviewers.
16. Keep all your documents well organized in a folder. Also be on time, preferably 15
minutes before so you get time to settle down and calm your nerves.
17. Interview manners are very important. Bad manners will definitely be a turn off.
Don’t bang the door, shake handily firmly, ask if you can take a seat, sit up straight and do
not slouch.
18. When asked about remuneration. You don’t have to be blunt. Instead you can say that
you expect a fair raise in terms of qualifications and experience proportionate with peers.
Now that you have some good interview tips. Be confident, gear up and don’t let
yourself down. Remember this is not the end of life if you don’t get through to the process.
It’s just an interview. Good Luck!
Preparing For Software Testing Interview –
Simple Tips To Follow Prior And at The Time of
Interview
As Software testers, we keep performing testing activities in various phases of a project.
When it comes to testing our own skills, we may not end up choosing an appropriate
approach. I am talking about how the interview rounds go and how to face them. The whole
article is a very general discussion about the challenges that a tester has to face in an
interview.
The way you present in interviews is very important. Right attitude is very important too.
Many managers can judge it easily, if you have really worked on projects or it’s just a fake
experience. The confidence level with which you answer makes a strong impression. For any
question if you are not sure about the correct answer, just make an attempt. Do not just
give up. You can also talk about things that you explored in free time or with your interest.
This shows that you take initiative and are a continuous learner as well.
As many of us must have experienced that the interviewers keep asking about the
processes that you have followed or are familiar with. One does not need to worry if they
have never followed any processes. Following the processes is up to the company and a
tester cannot do much regarding that. But of course one can follow some processes for
his/her own task (I mean the modules that you own or are in charge of etc). This will not
only help to manage things but also inspires other to follow some processes. Any process,
which has proven some good results, can be followed. So, instead of blaming others for not
following any processes, one can take an initiative to do it. Do not forget that Initiative is
one of the qualities that a tester should possess.
One more important point: It’s not necessary that the person who is taking your
interview is a person from QA background. A person from developing background can also
take software testing job interviews. What I mean to say is the person need not have
actually worked on the QA processes. In such case it becomes very important to answer the
questions very carefully. It may sound illogical when a person from non-QA background
interviews a tester but remember it will be a very good experience as you will get to know
how testing is perceived by others.
Over to You:
What’s your experience about software testing interviews? If you want to share some do’s
and don’ts please make comments below so that other testers can get benefit from your
experience. And finally ‘all the best’ for your testing career!
Sandhya will be giving youISTQB paper pattern and tips on how to solve the
questions quickly. To start with, here are 10 sample ISTQB ‘Foundation level’ questions
with detailed explanation for answers.
ISTQB question pattern and tips to solve:
ISTQB questions are formatted in such a way that the answers look very much similar.
People often choose the one, which they are more familiar with. We should carefully read
the question twice or thrice or may be more than that, till we are clear about what is being
asked in the question.
Now look at the options carefully. The options are chosen to confuse the candidates. To
choose the correct answer, we should start eliminating one by one. Go through each option
and check whether it is appropriate or not. If you end up selecting more than one option,
repeat the above logic for the answers that you selected. This will definitely work.
Before you start with the question papers, please read the material thoroughly. Practice as
many papers as possible. This will help a lot because, when we actually solve the papers,
we apply the logic that we know.
What is the expected result for each of the following test cases?
A.TC1: Anand is a 32 year old married, residing in Kolkatta.
B.TC3: Attapattu is a 65 year old married person, residing in Colombo.
a) A – Issue membership, 10% discount, B–Issue membership, offer no discount. B
b) A – Don’t Issue membership, B – Don’t offer discount. C
c) A – Issue membership, no discount, B – Don’t Issue membership.
d) A – Issue membership, no discount, B- Issue membership with 10% discount.
Evaluating the options:
Explanation:
For TC1: follow the path in green color
(The person is Indian resident, so select only ‘True’ options.
The person is aged between 18-55, so select only ‘True’
The person is a married, so again select only ‘True’
For this person, the actions under ‘Rule 4′ will be applied. That is, issue membership and no
discount)
For TC3: follow the path in blue color
(The person is not Indian resident, so select only ‘False’ (under Rule 1)
The person is not aged between 18-55. No need to select any path, as it is written “Don’t
care”.
The person is married. No need to select any path, as it is written “Don’t care”.
For this person, the actions under ‘Rule1′ will be applied, That is, Don’t issue membership
and no discount.)
So, the answer is ‘C’
Note: The answers are based on writers own experience and judgment and may not be
100% correct. If you feel any correction is required please discuss in comments below.
i. Planning
ii. Review Meeting
iii. Rework
iv. Individual Preparations
v. Kick Off
vi. Follow Up
a) i,ii,iii,iv,v,vi
b) vi,i,ii,iii,iv,v
c) i,v,iv,ii,iii,vi
d) i,ii,iii,v,iv,vi
Evaluating the options:
Formal review process is ’Inspection’. Planning is foremost step. Hence we can eliminate
option ’b’. Now we need to kickoff the process, so the second step will be Kick off. That’s it
we found the answer. Its ’C’
The answer is ’C’
4. Consider the following state transition diagram of a two-speed hair dryer, which
is operated by pressing its one button. The first press of the button turns it on to
Speed 1, second press to Speed 2 and the third press turns it off.
Which of the following series of state transitions below will provide 0-switch coverage?
a. A,C,B
b. B,C,A
c. A,B,C
d. C,B,A
Evaluating the options:
In State transition testing a test is defined for each state transition. The coverage that is
achieved by this testing is called 0-switch or branch coverage. 0-switch coverage is to
execute each loop once (No repetition. We should start with initial state and go till end
state. It does not test ‘sequence of two state transitions’). In this case the start state is
‘OFF’, and then press of the button turns it on to Speed 1 (i.e. A). Second press turns it on
to Speed 2 (i.e. B) and the third press turns it off (i.e. C). Here we do not test the
combinations like what if the start state is ‘Speed 1’ or ‘Speed 2’ etc.
An alternate way of solving this is check for the options where it starts with ‘OFF’ state. So
we have options ‘a’ and ‘c’ to select from. As per the state diagram from ‘OFF’ state the
dryer goes to ‘Speed 1’ and then to ‘Speed 2’. So our answer should start with ‘A’ and end
with ‘C’.
Questions
which of the following input values cover all of the equivalence partitions?
a. 10,11,21
b. 3,20,21
c. 3,10,22
d. 10,21,22
30. Using the same specifications as question 29, which of the following covers
the MOST boundary values?
a. 9,10,11,22
b. 9,10,21,22
c. 10,11,21,22
d. 10,11,20,21
Answers of all above Questions:
Question Answer
1. d
2. b
3. d
4. c
5. d
6. a
7. c
8. b
9. a
10. a
11. c
12. a
13. b
14. c
15. b
16. b
17. c
18. c
19. a
20. c
21. b
22. d
23. c
24. a
25. b
26. d
27. a
28. d
29. c
30. b
Question 1
One of the fields on a form contains a text box which accepts numeric values in the range of
18 to 25. Identify the invalid Equivalence class.
a) 17
b) 19
c) 24
d) 21
Solution
The text box accepts numeric values in the range 18 to 25 (18 and 25 are also part of the
class). So this class becomes our valid class. But the question is to identify invalid
equivalence class. The classes will be as follows:
Class I: values < 18 => invalid class
Class II: 18 to 25 => valid class
Class III: values > 25 => invalid class
17 fall under invalid class. 19, 24 and 21 fall under valid class. So answer is ‘A’
Question 2
In an Examination a candidate has to score minimum of 24 marks in order to clear the
exam. The maximum that he can score is 40 marks. Identify the Valid Equivalence values if
the student clears the exam.
a) 22,23,26
b) 21,39,40
c) 29,30,31
d) 0,15,22
Solution
The classes will be as follows:
Class I: values < 24 => invalid class
Class II: 24 to 40 => valid class
Class III: values > 40 => invalid class
We have to indentify Valid Equivalence values. Valid Equivalence values will be there in
Valid Equivalence class. All the values should be in Class II. So answer is ‘C’
Question 3
One of the fields on a form contains a text box which accepts alpha numeric values. Identify
the Valid Equivalence class
a) BOOK
b) Book
c) Boo01k
d) Book
Solution
Alpha numeric is combination of alphabets and numbers. Hence we have to choose an
option which has both of these. A valid equivalence class will consist of both alphabets and
numbers. Option ‘c’ contains both alphabets and numbers. So answer is ‘C’
Question 4
The Switch is switched off once the temperature falls below 18 and then it is turned on
when the temperature is more than 21. When the temperature is more than 21. Identify the
Equivalence values which belong to the same class.
a) 12,16,22
b) 24,27,17
c) 22,23,24
d) 14,15,19
Solution
We have to choose values from same class (it can be valid or invalid class). The classes will
be as follows:
Class I: less than 18 (switch turned off)
Class II: 18 to 21
Class III: above 21 (switch turned on)
Only in Option ‘c’ all values are from one class. Hence the answer is ‘C’. (Please note that
the question does not talk about valid or invalid classes. It is only about values in same
class)
Question 5
A program validates a numeric field as follows: values less than 10 are rejected, values
between 10 and 21 are accepted, values greater than or equal to 22 are rejected. Which of
the following input values cover all of the equivalence partitions?
a. 10,11,21
b. 3,20,21
c. 3,10,22
d. 10,21,22
Solution
We have to select values which fall in all the equivalence class (valid and invalid both). The
classes will be as follows:
Class I: values <= 9 => invalid class
Class II: 10 to 21 => valid class
Class III: values >= 22 => invalid class
All the values from option ‘c’ fall under all different equivalence class.So answer is ‘C’.
Question 6
A program validates a numeric field as follows: values less than 10 are rejected, values
between 10 and 21 are accepted, values greater than or equal to 22 are rejected. Which of
the following covers the MOST boundary values?
a. 9,10,11,22
b. 9,10,21,22
c. 10,11,21,22
d. 10,11,20,21
Solution
We have already come up with the classes as shown in question 5. The boundaries can be
identified as 9, 10, 21, and 22. These four values are in option ‘b’. So answer is ‘B’
Question 7
In a system designed to work out the tax to be paid:
An employee has £4000 of salary tax free.
The next £1500 is taxed at 10%.
The next £28000 after that is taxed at 22%.
Any further amount is taxed at 40%.
To the nearest whole pound, which of these groups of numbers fall into three DIFFERENT
equivalence classes?
a) £4000; £5000; £5500
b) £32001; £34000; £36500
c) £28000; £28001; £32001
d) £4000; £4200; £5600
Solution
The classes will be as follows:
Class I : 0 to £4000 => no tax
Class II : £4001 to £5500 => 10 % tax
Class III : £5501 to £33500 => 22 % tax
Class IV : £33501 and above => 40 % tax
Select the values which fall in three different equivalence classes. Option ‘d’ has values from
three different equivalence classes. So answer is ‘D’.
Question 8
In a system designed to work out the tax to be paid:
An employee has £4000 of salary tax free.
The next £1500 is taxed at 10%.
The next £28000 after that is taxed at 22%.
Any further amount is taxed at 40%.
To the nearest whole pound, which of these is a valid Boundary Value Analysis test case?
a) £28000
b) £33501
c) £32001
d) £1500
Solution
The classes are already divided in question # 7. We have to select a value which is a
boundary value (start/end value). 33501 is a boundary value. So answer is ‘C’.
Question 9
Given the following specification, which of the following values for age are in the SAME
equivalence partition?
If you are less than 18, you are too young to be insured.
Between 18 and 30 inclusive, you will receive a 20% discount.
Anyone over 30 is not eligible for a discount.
a) 17, 18, 19
b) 29, 30, 31
c) 18, 29, 30
d) 17, 29, 31
Solution
The classes will be as follows:
Class I: age < 18 => not insured
Class II: age 18 to 30 => 20 % discount
Class III: age > 30 => no discount
Here we cannot determine if the above classes are valid or invalid, as nothing is mentioned
in the question. (But according to our guess we can say I and II are valid and III is invalid.
But this is not required here.) We have to select values which are in SAME equivalence
partition. Values from option ‘c’ fall in same partition. So answer is ‘C’.
These are few sample questions for practice from ISTQB papers. We will continue
to add more ISTQB question papers with answers in coming posts.
About the Author:
This is a guest article by “N. Sandhya Rani”. She is having around 4 years of
experience in software testing mostly in manual testing. She is helping many aspirant
software testers to clear the ISTQB testing certification exam.
Put your questions related to ISTQB exam in comment section below.
Answer:
1-a) Boundary value Analysis: -
A process of selecting test cases/data by
identifying the boundaries that separate valid and invalid conditions. Tests are
constructed to test the inside and outside edges of these boundaries, in addition to
the actual boundary points. or A selection technique in which test data are chosen to
lie along “boundaries” of the input domain [or output range] classes, data structures,
procedure parameters, etc. Choices often include maximum, minimum, and trivial
values or parameters.
E.g. – Input data 1 to 10 (boundary value)
Test input data 0, 1, 2 to 9, 10, 11
1-b) Equivalence testing: -
The input domain of the system is partitioned into classes
of representative values, so that the no of test cases can be limited to one-per-class,
which represents the minimum no. of test cases that must be executed.
E.g.- valid data range: 1-10
Test set:-2; 5; 14
1-c) Error guessing: -
Test data selection technique. The selection criterion is to pick
values that seem likely to cause errors Error guessing is based mostly upon
experience, with some assistance from other techniques such as boundary value
analysis. Based on experience, the test designer guesses the types of errors that
could occur in a particular type of software and designs test cases to uncover them.
E.g. – For example, if any type of resource is allocated dynamically, a good place to
look for errors is in the de-allocation of resources. Are all resources correctly deallocated,
or are some lost as the software executes?
1-d) Desk checking: -
Desk checking is conducted by the developer of the system or
program. The process involves reviewing the complete product to ensure that it is
structurally sound and that the standards and requirements have been met. This is
the most traditional means for analyzing a system or program.
1-e) Control Flow Analysis: -
It is based upon graphical representation of the
program process. In control flow analysis; the program graphs has nodes which
represent a statement or segment possibly ending in an unresolved branch. The
graph illustrates the flow of program control from one segment to another as
illustrated through branches .the objective of control flow analysis is to determine
the potential problems in logic branches that might result in a loop condition or
improper processing .
Black box testing occurs throughout the software development and Testing life cycle i.e in
Unit, Integration, System, Acceptance and regression testing stages.
I will suggest to pick any such situation from you career and explain it in better
way. At least it should sound challenging This will help you to face further questions
from interviewer depending on your answer.
The broad challenges in manual testing are: How to ensure complete test coverage?
Testing without an automation tool is itself a big challenge. You can also explain non-
technical challenges in manual testing like managing the testing work in critical time (Llink
to testing under time limit) i.e. completing testing before deadline and even worst case if
the deadline itself is not feasible.
Explaining a challenging bug you found in your career can be also a good answer for this
question. For example the bug that was difficult to find or reprove or having big impact on
customer revenue etc.
Pavan you mentioned that you don’t have knowledge in banking and finance domain then
how you expect from yourself to give answer on that? If you don’t have experience in
banking and finance domain then do not put this as a skill in your resume just for the sake
of matching your profile with employer requirements. If you really want to get into testing
of BFSI (Banking, Financial services and Insurance) domain then first study
this domain. Know the basic concepts in BFSI domain. See the resources I have listed on
BFSI domain on ourresource page. Keep in mind you can answer in detail about any
question if you have worked on that.
Mitch asks:
“What is the best way to go about getting a pay rise? Is reporting and graphing bugs found
compared to other team member a good idea?
Comparing the bug count with other team or team member is very bad idea to ask
for pay rise. If you are working for the organization for long time then your employer know
your value and importance in organization. There is no need to show how your bug count
graph is higher than your counterparts.
So what is the best way to ask for good salary rise?
At the time of your performance appraisal you should be able to convince to your reviewer
that how you worked hard for your organization, How you succeeded in managing difficult
tasks and how you enhanced your skills to better match your current work profile. If you
succeed in this negotiation then you will definitely get good pay rise.
Other factors considered while giving you pay rise:
Your relevant skills, Complexity of application you are working on, problem solving skill,
total and relevant experience, education andcertifications.
Irrespective of the position, candidate should always be clear and confident about the
database concepts. For most software testing positions you need to have database
knowledge to perform some database checks. Almost all applications need an interaction
with database.
Let’s consider the database interview questions for entry-level software testing
positions. For entry level testing positions generally following questions can be
asked in interviews:
1) Basic and to some extent nested SQL queries to fetch data from database tables.
2) Examples of database statements for: Create Database, Create table and Drop Table.
3) Concept of “Primary Key”, “Foreign Key” and DB index
4) Examples of Select, Insert, Delete, Alter and Update SQL statements.
5) SQL joins (Inner Join, Left Join, Right Join and Full join) with examples.
Practice SQL join queries on dummy tables and see results.
For experienced level software testing positions, database interview questions depend on
the job requirement. For such positions interviewers expect detailed database knowledge
from candidates.
One more important point – If you get questions on database SQL queries, never say
that “You get all query statements to be executed from developers”. It’s ok to say that you
get help from developers to write complex SQL queries, but finally you manage by your
own.
Shariff asks:
What is Test Strategy?
In simple words – Test strategy means “How you are going to test the application?” You
need to mention the exact process/strategy that you are going to follow when you will get
the application for testing.
I see many companies follow test strategy template very strictly. Even without any standard
template you can keep this test strategy document simple but still effective.
Installation testing is like introducing a guest in your home. The new guest should be
properly introduced to all the family members in order to feel him comfortable. Installation
of new software is also quite like above example.
How we can use automation in this process? Well make some systems dedicated for
creating basic images (use software’s like Norton Ghost for creating exact images of
operating system quickly) of base configuration. This will save your tremendous time in
each test case. For example if time to install one OS with basic configuration is say 1 hour
then for each test case on fresh OS you will require 1+ hour. But creating image of OS will
hardly require 5 to 10 minutes and you will save approximately 40 to 50 minutes!
You can use one operating system with multiple attempts of installation of installer. Each
time uninstalling the application and preparing the base state for next test case. Be careful
here that your uninstallation program should be tested before and should be working fine.
If you like this article you would also like to subscribe to our email newsletter.
What is the main task in build release? Obviously file ‘check in’ i.e. to include all the
new and modified project files associated with respective builds. BVT was primarily
introduced to check initial build health i.e. to check whether – all the new and modified files
are included in release, all file formats are correct, every file version and language, flags
associated with each file.
These basic checks are worth before build release to test team for testing. You will save
time and money by discovering the build flaws at the very beginning using BVT.
Which test cases should be included in BVT?
This is very tricky decision to take before automating the BVT task. Keep in mind that
success of BVT depends on which test cases you include in BVT.
Here are some simple tips to include test cases in your BVT automation suite:
• Include only critical test cases in BVT.
• All test cases included in BVT should be stable.
• All the test cases should have known expected result.
• Make sure all included critical functionality test cases are sufficient for application
test coverage.
Also do not includes modules in BVT, which are not yet stable. For some under-development
features you can’t predict expected behavior as these modules are unstable and you might
know some known failures before testing for these incomplete modules. There is no point
using such modules or test cases in BVT.
You can make this critical functionality test cases inclusion task simple by communicating
with all those involved in project development and testing life cycle. Such process should
negotiate BVT test cases, which ultimately ensure BVT success. Set some BVT quality
standards and these standards can be met only by analyzing major project features and
scenarios.
Example: Test cases to be included in BVT for Text editor application (Some sample
tests only):
1) Test case for creating text file.
2) Test cases for writing something into text editor
3) Test case for copy, cut, paste functionality of text editor
4) Test case for opening, saving, deleting text file.
These are some sample test cases, which can be marked as ‘critical’ and for every minor or
major changes in application these basic critical test cases should be executed. This task
can be easily accomplished by BVT.
BVT automation suits needs to be maintained and modified time-to-time. E.g. include test
cases in BVT when there are new stable project modules available.
It’s not that we don’t know how to do the documentation right. We just don’t think it’s
important.
Everyone must have standard templates for all the kinds of documentation starting from
Test strategy, test Plan, Test cases, and Test data to Bug report. These are just to follow
some standards (CMMI, ISO etc.) but, when it comes to actual implementation how many of
these documents are really used by us? We just need to synchronize our quality process
with documentation standards and other process in an organization.
Continue reading →
30 Comments
Even I did not stress more on the documentation, but I can say it’s my habit to place all the
data in black and white and to update others about that as well.
Novice testers have many questions about software testing and the actual work that they
are going to perform. As novice testers, you should be aware of certain facts in the
software testing profession. The tips below will certainly help to advance you in your
software-testing career. These ‘testing truths’ are applicable to and helpful for
experienced testing professionals as well. Apply each and every testing truth mentioned
below in your career and you will never regret what you do.
Know Your Application
Don’t start testing without understanding the requirements. If you test without knowledge
of the requirements, you will not be able to determine if a program is functioning as
designed and you will not be able to tell if required functionality is missing. Clear
knowledge of requirements, before starting testing, is a must for any tester.
Know Your Domain
As I have said many times, you should acquire a thorough knowledge of the domain on
which you are working. Knowing the domain will help you suggest good bug solutions.
Your test manager will appreciate your suggestions, if you have valid points to make. Don’t
stop by only logging the bug. Provide solutions as well. Good domain knowledge will also
help you to design better test cases with maximum test coverage. For more guidance on
acquiring domain knowledge, read this post.
No Assumptions In Testing
Don’t start testing with the assumption that there will be no errors. As a tester, you should
always be looking for errors.
Learn New Technologies
No doubt, old testing techniques still play a vital role in day-to-day testing, but try to
introduce new testing procedures that work for you. Don’t rely on book knowledge. Be
practical. Your new testing ideas may work amazingly for you.
You Can’t Guarantee a Bug Free Application
No matter how much testing you perform, you can’t guarantee a 100% bug free
application. There are some constraints that may force your team to advance a product to
the next level, knowing some common or low priority issues remain. Try to explore as many
bugs as you can, but prioritize your efforts on basic and crucial functions. Put your best
efforts doing good work.
Think Like An End User
This is my top piece of advice. Don’t think only like a technical guy. Think like customers
or end users. Also, always think beyond your end users. Test your application as an end
user. Think how an end user will be using your application. Technical plus end user
thinking will assure that your application is user friendly and will pass acceptance tests
easily. This was the first advice to me from my test manager when I was a novice tester.
100% Test Coverage Is Not Possible
Don’t obsess about 100% test coverage. There are millions of inputs and test combinations
that are simply impossible to cover. Use techniques like boundary value analysis and
equivalence partitioning testing to limit your test cases to manageable sizes.
Build Good Relations With Developers
As a tester, you communicate with many other team members, especially developers. There
are many situations where tester and developer may not agree on certain points. It will
take your skill to handle such situations without harming a good relationship with the
developer. If you are wrong, admit it. If you are right, be diplomatic. Don’t take it
personally. After all, it is a profession, and you both want a good product.
Learn From Mistakes
As a novice, you will make mistakes. If you don’t make mistakes, you are not testing hard
enough! You will learn things as you get experience. Use these mistakes as your learning
experience. Try not to repeat the same mistakes. It hurts when the client files any bug in
an application tested by you. It is definitely an embracing situation for you and cannot be
avoided. However, don’t beat yourself up. Find the root cause of the failure. Try to find out
why you didn’t find that bug, and avoid the same mistake in the future. If required, change
some testing procedures you are following.
Don’t Underestimate Yourself if Some of Your bugs Are Not Fixed
Some testers have assumptions that all bugs logged by them should get fixed. It is a good
point to a certain level but you must be flexible according to the situation. All bugs may or
may not be fixed. Management can defer bugs to fix later as some bugs have low priority,
low severity or no time to fix. Over time you will also learn which bugs can be deferred
until the next release. Read article on ‘How to get all your bugs resolved‘.
Over To You:
If you are an experienced tester, what advice do you like to give to novice testers?
85 Comments
Top 20 practical software testing tips you should
read before testing any application.
September 29th, 2008 — Testing Skill Improvement, Testing Tips and resources,Testing best practices
I wish all testers read these software testing good practices.Read all points carefully
and try to implement them in your day-to-day testing activities. This is what I expect from
this article. If you don’t understand any testing practice, ask for more clarification in
comments below. After all you will learn all these testing practices by experience. But
then why not to learn all these things before making any mistake?
Here are some of the best testing practices I learned by experience:
1) Learn to analyze your test results thoroughly. Do not ignore the test result. The
final test result may be ‘pass’ or ‘fail’ but troubleshooting the root cause of ‘fail’ will lead you
to the solution of the problem. Testers will be respected if they not only log the bugsbut also
provide solutions.
2) Learn to maximize the test coverage every time you test any application. Though
100 percent test coverage might not be possible still you can always try to reach near it.
3) To ensure maximum test coverage break your application under test (AUT) into
smaller functional modules. Write test cases on such individual unit modules. Also if
possible break these modules into smaller parts.
E.g: Lets assume you have divided your website application in modules and ‘accepting user
information’ is one of the modules. You can break this ‘User information’ screen into smaller
parts for writing test cases: Parts like UI testing, security testing, functional testing of the
‘User information’ form etc. Apply all form field type and size tests, negative and validation
tests on input fields and write all such test cases for maximum coverage.
4) While writing test cases, write test cases for intended functionality first i.e. for valid
conditions according to requirements. Then write test cases for invalid conditions. This will
cover expected as well unexpected behavior of application under test.
5) Think positive. Start testing the application by intend of finding bugs/errors. Don’t
think beforehand that there will not be any bugs in the application. If you test the
application by intention of finding bugs you will definitely succeed to find those subtle
bugs also.
6) Write your test cases in requirement analysis and design phase itself. This way you can
ensure all the requirements are testable.
7) Make your test cases available to developers prior to coding.Don’t keep your test
cases with you waiting to get final application release for testing, thinking that you can log
more bugs. Let developers analyze your test cases thoroughly to develop quality
application. This will also save the re-work time.
8 ) If possible identify and group your test cases for regression testing. This will
ensure quick and effective manual regression testing.
9) Applications requiring critical response time should be thoroughly tested for
performance. Performance testing is the critical part of many applications. In manual
testing this is mostly ignored part by testers due to lack of required performance testing
large data volume. Find out ways to test your application for performance. If not possible to
create test data manually then write some basic scripts to create test data for performance
test or ask developers to write one for you.
10) Programmers should not test their own code. As discussed in our previous post,
basic unit testing of developed application should be enough for developers to release the
application for testers. But you (testers) should not force developers to release the product
for testing. Let them take their own time. Everyone from lead to manger know when the
module/update is released for testing and they can estimate the testing time accordingly.
This is a typical situation in agile project environment.
11) Go beyond requirement testing. Test application for what it is not supposed to do.
12) While doing regression testing use previous bug graph (Bug graph – number of bugs
found against time for different modules). This module-wise bug graph can be useful to
predict the most probable bug part of the application.
13) Note down the new terms, concepts you learn while testing. Keep a text file open while
testing an application. Note down the testing progress, observations in it. Use these
notepad observations while preparing final test release report. This good habit will help you
to provide the complete unambiguous test report and release details.
14) Many times testers or developers make changes in code base for application under test.
This is required step in development or testing environment to avoid execution of live
transaction processing like in banking projects. Note down all such code changes done
for testing purpose and at the time of final release make sure you have removed all these
changes from final client side deployment file resources.
15) Keep developers away from test environment. This is required step to detect any
configuration changes missing in release or deployment document. Some times developers
do some system or application configuration changes but forget to mention those in
deployment steps. If developers don’t have access to testing environment they will not do
any such changes accidentally on test environment and these missing things can be
captured at the right place.
16) It’s a good practice to involve testers right from software requirement and
design phase. These way testers can get knowledge of application dependability resulting
in detailed test coverage. If you are not being asked to be part of this development cycle
then make request to your lead or manager to involve your testing team in all decision
making processes or meetings.
17) Testing teams should share best testing practices, experience with other teams in
their organization.
18) Increase your conversation with developers to know more about the product.
Whenever possible make face-to-face communication for resolving disputes quickly and to
avoid any misunderstandings. But also when you understand the requirement or resolve any
dispute – make sure to communicate the same over written communication ways like
emails. Do not keep any thing verbal.
19) Don’t run out of time to do high priority testing tasks.Prioritize your testing work
from high to low priority and plan your work accordingly. Analyze all associated risks to
prioritize your work.
20) Write clear, descriptive, unambiguous bug report. Do not only provide the bug
symptoms but also provide the effect of the bug and all possible solutions.
Don’t forget testing is a creative and challenging task. Finally it depends on your skill and
experience, how you handle this challenge.
Over to you:
Sharing your own testing experience, tips or testing secrets in comments below will
definitely make this article more interesting and helpful!!
If you are not regular reader of this website then highly recommend you to sign up for our
free email newsletter! Sign up just providing your email address below:
Top of Form
Subscribe
Bottom of Form
146 Comments
Conclusion
So in short there is no problem if developers are doing the basic unit testing and
basic verification testing. Developers can test few exceptional conditions they know are
critical and should not be missed. But there are some great testers out there. Through the
build to test team. Don’t waste your time as well. For success of any project there should be
independent testing team validating your applications. After all it’s our (testers)
responsibility to make the ‘baby’ smarter!!
What you say?
Preparing proper test data is part of the test setup. Generally testers call it as testbed
preparation. In testbed all software and hardware requirements are set using the predefined
data values.
If you don’t have the systematic approach for building test data whilewriting and executing
test cases then there are chances of missing some important test cases. Tester can’t justify
any bug saying that test data was not available or was incomplete. It’s every testers
responsibility to create his/her own test data according to testing needs. Don’t even rely on
the test data created by other tester or standard production test data, which might not have
been updated for months! Always create fresh set of your own test data according to your
test needs.
Sometime it’s not possible to create complete new set of test data for each and every build.
In such cases you can use standard production data. But remember to add/insert your own
data sets in this available database. One good way to design test data is use the existing
sample test data or testbed and append your new test case data each time you get same
module for testing. This way you can build comprehensive data set.
I generally ask to my manager if he can make live environment data available for testing.
This data will be useful to ensure smooth functioning of application for all valid inputs.
How to prepare test data that will ensure complete test coverage?
Design your test data considering following categories:
Test data set examples:
1) No data: Run your test cases on blank or default data. See if proper error messages are
generated.
2) Valid data set: Create it to check if application is functioning as per requirements and
valid input data is properly saved in database or files.
3) Invalid data set: Prepare invalid data set to check application behavior for negative
values, alphanumeric string inputs.
4) Illegal data format: Make one data set of illegal data format. System should not accept
data in invalid or illegal format. Also check proper error messages are generated.
5) Boundary Condition data set: Data set containing out of range data. Identify
application boundary cases and prepare data set that will cover lower as well as upper
boundary conditions.
6) Data set for performance, load and stress testing: This data set should be large in
volume.
This way creating separate data sets for each test condition will ensure complete test
coverage.
Conclusion:
Preparing proper test data is a core part of “project test environment setup”. Tester cannot
pass the bug responsibility saying that complete data was not available for testing. Tester
should create his/her own test data additional to the existing standard production data. Your
test data set should be ideal in terms of cost and time. Use the tips provided in this article
to categorize test data to ensure complete functional test cases coverage.
Be creative, use your own skill and judgments to create different data sets instead of relying
on standard production data while testing.
Like This post? Get all article updates in your inbox. Click here to register just giving
your email ID.
7 basThis is a guest article by: Inder P Singh
These days a number of web sites are deployed in multiple languages. As companies
perform more and more business in other countries, the number of such global multi-lingual
web applications will continue to increase.
Testing web sites supporting multiple languages has its own fair share of challenges. In this
article,I will share seven tips with you that will enable you to test the multi-lingual
browser-based applications in a complete way:
Tip # 1 – Prepare and use the required test environment
If a web site is hosted in English and Japanese languages, it is not enough to simply change
the default browser language and perform identical tests in both the languages. Depending
on its implementation, a web site may figure out the correct language for its interface from
the browser language setting, the regional and language settings of the machine, a
configuration in the web application or other factors. Therefore, in order to perform a
realistic test, it is imperative that the web site be tested from two machines – one with the
English operating system and one with the Japanese operating system. You might want to
keep the default settings on each machine since many users do not change the default
settings on their machines.
Over to you:
Sharing your own testing experience, tips or testing secrets in comments below will
definitely make this article more interesting and helpful!!
Client used many ambiguous terms, which were having many different meanings, making it
difficult to analyze the exact meaning. The next version of the requirement doc from client
was clear enough to freeze for design phase.
Specifications should state both type of requirements i.e. what system should do and what
should not.
Generally I use my own method to uncover the unspecified requirements. When I read
the software requirements specification document (SRS), I note down my own
understanding of the requirements that are specified, plus other requirements SRS
document should supposed to cover. This helps me to ask the questions about unspecified
requirements making it clearer.
For checking the requirements completeness, divide requirements in three sections, ‘Must
implement’ requirements, requirements those are not specified but are ‘assumed’ and third
type is ‘imagination’ type of requirements. Check if all type of requirements are addressed
before software design phase.