Entries from March 2007 ↓
March 14th, 2007 — Software Testing Templates, Testing Tips and resources, Web Testing
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
Like this post? Please subscribe to Email Newsletter or RSS Feed to have future Software Testing Tips delivered to your email inbox or feed reader!
March 12th, 2007 — Testing Interview questions, Testing Skill Improvement, Testing Tips and resources, Web Testing
Points to be considered while testing a Web site:
Web sites are essentially client/server applications -
with web servers and ‘browser’ clients.
Consideration should be given to the interactions between html pages, TCP/IP communications, Internet connections, firewalls, applications that run in web pages (such as applets, javascript, plug-in applications), and applications that run on the server side (such as cgi scripts, database interfaces, logging applications, dynamic page generators, asp, etc.).
Additionally, there are a wide variety of servers and browsers, various versions of each, small but sometimes significant differences between them, variations in connection speeds, rapidly changing technologies, and multiple standards and protocols. The end result is that testing for web sites can become a major ongoing effort.
Other considerations might include:
What are the expected loads on the server (e.g., number of hits per unit time?), and what kind of performance is required under such loads (such as web server response time, database query response times). What kinds of tools will be needed for performance testing (such as web load testing tools, other tools already in house that can be adapted, web robot downloading tools, etc.)?
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.
Pages should be as browser-independent as possible, or pages should be provided or generated based on the browser-type.
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.
I am working on the search engine website. Testing a search engine site is a little bit different than a regular website. In my next posts I will explain how to test WWW in detail.
March 10th, 2007 — Software Job Openings
Designation : QA Engineer/Lead Engineer
Job Description:
Should have knowledge on testing applications.
Experience in preparation of test plans, test strategy, test case design and test execution.
Will be responsible for developing test plans and test case reports for functional, system, GUI and regression testing independently.
Will execute functional tests on builds at regular frequency and deliver test reports and bug reports.
Experience in Manual and Automated Testing of Software Application.
Experience in Automated test tools like QTP , Test Director.
Responsible for reproducing and isolation testing of bugs and verification for bug fixes.
Excellent experience in testing methodologies and Software Development Life Cycle processes.
Should have prior experience in handling teams .
Test Planning.
Preferably should have support UTA! .
Desire Profile :
Ability to work in team and handle pressure and demands.
Ability to Multi-task in a fast-paced, deadline driven environment.
Strong interpersonal skills and ability to work with all departments and levels within the organization
Highly organized and detail-oriented.
Must possess effective verbal & written communication skills.
Years of Experience : 2 to 9 yrs in Information Technology.
Education : B.E / B.Tech . – Any Specialization
Location : Mumbai
Key Words: QTP Testing , Silk Test and Strong in SDLC and Test Methodologies
Kindly revert if interest in the same. Kindly send your updated CV to us.
Also send the following details
Total IT Exp
Total relevant Exp:
Current Organiza! tion:
Role in Current Organization:
Current CTC:
Expected CTC:
Joining period:
Current Location:
Relocation to Mumbai (Yes/No)
Please revert back to us with your update profile as an word attachment we will confirm you for interview.
Thanks & Regards
Alpa Narvekar
SDF-V, SEEPZ, Andheri(East),
Mumbai – 400096 .India
Phone : +91-22- 39815000 # 1297
Mobile : 9820268246
Email:alpa.narvekar@polaris.co.in
March 7th, 2007 — Basics of Software testing, Test strategy
Is there any standard procedure to test the application as a whole? Or How can I test complete application right from the requirement gathering?
Here are the broad steps to test the application :These are the standard SQA peocesses to be followed in any application testing.
Review of the Objectives set for the Last Released Build
Objectives remaining to be completed are carried forward for the next release.
- Branching for the development cycle
- Objectives settings for the Major and customized releases
Target Date planned for the Releases and decision on the entire Project schedule that is required to achieve these target dates.
- A Detailed Project Plan and the release of design Specifications
This includes the decision on Design Specifications (Productwise), review of the design specs and development schedule. This involves QA during the phase of review.
- QA – Develop Test Plan based on Design Specifications
Test Plan : This is a top-level document that talks about how the product is going to be tested
This includes Objectives, Methodology adopted while testing, Features to be tested and not to be tested, risk criteria, testing schedule, cross-platform support and the resource allocation for testing.
Feature Test Plan : This document talks about how the testing is going to be carried out for each type of testing.
- QA – Functional Test Specifications
This document includes technical details (Software requirements) required prior to the testing. It is important from the tester’s point of view to understand and plan the technical resources prior to the testing.
Application Development : Considering the product features, tester has to make ready his/her own test suit.
- QA – Writing of Test Cases (CM)
- Smoke (BVT) test cases
- Sanity Test cases
- Regression Test Cases
- Extended Test Cases
- Negative Test Cases
- Development – Goes on Module by Module.
- Installers Binding and Building
- Installers are built around the individual product.
- Release Engg is responsible for releasing the Builds.
- Release Engg collects fresh/developed code from the developer’s initially/module wise.
- Installers have to take care of jar files updating, registry entries, and additional software installations.
- A build includes Installers of the available products – multiple platforms.
- For each build one or 2 CDs are made/build the same are pushed to Pune/Chennai based on the priority.
- Each product build are received in the form of zip files under http://pun-qaftp/ftproot/QA-Builds ( Pune-Specific). The procedure goes along for Chennai. San Jose QA picks up builds from Nexus ( Build Specific Server )
- The same zip files need to be unzipped to get the desired installer and the same is put at Pun_fps1/QA/Builds folder. ( Pune-Specific)
- Smoke Test (BVT) to check basic features of the product.
- Smoke Test results has to be posted on http://Chaquita which is an official site for posting Smoke
- Test results and to share the basic testing information.
- Prepare Smoke Test procedure.
- Testing of new features
- Document review
- Cross-platform testing
- Stress testing and memory leakage testing.
- Use of Trackweb’s “Soffront” as the Bug Tracking tool.
- Further FET (Fixed Effectiveness testing) of the filed bugs.
- Exception study and verification.
- Development – Code freeze :
No more new features are added at this point.
Candidate Builds and regression testing.
CDs are cut for the released products and the product is installed using those CDs and it takes place in San Jose.
- Decision to release the product :
A review meeting to analyze the performance of the product, which is set, and the same is compared with the objectives set.
One branch is kept for the post release modification and hence the product testing.
Post release review meeting to decide upon the objectives for the next release.
March 6th, 2007 — ISO standards
· SEI = ‘Software Engineering Institute’ at Carnegie-Mellon University; initiated by the U.S. Defense Department to help improve software development processes.
· CMM = ‘Capability Maturity Model’, developed by the SEI. It’s a model of 5 levels of organizational ‘maturity’ that determine effectiveness in delivering quality software. It is geared to large organizations such as large U.S. Defense Department contractors. However, many of the QA processes involved are appropriate to any organization, and if reasonably applied can be helpful. Organizations can receive CMM ratings by undergoing assessments by qualified auditors.
Level 1 - characterized by chaos, periodic panics, and heroic efforts required by individuals to successfully complete projects. Few if any processes in place; successes may not be repeatable.
Level 2 – software project tracking, requirements management, realistic planning, and configuration management processes are in place; successful practices can be repeated.
Level 3 – standard software development and maintenance processes are integrated throughout an organization; a Software Engineering Process Group is in place to oversee software processes, and training programs are used to ensure understanding and compliance.
Level 4 – metrics are used to track productivity, processes, and products. Project performance is predictable, and quality is consistently high.
Level 5 – the focus is on continuous process improvement. The impact of new processes and technologies can be predicted and effectively implemented when required.
· ISO = ‘International Organization for Standards’ – The ISO 9001, 9002, and 9003 standards concern quality systems that are assessed by outside auditors, and they apply to many kinds of production and manufacturing organizations, not just software. The most comprehensive is 9001, and this is the one most often used by software development organizations. It covers documentation, design, development, production, testing, installation, servicing, and other processes. ISO 9000-3 (not the same as 9003) is a guideline for applying ISO 9001 to software development organizations. The U.S. version of the ISO 9000 series standards is exactly the same as the international version, and is called the ANSI/ASQ Q9000 series. The U.S. version can be purchased directly from the ASQ (American Society for Quality) or the ANSI organizations. To be ISO 9001 certified, a third-party auditor assesses an organization, and certification is typically good for about 3 years, after which a complete reassessment is required. Note that ISO 9000 certification does not necessarily indicate quality products – it indicates only that documented processes are followed.
· IEEE = ‘Institute of Electrical and Electronics Engineers’ – among other things, creates standards such as ‘IEEE Standard for Software Test Documentation’ (IEEE/ANSI Standard 829), ‘IEEE Standard of Software Unit Testing (IEEE/ANSI Standard 1008), ‘IEEE Standard for Software Quality Assurance Plans’ (IEEE/ANSI Standard 730), and others.
· ANSI = ‘American National Standards Institute’, the primary industrial standards body in the U.S.; publishes some software-related standards in conjunction with the IEEE and ASQ (American Society for Quality).
March 1st, 2007 — Software Job Openings
Designation Software Trainee(T37758)
Functional Area IT Software
Area of Expertise System Design
Location France
Education
UG – Any Graduate – Any Specialization
PG – Post Graduation Not Required
Job Description
Roles and Responsibilities: KEy role and responsibilities:The candidates are supervised by a senior engineer. They are expected to come up with solutions that will be used for the actual IP development in 802.11n. ,
Skill & Job Requirements: Signal Processing,Wireless communications
Desired Profile
Skills: Freshers
Reference Job Code is T37758
How to Apply
1. Click here to Apply
2. Under “Know your Job code” enter 37758.
3. Complete the application process.