Bottom-up Integration :-
An incremental approach to integration testing where the lowest level components are tested first, and then used to facilitate the testing of higher level components. This process is repeated until the component at the top of the hierarchy is tested
Top-down testing:
An incremental approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level components. The process is repeated until the lowest level components have been tested
Thursday, December 10, 2009
Positive Testing Vs Negative Testing
Positive testing is that testing which attempts to show that a given module of an application does what it is supposed to do.
Negative testing is that testing which attempts to show that the module does not do anything that it is not supposed to do.
E.g of Positive testing If you are testing for boundary conditions for data ranging from 1-100 then at 101 it should throw and error.
If you are testing for boundary conditions for data ranging from 1-100 then at 101 it is not throwing an error.
Negative testing is that testing which attempts to show that the module does not do anything that it is not supposed to do.
E.g of Positive testing If you are testing for boundary conditions for data ranging from 1-100 then at 101 it should throw and error.
If you are testing for boundary conditions for data ranging from 1-100 then at 101 it is not throwing an error.
Extreme Programming & Scrum
Extreme Programming :- Extreme programming is the term to deal with iterative development model. In this as and when the piece of code is developed it is tested and delivered to the client.So Develop and deliver rule is followed here.
Scrum :- The Scrum is nothign but the whole engagement is divided into small sprints. One sprints lasts for 1 week to 3 weeks and the consensus of the team involved in the whole engagement is taken by doing a small meeting called as Scrum
Test Harness
Test harness or automated test framework is a collection of software and test data configured to test a program unit by running it under varying conditions and monitoring its behavior and outputs
Drivers and Stubs
It is always a good idea to develop and test software in "pieces". But, it may seem impossible because it is hard to imagine how you can test one "piece" if the other "pieces" that it uses have not yet been developed (and vice versa). To solve this kindof diffcult problems we use stubs and drivers.
Stub is a piece of code emulating a called function :-Stubs are created integration testing like Top-down approach
Driver is a piece of code emulating a calling function.Drivers are created integration testing like bottom-up approach
Stub is a piece of code emulating a called function :-Stubs are created integration testing like Top-down approach
Driver is a piece of code emulating a calling function.Drivers are created integration testing like bottom-up approach
Wednesday, December 9, 2009
ISTQB Training Institute
Are you interested in taking coaching for ISTQB exam? Learn from the Best ISTQB
training institute
ISTQB-FOUNDATION LEVEL
12th and 13th December’2009
NOIDA
Course Objective:
Become a certified software tester and join a group of elite internationally-recognized software testing professionals. Learn the absolute latest testing techniques and concepts from the most qualified & Foundation Level Certified trainers. Increase your marketability world-wide.Highlights Of Training:
ISTQB ACCREDITED TRAINING MATERIAL
THOROUGH PREPARATION OF CERTIFICATION EXAM
MOCK PAPERS & SAMPLE PAPERSHIGHLY EXPERIENCED AND CERTIFIED FACULTY
Course Contents:
Day 1
Fundamentals of Testing
Testing Throughout the Software Lifecycle
Static Techniques
Day 2
Test Design Techniques
Test Management
Tool Support for Testing
Mock Test Paper
Course Fee:
Rs 7721/- (inclusive of all taxes) per candidate
Registration Details
Location:
NOIDA
PureTrainings Software Pvt. LtdA-108B, Sector-58, NOIDA – 201301 (UP)
Contact Information
E-mail: mehak@puretrainings.com
Tel +911.120.462.1087Hand Phone +91.971.782.5444
Bangalore
PureTrainings Software Pvt. LtdBuilding Name:-Golden Square, 53/A, 16th C Main, 4th Block,Koramangala, (Near Sony-Center)Bangalore-560034
Contact Information
E-mail: vinay@puretrainings.com
Hand Phone +91.994.542.2723
Corporate Batches
We also conduct the above programs as Corporate Batches at Client locations' or at our Training Centre.
For Corporate Enquires, please contact Vinay
Email – Vinay@PureTrainings.comHand Phone - +91.991.010.5147
Discounts Scheme
· 5% Discount for early Bird Registrations (15 Days in advance of the program date)
· 5% Discount on Task Force of 4 to 7
· 10% Discount on Task Force of 8 and above
· 5% discount applicable to ISTQB Qualified Professionals.*
· 5% discount applicable to current and alumni of PureTrainings.
Only one discount is applicable at a time
Bangalore Hand Phone +91.994.542.2723
www.PureTrainings.com - Testing Training Experts
Marking breakup for ISTQB Exam !!!
Number of Questions Expected from each chapter
The principles of testing - 7
Testing throughout the life-cycle - 6
Static testing- 3
Test design techniques - 12
Test management - 8
Tool support for testing 4
Syllabus Breakup for ISTQB Preparation Material
The principles of testing
Terminology; why testing is necessary; fundamental test process; psychology of testing;
re-testing and regression testing; expected results; prioritization.
Testing throughout the life-cycle
Models for testing; economics of testing; high level test planning; acceptance testing;
integration testing in the large; functional and non-functional system testing; integration
testing in the small; component testing; maintenance testing.
Static testing
Reviews and the test process; types of review; static analysis.
Test design techniques
Dynamic testing techniques, Black and white-box testing techniques; error guessing,
BVA etc.
Test management
Organization; configuration management; test estimation, monitoring and control;
incident management; standards for testing.
Tool support for testing
Types of CAST tool (Computer-Aided Software Testing); tool selection and
implementation
Terminology; why testing is necessary; fundamental test process; psychology of testing;
re-testing and regression testing; expected results; prioritization.
Testing throughout the life-cycle
Models for testing; economics of testing; high level test planning; acceptance testing;
integration testing in the large; functional and non-functional system testing; integration
testing in the small; component testing; maintenance testing.
Static testing
Reviews and the test process; types of review; static analysis.
Test design techniques
Dynamic testing techniques, Black and white-box testing techniques; error guessing,
BVA etc.
Test management
Organization; configuration management; test estimation, monitoring and control;
incident management; standards for testing.
Tool support for testing
Types of CAST tool (Computer-Aided Software Testing); tool selection and
implementation
Monday, December 7, 2009
Sunday, December 6, 2009
Defect Clustering
In most cases, it can be seen that the majority of the detected defects are caused by a small number of modules, i.e. the distribution of defects are not across the application but rather condensed in particular areas of the application. This is particularly true for enterprise systems where the complexity, size, continuous change and developer inexperience can impact the quality of the system and affect particular modules.
This analogy is based on the Pareto principle, also known as the 80-20 rule, where it is stated that approximately 80 per cent of the problems are caused by 20 per cent of the modules. This can give a good indication that when a defect is found in one area of the application, chances are there are more defects in that particular area, so it is worth investing more time to test that particular area of the application to find as many defects as possible. However, this should not deter testers to “ignore” the rest of application as there may be other defects scattered around
This analogy is based on the Pareto principle, also known as the 80-20 rule, where it is stated that approximately 80 per cent of the problems are caused by 20 per cent of the modules. This can give a good indication that when a defect is found in one area of the application, chances are there are more defects in that particular area, so it is worth investing more time to test that particular area of the application to find as many defects as possible. However, this should not deter testers to “ignore” the rest of application as there may be other defects scattered around
Pesticide Paradox Explained
Repetitive use of the same pesticide mix to eliminate insects during farming will over time lead to the insects developing resistance to the pesticide thereby rendering the mix ineffective. A similar phenomenon may be seen while testing software. As testers keep repeating the same set of tests over an over again, the software being tested develops immunity to these tests and fewer defects show up. As you execute the same set of repetitive tests over an over again, your software eventually builds up resistance resulting in nothing new being revealed by the tests.
Further, every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffectual. In order to overcome the pesticide paradox, testers must regularly develop newer tests exercising the various parts of the system and their inter-connections to find additional defects. Also, testers cannot forever rely on existing test techniques or methods and must be on the look out to continually improve upon existing methods to make testing more effective
Further, every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffectual. In order to overcome the pesticide paradox, testers must regularly develop newer tests exercising the various parts of the system and their inter-connections to find additional defects. Also, testers cannot forever rely on existing test techniques or methods and must be on the look out to continually improve upon existing methods to make testing more effective
Thursday, December 3, 2009
ISTQB - Test design Technique Questions
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
__________________________________________________________________
Using the same specifications as question above , 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
____________________________________________________________________
Order numbers on a stock control system can range between 10000 and 99999 inclusive. Which of the following inputs might be a result of designing tests for only valid equivalence classes and valid boundaries:
a) 1000, 5000, 99999
b) 9999, 50000, 100000
c) 10000, 50000, 99999
d) 10000, 99999
e) 9999, 10000, 50000, 99999, 10000
____________________________________________________________________
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
__________________________________________________________________
Using the same specifications as question above , 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
____________________________________________________________________
Order numbers on a stock control system can range between 10000 and 99999 inclusive. Which of the following inputs might be a result of designing tests for only valid equivalence classes and valid boundaries:
a) 1000, 5000, 99999
b) 9999, 50000, 100000
c) 10000, 50000, 99999
d) 10000, 99999
e) 9999, 10000, 50000, 99999, 10000
____________________________________________________________________
IEEE 829 Explained
IEEE 829 :- Standard for Software Test Documentation
Eight defined stages of software testing
Test Plan
Test Design Specification
Test Case Specification
Test Procedure Specification
Test Item Transmittal Report
Test Incident Report
Test Log
Test Summary Report
Eight defined stages of software testing
Test Plan
Test Design Specification
Test Case Specification
Test Procedure Specification
Test Item Transmittal Report
Test Incident Report
Test Log
Test Summary Report
ISTQB Important Standards
IEEE 610.12:. Standard Glossary of Software Engineering Terminology.
IEEE 829: Standard for Software Test Documentation.
IEEE 1008: Standard for Software Unit Testing.
IEEE 1012:Standard for Verification and Validation Plans
IEEE 1028. Standard for Software Reviews and Audits.
IEEE 1044. Standard Classification for Software Anomalies.
IEEE 1219. Software Maintenance.
ISO/IEC 12207. Information Technology – Software Life Cycle Processes.
ISO/IEC 14598 Information Technology – Software Product Evaluation
IEEE 829: Standard for Software Test Documentation.
IEEE 1008: Standard for Software Unit Testing.
IEEE 1012:Standard for Verification and Validation Plans
IEEE 1028. Standard for Software Reviews and Audits.
IEEE 1044. Standard Classification for Software Anomalies.
IEEE 1219. Software Maintenance.
ISO/IEC 12207. Information Technology – Software Life Cycle Processes.
ISO/IEC 14598 Information Technology – Software Product Evaluation
General Exam Guidelines
• All questions must be written in US English.
• Use good grammar, punctuation, and spelling.
• Write simply and clearly - measure candidates’ knowledge of material, not vocabulary or "mind reading." Tricky or ambiguous questions create error, frustration, and compound biases related to language and disability.
• The questions should be designed to test the learning objectives of the syllabus, and not trivia or obscure knowledge associated with the subject matter. Questions should be recognized as being relevant to the goals of the syllabus.
• Use either the "correct answer" or "best answer" format, making sure there is only one ‘correct’ or ‘best’ answer.
• Avoid turns of phrase and figures of speech that could reasonably be construed as racist or sexist, or which may have a cultural bias.
• Avoid trick questions that mislead or deceive candidates into answering incorrectly.
• Emphasise key words that, if missed, could cause the candidate to select an incorrect option, (e.g. must or best or most) by CAPITALISING or emboldening.
• Keep questions independent of one another; do not cue the answer to one question with another. Independence maximizes breadth of coverage.
• Make all directions in the stem clear, using language that lets the candidate know exactly what is asked.
• In phrasing each question, minimize candidate reading time.
• Use vocabulary at a level appropriate to the qualification for which the candidate is being examined.
• Avoid complex multiple-choice formats unless dictated by the knowledge and skill requirements in the syllabus
• Minimize the difficulty of calculations.
• Avoid giving clues within the stem.
• Items should test one central idea or concept
• Good questions and therefore good exams take time to write - give yourself enough time to evaluate questions. After a day or two, revise, edit, and ask others to read them before submitting them.
• Questions must be based on the syllabus but should also be consistent with the ‘real world’.
• The key option must not be specific to an individual’s work context, but should apply generally to all work situations
• Use good grammar, punctuation, and spelling.
• Write simply and clearly - measure candidates’ knowledge of material, not vocabulary or "mind reading." Tricky or ambiguous questions create error, frustration, and compound biases related to language and disability.
• The questions should be designed to test the learning objectives of the syllabus, and not trivia or obscure knowledge associated with the subject matter. Questions should be recognized as being relevant to the goals of the syllabus.
• Use either the "correct answer" or "best answer" format, making sure there is only one ‘correct’ or ‘best’ answer.
• Avoid turns of phrase and figures of speech that could reasonably be construed as racist or sexist, or which may have a cultural bias.
• Avoid trick questions that mislead or deceive candidates into answering incorrectly.
• Emphasise key words that, if missed, could cause the candidate to select an incorrect option, (e.g. must or best or most) by CAPITALISING or emboldening.
• Keep questions independent of one another; do not cue the answer to one question with another. Independence maximizes breadth of coverage.
• Make all directions in the stem clear, using language that lets the candidate know exactly what is asked.
• In phrasing each question, minimize candidate reading time.
• Use vocabulary at a level appropriate to the qualification for which the candidate is being examined.
• Avoid complex multiple-choice formats unless dictated by the knowledge and skill requirements in the syllabus
• Minimize the difficulty of calculations.
• Avoid giving clues within the stem.
• Items should test one central idea or concept
• Good questions and therefore good exams take time to write - give yourself enough time to evaluate questions. After a day or two, revise, edit, and ask others to read them before submitting them.
• Questions must be based on the syllabus but should also be consistent with the ‘real world’.
• The key option must not be specific to an individual’s work context, but should apply generally to all work situations
ISTQB Exam Guidelines
International Software Testing Qualification Board
ISTQB Foundation Exam format and question writing guidelines
All ISTQB Foundation exams will use the same format, which will consist of the following components:
• 40 multiple choice questions (4 answers per question)
• 1 hour exam (set and managed by authorised examination boards)
• Score more than 60% (25 or more) to pass
• Each exam, if produced manually, will be live for a maximum of 6 months, otherwise each new exam to be created automatically each time
• Exam questions, whilst still ‘live’ in the question bank, can be reused as required by Exam setters
-----------------------------------------------------------------------------
For a 40 question paper, the breakdown should be:
Chapter 1 7 questions
Chapter 2 6 questions
Chapter 3 3 questions
Chapter 4 12 questions
Chapter 5 8 questions
Chapter 6 4 questions
ISTQB Foundation Exam format and question writing guidelines
All ISTQB Foundation exams will use the same format, which will consist of the following components:
• 40 multiple choice questions (4 answers per question)
• 1 hour exam (set and managed by authorised examination boards)
• Score more than 60% (25 or more) to pass
• Each exam, if produced manually, will be live for a maximum of 6 months, otherwise each new exam to be created automatically each time
• Exam questions, whilst still ‘live’ in the question bank, can be reused as required by Exam setters
-----------------------------------------------------------------------------
For a 40 question paper, the breakdown should be:
Chapter 1 7 questions
Chapter 2 6 questions
Chapter 3 3 questions
Chapter 4 12 questions
Chapter 5 8 questions
Chapter 6 4 questions
Subscribe to:
Posts (Atom)