Software Engineering - Software Modelling & Design
EXPLAIN : WHAT IS ANALYSIS MODELLING
- Software Engineer / Developer perform Analysis Modelling & Create an Analysis Model to provide Information of "What" Software should do instead of "How" to fulfill the Requirement in Software.
- The Basic Aim of Analysis Modelling is to Create the Model that Represent the Information, Functions & Behavior of the System to be Built.
- The Function, Behavior & Information of the System are Translated into Architecture, Interface & Component Level Designs in Design Modelling.
- Analysis Model uses a Combination of Text & Diagrammatic Forms to Depict Requirement.
- Analysis Model operates as a Link between the System Description & the Design Model.
DEFINE : OBJECTIVES OF ANALYSIS MODELLING
- To describe what are the Customer Requirements.
- To establish a base for the creation of a Software Design.
- To define a set of Requirements which can be Validated once, The Software is built or Developed.
DIAGRAM : ANALYSIS MODELLING
EXPLAIN : ANALYSIS MODELLING APPROACH
- Analysis Model comprises 2 Approaches (i.e - Structured Analysis & Object Oriented Analysis)
- Structured Analysis expresses Information through Data Flow Diagram whereas Object Oriented Analysis specifies the Functional & Behavior Information using Objects.
EXPLAIN : STRUCTURED ANALYSIS
- Analysis Modelling can also be known as Structured Analysis.
- Structured Analysis is a Top Down Approach.
- The purpose of Structured Analysis is to provide a Graphical Representation to Develop new Software.
EXPLAIN : OBJECT ORIENTED ANALYSIS
- Object Oriented Analysis specifies that what the System is to do in terms of the Real World Objective and not in the terms of Separate Functional Data.
- STEPS:
- Define User View of the Requirements.
- Identify Analysis Objects & their Characteristics.
- Determine Object Interaction's & Relationship.
- Object Oriented Approach is used to describe System Requirements using Prototype.
- Object Oriented Analysis defines a System as a Set of Object which Interact with each other by the Services they provide.
EXPLAIN : ELEMENTS OF ANALYSIS MODEL
- Scenario Based Element : It represents the System User Point of View (Example - Use Case Diagram & User Stories)
- Class Based Element : It represents the Object, Attributes & Relationship (Example - Class Diagram & Collaboration Diagram)
- Behavioral Elements : It represents the State of System & how the External Events affect it (Example - Sequenced Diagram & State Diagram)
- Flow Oriented Diagram : It represents the way of Transforming Data Objects when they flow between the Different System Functions (Example - Data Flow Diagram & Control Flow Diagram)
EXPLAIN : DOMAIN ANALYSIS
- Domain Analysis / Software Domain Analysis is the Identification, Analysis & Specification of Common Requirements from a Specific Application Domain.
- It is simply a process of Analyzing Related Software Systems in a Domain to find their Common & Variable parts.
- It is a Model of Wider Business Context for the System.
EXPLAIN : TRANSLATING THE REQUIREMENTS MODEL INTO DESIGN MODEL
- Software Design encompasses the Set of Principles, Concepts & Practices that lead to the Development of a High Quality System or Product.
- Design Concepts must be understood before the Design Practices are Applied.
- Design Practice serve as a Guide for the Construction Activity that follows.
- The Design Model provides Details about Software Data Structures, Architectures, Interfaces & Components that are Necessary to Implement of the System.
- As per Mitch Kapor, Good Software Design should Exhibit:
- Firmness : A Program should not have any Bugs that Inhibit it's Function.
- Commodity : A Program should be Suitable for the Purposes for which it was Intended.
- Delight : The Experience of using the Program should be Pleasurable One.
EXPLAIN : WHAT IS A DATA ATTRIBUTE
- An Attribute is a Characteristic of an Entity Entities are represented by Means of their Attributes.
- All Attributes have their own Specific Values.
- Example : An Employee Entity may have Employee ID, Employee Name, Salary as the Attributes.
EXPLAIN : WHAT ARE RELATIONSHIPS
- The Association between 2 Different Entities is called a Relationship.
- In the Real World Application, What does 1 Entity do with the other, How do they Connect with Each Other.
- Example : An Employee Works at a Department. Then, "Work" will be known as a Relationship.
EXPLAIN : WHAT IS CARDINALITY
- It specifies the Number of Occurrences Instances of 1 Data Object or An Entity that relates to the Number of Occurrence of Another Data Object or the Entity.
EXPLAIN : WHAT IS MODALITY
- It describes the Possibility that whether a Relationship between 2 or more Entities or Data Object is required.
EXPLAIN : MODULARITY
- Modularity can be achieved by the process of Dividing the Software into Components which are Uniquely Named & Addresses-able. These Components are also known as the "Modules".
- When the Development is completed, The Modules are integrated to form an Entire Project.
EXPLAIN : CONCURRENCY
- It is important to Utilize the Resources efficiently as much as possible. For this purpose, Multiple Tasks must be Executed Concurrently.
- This Aspect makes Concurrency one of the important Concepts of the Software Design.
- For Example, If the currently Executing Process is waiting for some Resource, The System must be able to Execute any pther Process in the Mean Time.
EXPLAIN : DATA FLOW DIAGRAM
- The Data Flow Diagram (DFD) is a Graphical Representation of the Flow of Data through an Information System.
- A Data Flow Diagram is also known as a Bubble Chart or Work Flow Diagram.
- A DFD Maps out the Flow of Information for any Process / System.
- It uses defined Symbols like Rectangles, Circles & Arrows to show Data Outputs.
ENLIST : TYPES OF DFDs
- Logical Data Flow Diagrams.
- Physical Data Flow Diagrams.
DEFINE : TYPES OF DFDs
- Logical DFD : A Logical DFD captures the Data Flows that are necessary for a System to Operate. It describes the Processes that are Undertaken, The Data required & produced by each Process, And the stores that are needed to Hold the Data.
- Physical DFD : Physical DFD captures how the System is actually Implemented , Either at the Moment or at (Current Physical DFD) how the Designer Intends it to be in the Future (Required Physical DFD).
EXPLAIN : LEVELS OF DFDs
- Level O DFDs :These are also referred as Context Diagrams which are considered as the Most Basic Data Flow Diagram. These Diagrams provide a Broad View, Which is very easy to Understand...But offers Little Detail.
- Level 1 DFDs :These Diagrams also provide the same General Overview, But with More Details as compared to the Level "0". One Process Node from the Context Diagram is Broken Down into Several Relevant Sub-Processes.
- Level 2+ DFDs : These Diagrams Break the Processes down into More Detailed Sub-Processes. Theoretically, DFDs could go Beyond Level 3, But it is a very Rare Case. Thus, Here the Data Flow Diagram is considered Detailed enough as there is no need to Break them down further.
DEFINE : ADVANTAGES OF DFDs
- A DFD is used as the Part of Documentation File.
- DFD can provide a Detailed Representation of the System Components.
DEFINE : DIS-ADVANTAGES OF DFDs
- The DFD takes a Long Time to get Developed / Created.
- Physical Considerations are Left Out with DFD.
ENLIST : SYMBOLS IN DFDs & DIAGRAM
DEFINE : SYMBOLS IN DFDs
- External Entity : It Sends / Receives Data from the System. It can represent a Machine, Organization & Etc.
- Process : It is a part of the System which Transforms the Inputs to Outputs. The Symbol of a Process is a Circle, Oval, Rectangle or a Rectangle with Rounded Corners.
- Data Store / Warehouse : It is used to store the Data for Later Use. The Symbol of the Store is 2 Horizontal Lines, The Other Way is shown in the DFD Notations.
- Data Flow :It shows the Transfer of Information from One Part of the System to the Another. The Symbol of a Data Flow is an "Arrow".
EXPLAIN : WHAT IS TESTING
- A Test is an Experiment Designed to Reveal Information, Or to Answer a Specific Question about the Software or the System.
- Simply, Testing is Executing a System in order to Identify any Gaps, Error or Missing Requirements.
EXPLAIN : IMPORTANCE OF TESTING
- Software Testing is necessary Because Mistakes are Occurred in Software Development by Everyone.
- It is very important to Ensure the Quality of the Product or the Software Application.
EXPLAIN : OBJECTIVES / GOALS OF TESTING
- Finding the Defects which may Get Created by the Programmer.
- To Prevent the Defects developed in the Software Project.
- To Gain Confidence of the Customer.
ENLIST : LEVELS OF TESTING
- Unit Testing.
- Integration Testing.
- System Testing.
- Acceptance Testing.
EXPLAIN : LEVELS OF TESTING
- Unit Testing : A Level of the Software Testing Process Where Individual Units of a Software are Tested. The Purpose to Validate that Each of the Software Performs are Designed. It has Many Inputs, But a Single Output.
- Integration Testing : A Level of Software Testing Process Where Units are Combined & Tested as a Group. The Purpose of this Level of Testing is to Expose Faults in the Interaction Between Units.
- System Testing : A Level of Software Testing Process Where a Complete Integrated System is Tested. The Purpose of this Test is to Evaluate the System's Compliance with the Specified Requirements.
- Acceptance Testing : A Level of Software Testing Process Where a System is Tested for Acceptability. The Purpose of this Level of Software Testing is to Evaluate the System for Compliance with the Business Requirements.
COMPARE : VERIFICATION V/S VALIDATION
- Checks whether we are Building the Right Product / Checks whether we are Building the Product Right.
- It is done without Executing the Software / It is done with Executing the Software.
- Includes all the Static Testing Techniques / Includes all the Dynamic Testing Techniques.
- It is based on the Process / It is based on the Product.
- It is Developed by the Programmers / It is Developed by the Testers.
EXPLAIN : BLACK BOX TESTING
- Black Box Testing checks the Functional Requirements & Examines the Input & Output Data of these Requirements.
- When Black Box Testing is performed, Only Set of Legal Inputs & Corresponding Outputs should be known as the Tester.
- In Black Box Testing, It Examines the Functionality without knowing the Internal Structure & Workings of the Software Project.
DIAGRAM : BLOCK BOX TESTING
DEFINE : ADVANTAGES OF "BB" TESTING
- In Black Box Testing, The Access of Source Code is Not Required.
- BBT clearly Separates User's Perspective from the Developer's Perspective.
- It is Efficient when used on the Large Systems.
DEFINE : DIS-ADVANTAGES OF "BB" TESTING
- The Test Cases are Difficult to Design in BBT.
- Black Box Testing has Limited Storage.
- Tests can be Repeated which are already Tested by the Programmer.
EXPLAIN : WHITE BOX TESTING
- White Box Testing is also known as Structure Testing & Glass Testing.
- White Box Testing needs more Structural Understanding & Knowledge of the Software Structure & Implementation.
- Here, The Testers Require the Knowledge of "How the Software is Implemented?" & "How it Works?".
DIAGRAM : WHITE BOX TESTING
DEFINE : ADVANTAGES OF "WB" TESTING
- Tester also has the Knowledge of the Source Code & Implementation.
- WBT Tests are Easy to Automate.
- WBT can Cover mostly all the Paths.
DEFINE : DIS-ADVANTAGES OF "WB" TESTING
- White Box Testing is Difficult to Maintain.
- The Cost of this Testing is More due to Detailed Work.
- Highly Skilled Resources are Required.
COMPARE : BLACK BOX V/S WHITE BOX TESTING
- The Internal Working of the Application is not Checked or Required / The Internal Working of the Application is Checked or Required.
- It is also known as Closed Bar Testing & Data Drive Testing / It is also known as Clear Bar Testing & Structural Testing.
- It is Not Suited for Algorithm Testing / It can be Suited for Algorithm Testing.
- It is carried out by the Testers / It is carried out by the Dev.
- It does the Functional Testing, External Testing / It does the Structural Testing, Interior Testing.
EXPLAIN : WHAT IS UNIT TESTING
- Unit Testing Is A Level Of Software Testing Where Individual Units/components Of A Software Are Tested.
- The Purpose Is To Validate That Each Unit Of The Software Performs As Designed. A Unit Is The Smallest Testable Part Of Any Software.
- It Usually Has One Or A Few Inputs And Usually A Single Output.
DEFINE : ADVANTAGES OF UNIT TESTING
- The Bugs are found Easily in Unit Testing.
- Unit Testing helps in Simplifying the Debugging Process.
- It also Helps in Maintaining & Changing the Code.
DEFINE : DIS-ADVANTAGES OF UNIT TESTING
- Unit Testing cannot catch each Bug in the Project.
- It Cannot Evaluate every Execution Path.
- It is not the best Testing Technique comparatively to Others.
EXPLAIN : TEST DOCUMENTATION
- Testing the Documentation involves the Documentation of Artifacts which should be Developed Before or During the Testing of Software.
- Documentation for Software Testing helps in Estimating the Testing Effort Required, Test Coverage, Requirement Tracking / Tracing & Etc.
- Examples : Test Plan, Test Case Template, Introduction to Defect Report & Test Summary Report.
EXPLAIN : TEST PLAN
- A Test Plan illustrates the Strategy which will be used for testing of an Application, The Necessary Resources, The Test Environment that will be used to Perform the test.
- Usually a Test Plan is Generated by the Quality Assurance Team Lead.
- Test Plan Includes : Introduction to the Test Plan, Considerations while Testing the Application, List of Test Cases involved in Testing the Application, Type of Approach to use during the testing the Software & Etc.
EXPLAIN : TEST CASE TEMPLATES
- Test Case is a Group of Positive & Negative Scenarios which are Executed to Test the Specific Functionality of Our Software Application.
- A Test Case is a Document which includes set of Test Data, Pre-Conditions, Expected Results & the Actual Result created for the Specific Test Scenario.
- It simply acts like the Starting Point for the Test Execution, And after Applying a Set of Input Data, the Application has a Specific Output which is called at the Actual Result.
ENLIST : TYPES OF INTEGRATION TESTING
- Top Down Integration.
- Bottom Up Integration.
EXPLAIN : TYPES OF INTEGRATION TESTING W/ DIAGRAM
- Top Down Integration : In this Integration, The Modules are Integrated by Moving Downwards through the Control Hierarchy, Which begins with the Main Module. The Subordinate Modules are In-Corporated in either a "Depth First" or "Breath First" Fusion.
- Bottom Up Integration : Since, Integration & Testing starts with the most Atomic Modules in the Control Hierarchy. This Approach Verifies Low-Level Data Processing Early in the Testing Process.\
COMPARE : ALPHA V/S BETA TESTING
- It is always Performed by the Developers at the Software Development Site / It is always Performed by the Customers at Their Site.
- Alpha Testing is Conducted by a Group of Highly Skilled Testers at the Development Site / Beta Testing is always Conducted at the Customers / Users at Their Site.
- It is Conducted for the Software Application & Project / It is Usually Conducted for the Software Product.
- It is always Performed in a Virtual Environment / It is always Performed in a Live Environment.
- It is always Performed within the Organization / It is always Performed outside the Organization.
- It comes under the White Box Testing & the Black Box Testing / It only comes under the Black Box Testing.
EXPLAIN : TEST SUMMARY REPORTS
- Test Summary Report is Considered as a Formal Document which Summarizes the Results regarding all Testing Efforts for a Specific Testing Cycle of a Project / Module or a Sub-Module.
- Usually this Document is Prepared by the Test Leads or the Test Managers at the end of the Testing Cycle.
- At the End of the Project, We have to Publish the Closure Report.
- Software Engineer / Developer perform Analysis Modelling & Create an Analysis Model to provide Information of "What" Software should do instead of "How" to fulfill the Requirement in Software.
- The Basic Aim of Analysis Modelling is to Create the Model that Represent the Information, Functions & Behavior of the System to be Built.
- The Function, Behavior & Information of the System are Translated into Architecture, Interface & Component Level Designs in Design Modelling.
- Analysis Model uses a Combination of Text & Diagrammatic Forms to Depict Requirement.
- Analysis Model operates as a Link between the System Description & the Design Model.
DEFINE : OBJECTIVES OF ANALYSIS MODELLING
- To describe what are the Customer Requirements.
- To establish a base for the creation of a Software Design.
- To define a set of Requirements which can be Validated once, The Software is built or Developed.
DIAGRAM : ANALYSIS MODELLING
EXPLAIN : ANALYSIS MODELLING APPROACH
- Analysis Model comprises 2 Approaches (i.e - Structured Analysis & Object Oriented Analysis)
- Structured Analysis expresses Information through Data Flow Diagram whereas Object Oriented Analysis specifies the Functional & Behavior Information using Objects.
EXPLAIN : STRUCTURED ANALYSIS
- Analysis Modelling can also be known as Structured Analysis.
- Structured Analysis is a Top Down Approach.
- The purpose of Structured Analysis is to provide a Graphical Representation to Develop new Software.
EXPLAIN : OBJECT ORIENTED ANALYSIS
- Object Oriented Analysis specifies that what the System is to do in terms of the Real World Objective and not in the terms of Separate Functional Data.
- STEPS:
- Define User View of the Requirements.
- Identify Analysis Objects & their Characteristics.
- Determine Object Interaction's & Relationship.
- Object Oriented Approach is used to describe System Requirements using Prototype.
- Object Oriented Analysis defines a System as a Set of Object which Interact with each other by the Services they provide.
EXPLAIN : ELEMENTS OF ANALYSIS MODEL
- Scenario Based Element : It represents the System User Point of View (Example - Use Case Diagram & User Stories)
- Class Based Element : It represents the Object, Attributes & Relationship (Example - Class Diagram & Collaboration Diagram)
- Behavioral Elements : It represents the State of System & how the External Events affect it (Example - Sequenced Diagram & State Diagram)
- Flow Oriented Diagram : It represents the way of Transforming Data Objects when they flow between the Different System Functions (Example - Data Flow Diagram & Control Flow Diagram)
EXPLAIN : DOMAIN ANALYSIS
- Domain Analysis / Software Domain Analysis is the Identification, Analysis & Specification of Common Requirements from a Specific Application Domain.
- It is simply a process of Analyzing Related Software Systems in a Domain to find their Common & Variable parts.
- It is a Model of Wider Business Context for the System.
EXPLAIN : TRANSLATING THE REQUIREMENTS MODEL INTO DESIGN MODEL
- Software Design encompasses the Set of Principles, Concepts & Practices that lead to the Development of a High Quality System or Product.
- Design Concepts must be understood before the Design Practices are Applied.
- Design Practice serve as a Guide for the Construction Activity that follows.
- The Design Model provides Details about Software Data Structures, Architectures, Interfaces & Components that are Necessary to Implement of the System.
- As per Mitch Kapor, Good Software Design should Exhibit:
- Firmness : A Program should not have any Bugs that Inhibit it's Function.
- Commodity : A Program should be Suitable for the Purposes for which it was Intended.
- Delight : The Experience of using the Program should be Pleasurable One.
EXPLAIN : WHAT IS A DATA ATTRIBUTE
- An Attribute is a Characteristic of an Entity Entities are represented by Means of their Attributes.
- All Attributes have their own Specific Values.
- Example : An Employee Entity may have Employee ID, Employee Name, Salary as the Attributes.
EXPLAIN : WHAT ARE RELATIONSHIPS
- The Association between 2 Different Entities is called a Relationship.
- In the Real World Application, What does 1 Entity do with the other, How do they Connect with Each Other.
- Example : An Employee Works at a Department. Then, "Work" will be known as a Relationship.
EXPLAIN : WHAT IS CARDINALITY
- It specifies the Number of Occurrences Instances of 1 Data Object or An Entity that relates to the Number of Occurrence of Another Data Object or the Entity.
EXPLAIN : WHAT IS MODALITY
- It describes the Possibility that whether a Relationship between 2 or more Entities or Data Object is required.
EXPLAIN : MODULARITY
- Modularity can be achieved by the process of Dividing the Software into Components which are Uniquely Named & Addresses-able. These Components are also known as the "Modules".
- When the Development is completed, The Modules are integrated to form an Entire Project.
EXPLAIN : CONCURRENCY
- It is important to Utilize the Resources efficiently as much as possible. For this purpose, Multiple Tasks must be Executed Concurrently.
- This Aspect makes Concurrency one of the important Concepts of the Software Design.
- For Example, If the currently Executing Process is waiting for some Resource, The System must be able to Execute any pther Process in the Mean Time.
EXPLAIN : DATA FLOW DIAGRAM
- The Data Flow Diagram (DFD) is a Graphical Representation of the Flow of Data through an Information System.
- A Data Flow Diagram is also known as a Bubble Chart or Work Flow Diagram.
- A DFD Maps out the Flow of Information for any Process / System.
- It uses defined Symbols like Rectangles, Circles & Arrows to show Data Outputs.
ENLIST : TYPES OF DFDs
- Logical Data Flow Diagrams.
- Physical Data Flow Diagrams.
DEFINE : TYPES OF DFDs
- Logical DFD : A Logical DFD captures the Data Flows that are necessary for a System to Operate. It describes the Processes that are Undertaken, The Data required & produced by each Process, And the stores that are needed to Hold the Data.
- Physical DFD : Physical DFD captures how the System is actually Implemented , Either at the Moment or at (Current Physical DFD) how the Designer Intends it to be in the Future (Required Physical DFD).
EXPLAIN : LEVELS OF DFDs
- Level O DFDs :These are also referred as Context Diagrams which are considered as the Most Basic Data Flow Diagram. These Diagrams provide a Broad View, Which is very easy to Understand...But offers Little Detail.
- Level 1 DFDs :These Diagrams also provide the same General Overview, But with More Details as compared to the Level "0". One Process Node from the Context Diagram is Broken Down into Several Relevant Sub-Processes.
- Level 2+ DFDs : These Diagrams Break the Processes down into More Detailed Sub-Processes. Theoretically, DFDs could go Beyond Level 3, But it is a very Rare Case. Thus, Here the Data Flow Diagram is considered Detailed enough as there is no need to Break them down further.
DEFINE : ADVANTAGES OF DFDs
- A DFD is used as the Part of Documentation File.
- DFD can provide a Detailed Representation of the System Components.
DEFINE : DIS-ADVANTAGES OF DFDs
- The DFD takes a Long Time to get Developed / Created.
- Physical Considerations are Left Out with DFD.
ENLIST : SYMBOLS IN DFDs & DIAGRAM
DEFINE : SYMBOLS IN DFDs
- External Entity : It Sends / Receives Data from the System. It can represent a Machine, Organization & Etc.
- Process : It is a part of the System which Transforms the Inputs to Outputs. The Symbol of a Process is a Circle, Oval, Rectangle or a Rectangle with Rounded Corners.
- Data Store / Warehouse : It is used to store the Data for Later Use. The Symbol of the Store is 2 Horizontal Lines, The Other Way is shown in the DFD Notations.
- Data Flow :It shows the Transfer of Information from One Part of the System to the Another. The Symbol of a Data Flow is an "Arrow".
EXPLAIN : WHAT IS TESTING
- A Test is an Experiment Designed to Reveal Information, Or to Answer a Specific Question about the Software or the System.
- Simply, Testing is Executing a System in order to Identify any Gaps, Error or Missing Requirements.
EXPLAIN : IMPORTANCE OF TESTING
- Software Testing is necessary Because Mistakes are Occurred in Software Development by Everyone.
- It is very important to Ensure the Quality of the Product or the Software Application.
EXPLAIN : OBJECTIVES / GOALS OF TESTING
- Finding the Defects which may Get Created by the Programmer.
- To Prevent the Defects developed in the Software Project.
- To Gain Confidence of the Customer.
ENLIST : LEVELS OF TESTING
- Unit Testing.
- Integration Testing.
- System Testing.
- Acceptance Testing.
EXPLAIN : LEVELS OF TESTING
- Unit Testing : A Level of the Software Testing Process Where Individual Units of a Software are Tested. The Purpose to Validate that Each of the Software Performs are Designed. It has Many Inputs, But a Single Output.
- Integration Testing : A Level of Software Testing Process Where Units are Combined & Tested as a Group. The Purpose of this Level of Testing is to Expose Faults in the Interaction Between Units.
- System Testing : A Level of Software Testing Process Where a Complete Integrated System is Tested. The Purpose of this Test is to Evaluate the System's Compliance with the Specified Requirements.
- Acceptance Testing : A Level of Software Testing Process Where a System is Tested for Acceptability. The Purpose of this Level of Software Testing is to Evaluate the System for Compliance with the Business Requirements.
COMPARE : VERIFICATION V/S VALIDATION
- Checks whether we are Building the Right Product / Checks whether we are Building the Product Right.
- It is done without Executing the Software / It is done with Executing the Software.
- Includes all the Static Testing Techniques / Includes all the Dynamic Testing Techniques.
- It is based on the Process / It is based on the Product.
- It is Developed by the Programmers / It is Developed by the Testers.
EXPLAIN : BLACK BOX TESTING
- Black Box Testing checks the Functional Requirements & Examines the Input & Output Data of these Requirements.
- When Black Box Testing is performed, Only Set of Legal Inputs & Corresponding Outputs should be known as the Tester.
- In Black Box Testing, It Examines the Functionality without knowing the Internal Structure & Workings of the Software Project.
DIAGRAM : BLOCK BOX TESTING
DEFINE : ADVANTAGES OF "BB" TESTING
- In Black Box Testing, The Access of Source Code is Not Required.
- BBT clearly Separates User's Perspective from the Developer's Perspective.
- It is Efficient when used on the Large Systems.
DEFINE : DIS-ADVANTAGES OF "BB" TESTING
- The Test Cases are Difficult to Design in BBT.
- Black Box Testing has Limited Storage.
- Tests can be Repeated which are already Tested by the Programmer.
EXPLAIN : WHITE BOX TESTING
- White Box Testing is also known as Structure Testing & Glass Testing.
- White Box Testing needs more Structural Understanding & Knowledge of the Software Structure & Implementation.
- Here, The Testers Require the Knowledge of "How the Software is Implemented?" & "How it Works?".
DIAGRAM : WHITE BOX TESTING
DEFINE : ADVANTAGES OF "WB" TESTING
- Tester also has the Knowledge of the Source Code & Implementation.
- WBT Tests are Easy to Automate.
- WBT can Cover mostly all the Paths.
DEFINE : DIS-ADVANTAGES OF "WB" TESTING
- White Box Testing is Difficult to Maintain.
- The Cost of this Testing is More due to Detailed Work.
- Highly Skilled Resources are Required.
COMPARE : BLACK BOX V/S WHITE BOX TESTING
- The Internal Working of the Application is not Checked or Required / The Internal Working of the Application is Checked or Required.
- It is also known as Closed Bar Testing & Data Drive Testing / It is also known as Clear Bar Testing & Structural Testing.
- It is Not Suited for Algorithm Testing / It can be Suited for Algorithm Testing.
- It is carried out by the Testers / It is carried out by the Dev.
- It does the Functional Testing, External Testing / It does the Structural Testing, Interior Testing.
EXPLAIN : WHAT IS UNIT TESTING
- Unit Testing Is A Level Of Software Testing Where Individual Units/components Of A Software Are Tested.
- The Purpose Is To Validate That Each Unit Of The Software Performs As Designed. A Unit Is The Smallest Testable Part Of Any Software.
- It Usually Has One Or A Few Inputs And Usually A Single Output.
DEFINE : ADVANTAGES OF UNIT TESTING
- The Bugs are found Easily in Unit Testing.
- Unit Testing helps in Simplifying the Debugging Process.
- It also Helps in Maintaining & Changing the Code.
DEFINE : DIS-ADVANTAGES OF UNIT TESTING
- Unit Testing cannot catch each Bug in the Project.
- It Cannot Evaluate every Execution Path.
- It is not the best Testing Technique comparatively to Others.
EXPLAIN : TEST DOCUMENTATION
- Testing the Documentation involves the Documentation of Artifacts which should be Developed Before or During the Testing of Software.
- Documentation for Software Testing helps in Estimating the Testing Effort Required, Test Coverage, Requirement Tracking / Tracing & Etc.
- Examples : Test Plan, Test Case Template, Introduction to Defect Report & Test Summary Report.
EXPLAIN : TEST PLAN
- A Test Plan illustrates the Strategy which will be used for testing of an Application, The Necessary Resources, The Test Environment that will be used to Perform the test.
- Usually a Test Plan is Generated by the Quality Assurance Team Lead.
- Test Plan Includes : Introduction to the Test Plan, Considerations while Testing the Application, List of Test Cases involved in Testing the Application, Type of Approach to use during the testing the Software & Etc.
EXPLAIN : TEST CASE TEMPLATES
- Test Case is a Group of Positive & Negative Scenarios which are Executed to Test the Specific Functionality of Our Software Application.
- A Test Case is a Document which includes set of Test Data, Pre-Conditions, Expected Results & the Actual Result created for the Specific Test Scenario.
- It simply acts like the Starting Point for the Test Execution, And after Applying a Set of Input Data, the Application has a Specific Output which is called at the Actual Result.
ENLIST : TYPES OF INTEGRATION TESTING
- Top Down Integration.
- Bottom Up Integration.
EXPLAIN : TYPES OF INTEGRATION TESTING W/ DIAGRAM
- Top Down Integration : In this Integration, The Modules are Integrated by Moving Downwards through the Control Hierarchy, Which begins with the Main Module. The Subordinate Modules are In-Corporated in either a "Depth First" or "Breath First" Fusion.
- Bottom Up Integration : Since, Integration & Testing starts with the most Atomic Modules in the Control Hierarchy. This Approach Verifies Low-Level Data Processing Early in the Testing Process.\
COMPARE : ALPHA V/S BETA TESTING
- It is always Performed by the Developers at the Software Development Site / It is always Performed by the Customers at Their Site.
- Alpha Testing is Conducted by a Group of Highly Skilled Testers at the Development Site / Beta Testing is always Conducted at the Customers / Users at Their Site.
- It is Conducted for the Software Application & Project / It is Usually Conducted for the Software Product.
- It is always Performed in a Virtual Environment / It is always Performed in a Live Environment.
- It is always Performed within the Organization / It is always Performed outside the Organization.
- It comes under the White Box Testing & the Black Box Testing / It only comes under the Black Box Testing.
EXPLAIN : TEST SUMMARY REPORTS
- Test Summary Report is Considered as a Formal Document which Summarizes the Results regarding all Testing Efforts for a Specific Testing Cycle of a Project / Module or a Sub-Module.
- Usually this Document is Prepared by the Test Leads or the Test Managers at the end of the Testing Cycle.
- At the End of the Project, We have to Publish the Closure Report.