Pages

Thursday, March 21, 2013

Test Plan Template :

Test Plan Template:
(Name of the Product)

Prepared by:
(Names of Preparers)
(Date)

TABLE OF CONTENTS :
1.0 INTRODUCTION
2.0 OBJECTIVES AND TASKS
2.1 Objectives
2.2 Tasks
3.0 SCOPE
4.0 Testing Strategy
4.1 Alpha Testing (Unit Testing)
4.2 System and Integration Testing
4.3 Performance and Stress Testing
4.4 User Acceptance Testing
4.5 Batch Testing
4.6 Automated Regression Testing
5.0 Hardware Requirements
6.0 Environment Requirements
6.1 Main Frame
6.2 Workstation
7.0 Test Schedule
8.0 Control Procedures
9.0 Features to Be Tested
10.0 Features Not to Be Tested
11.0 Resources/Roles & Responsibilities
12.0 Schedules
13.0 Significantly Impacted Departments (SIDs)
14.0 Dependencies
16.0 Tools
17.0 Approvals

Tuesday, February 28, 2012

Latent Bug

Latent Bug is a bug which is not identified in present version and can be able to identified in later versions. Also called as Golden Bug.

Gap Analysis

The gap analysis process involves determining, documenting and approving the variance between business requirements and current capabilities.It is the comparison study of general expectation of performance in the industry and the level of performance at
which the company currently functions.

Gap analysis provides a foundation for measuring investment of time, money and human resources required to achieve a particular outcome (e.g. to turn the salary payment process from paper based to paperless with the use of a system).

Such analysis can be performed at the strategic or operational level of an organization.'Gap analysis' is a formal study of what a business is
doing currently and where it wants to go in the future. It can be conducted, in different perspectives, as follows:

Organization (e.g., human resources)
Business direction
Business processes
Information technology

Also

Banking and financial services organizations often ask this question, as they face the risk of missing or incompletely covered Business Requirements (BR) in Functional Specifications Documents (FSDs). This risk arises as business users may not always articulate their basic requirements under the misconception that development vendors know them already. However, that is not often the case because technology focused developers do not understand the nuances of banking like a domain specialist can.

Inconsistencies between Business Requirements and Functional Specifications result in critical requirement gaps later in the product life cycle. This often proves very costly for the client and the vendor, in terms of both monetary and reputation loss.

Defect Leakage

Defect leakage occurs at the Customer or the End user side after the application delivery.After the release of the application to the client, if the end user gets any type of defects by using that application then it is called as Defect Leakage.This is also called as Bug Leakage.

Agile methodology over the Waterfall method

1. Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.
2. Another Agile method advantage is one has a launchable product at the end of each tested stage. This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination. This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.
3. Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications. Whereas, there is only one main release in the waterfall method and any problems or delays mean highly dissatisfied customers.
4. Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.
5. However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage. As for Agile, each coding module can be delegated to separate groups. This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.

Monday, February 27, 2012

Values of Agile Modeling

The five values of Agile Modeling (AM) are:
1.Communication : Models promote communication between your team and your project stakeholders as well as between developers on your team.
2.Simplicity : It’s important that developers understand that models are critical for simplifying both software and the software process—it’s much easier to explore an idea, and improve upon it as your understanding increases, by drawing a diagram or two instead of writing tens or even hundreds of lines of code.
3.Feedback : Kent Beck says it best in Extreme Programming Explained: “Optimism is an occupational hazard of programming, feedback is the treatment.” By communicating your ideas through diagrams, you quickly gain feedback, enabling you to act on that advice.
4.Courage : Courage is important because you need to make important decisions and be able to change direction by either discarding or refactoring your work when some of your decisions prove inadequate.
5.Humility : The best developers have the humility to recognize that they don't know everything, that their fellow developers, their customers, and in fact all project stakeholders also have their own areas of expertise and have value to add to a project. An effective approach is to assume that everyone involved with your project has equal value and therefore should be treated with respect. Huet Landry suggests the concept of "Other Esteem", instead of "Self Esteem", where you treat the opinions of others as if they have more value than yours. With this approach your first reaction to another's idea will be most positive.

Difference Between Authorization And Authentication

Authentication is the process to test whether the specific user is allowed to use or login to the application.

And

Authorization we test whether the specific user allowed to access some controls or features of the system/application/software.

Eg: In an office automation tool, every employee can login to the application, but only accounts manager can access accounts related features, only HR manager or executive can access company information

Severity And Priority

Severity
1. The Severity status is used to explain how badly the deviation is affecting the build.
2. The Severity type is defined by the tester on the written test cases and functionality.

Ex : If an aaplication or a web page crashes when a remote link is clicked,in this case clicking the remote link by an user is rare but the impact of application crashing is severe,so the severity is high and priority is low.

Priority
1. The Priority status is set by the tester to the developer mentioning the time frame to fix a defect.If High priority is mentioned then the developer has to fix it at the earliest.
2. The priority status is set based on the customer requirements.

Ex : If the company name is misspelled in the home page of a website, then the priority is high and the severity is low to fix it

Sunday, July 17, 2011

Quote 10

“If you don’t care about quality, you can meet any other requirement.” – Gerald M. Weinberg

Quote 9

“More than the act of testing, the act of designing tests is one of the best bug preventers known. The thinking that must be done to create a useful test can discover and eliminate bugs before they are coded – indeed, test-design thinking can discover and eliminate bugs at every stage in the creation of software, from conception to specification, to design, coding and the rest.” – Boris Beizer

Quote 8

“Quality is never an accident; it is always the result of intelligent effort.” – John Ruskin

Quote 7

"It's more about good enough than it is about right or wrong." (James Bach)

Quote 6

“Irreproducible bugs become highly reproducible right after delivery to the customer.”

Quote 5

"Before software can be reusable it first has to be usable.” – Ralph Johnson.

Accessibility Testing

Testing that determines if software will be usable by people with disabilities.

It is also called as ADA testing or 508 complaiance testing.(American disabilities act). Testing the application with respect to physically challenged persons point of view is called accessibility tesing..

Such as blindness, low or restricted vision, or color blindness. User with visual impairments uses assistive technology software that reads content loud. User with weak vision can also make text larger with browser setting or magnificent setting of operating system.

To know more plz visit Accessibility more

OR

To know more plz visit Testing for Accessibility MSDN

Sunday, January 9, 2011

Quote 4

Priorities tests so that whenever you stop testing you have done the best testing in the time available.

The 'Oracle Assumption'

For most systems it is possible to predict the expected results for any test case but there are a few systems where this is not the case.

For example, systems that predict situations or perform long and complex calculations that cannot practically be performed manually.

The Oracle Assumption is the name given to the assumption that it is possible to predict the expected results.

Quote 3

Testing is looking for something you don't really want to find.

Quote 2

The best way to build confidence is to try and destroy it.

Quote 1

You cannot have justified confidence in the quality of the software unless you have confidence in the quality of the Testing.