Seven Core Principles for Software Engineering: Testability: Software testability is simply how easily a computer program can

Software testability is simply how easily a computer program can be tested.

1. The reason that the software exists: A software system exists for one reason: to provide value to its White box testing: White box testing is a software testing method in which the internal
users. All decisions should be made with this in mind. 2. Keep it simple: Software design is not a structure/design/implementation of the item being tested is known to the tester.
haphazard process. There are many factors to consider in any design effort. All design should be as Black box testing: Black box testing is a software testing method in which the internal
simple as possible, but no simpler. 3. Maintain the vision: A clear vision is essential to the success of a structure/design/implementation of the item being tested is not known to the tester.
software project. Without one, a project almost unfailingly ends up being "of two or more minds"
about itself.4. Others will consume what you produce: In some way or other, someone else will use, Difference:
maintain, document, or other- wise depend on being able to understand your system. So, always Criteria Black box testing White box testing
specify, design, and implement knowing someone else will have to understand what you are doing. 5. Definition “ “
Be open to the future: A system with a long lifetime has more value. Never design yourself into a Labels applicable to Mainly applicable to higher Mainly applicable to lower
corner. Al- ways ask "what if," and prepare for all possible answers by creating systems that solve the label testing label testing
general problem, not just the specific one." This could very possibly lead to the reuse of an entire Responsibility Generally independent Generally software developer
system. 6. Plan ahead for software reuse: Reuse of software reduces the long-term cost and increases software tester
the value of the program and the reusable components 7. Think, and then act: This last Principle is Programming knowledge Not Required Required
probably the most overlooked. Placing clear, complete thought before action will almost always
Implementation Knowledge Not required Required
produce better results.
Basis of test case Requirement specification Detail design
Communication Practices: (All are same)
Rules of thumb: 1. The model should focus on requirements that are visible within the problem or
Communication: Project initiation, Requirements, gathering > Planning: Estimating,, Scheduling,
business domain. The level of abstraction should be relatively high. 2. Each elements of the analysis
Tracking > Modeling: Analysis, Design > Construction: Code, Test > Deployment: Delivery, Support,
model should be add to an overall understanding of software requirements and provide insight into
Feedback
the information domain, function and behavior of the system. 3. Delay consideration of infrastructure
and other non-functional models until design. 4. Minimize coupling throughout the system. 5. Be
Communication Principles:
certain that the analysis model provides values to all stakeholders. 6. Keep the model as simple as it
1. Listen. Try to focus on the speaker's words, rather than formulating your response to those words.
can be.
Ask for clarification if something is unclear, but avoid constant interruptions. 2. Prepare before you
communicate. Spend the time to understand the problem before you meet with others. If necessary,
Data Attributes: Data attributes defines the properties of the data object and take on one of 3
do some research to understand business domain jargon. 3. Someone should facility the activity. Every
different characteristics. 1. Name an instance of the data object. 2. Describe the instance 3. Make
communication meeting should have a leader to keep the conversation moving in a productive
reference to another instance.
direction; to mediate any conflict that does occur; to ensure than other principles are followed. 4.
Face-to-face communication is best. Face-to-face communication is best. But it usually works better
Cardinality: Cardinality is the specification of the number of instance of a data object that can be
when some other representation of the relevant information is present. For ex- ample, a participant
related to the number of occurrence of another data object.
may create a drawing or a "strawman” document that serves as a focus for discussion. 5. Take notes
Modality: Modality provides an indication whether or not a data object must participate in the
and document decisions. Things have a way of falling into the cracks. Someone participating in the
relationship.
communication should serve as a "recorder" and write down all important points and decisions. 6.
Relationship: Relationship indicates connectedness, a fact that must be remembered by the system
Strive for collaboration. Collaboration and consensus occur when the collective knowledge of members
and cannot or is not computed or derived mechanically. 1. Several instances of a relationship can exist.
of the team is combined to describe product or system functions or features. Each small collaboration
2. Objects can be related in many ways.
serves to build trust among team members and creates a common goal for the team. 7. Stay focused
on a topic, modularize your discussion. The more people involved in any communication, the more
Notation: How many occurrences of object X are related to how many occurrences of object of Y.
likely that discussion will bounce from one topic to the next. 8. If something is unclear, draw a picture. .
1. One to one(1:1) 2. One to many(1:N) 3. Many to many(M:N) modality notation: =0 => optional
Verbal communication goes only so far. A sketch or drawing can often provide clarity when words fail
relationship. 2. =1 => relationship must appear.
to do the job.
Encapsulation: Data encapsulation means to bind data and logical
procedure in one form to manipulate the data.
Planning Principles:
Class hierarchy:
1. Understand the scope of the project. It's impossible to use a road map if you don't know where
you’re going. Scope provides the software team with a destination. 2. Involve the customer in
the planning activity. The customer defines priorities and establishes project constraints. 3. Recognize
that planning is iterative. A project plan is never engraved in stone. As work begins, it is very likely that
things will change. 4. Estimate based on what you know. The intent of estimation is to provide
an indication of effort, cost, and task duration, based on the team's current understanding of the work
to be done. 5. Consider risk as you define the plan. If the team has defined risks that have high impact
and high probability, contingency planning is necessary. 6. be realistic. People don't work 100 percent
of every day. Noise always enters into any human communication. Omissions and ambiguity are facts
Activity Diagram:
of life. 7. Adjust granularity as you define the plan. Granularity refers to the level of detail that is
introduced as a project plan is developed.
Analysis Modeling Principles:
1. The information domain of a problem must be represented and understood. The information
domain encompasses the data that flow into the system. 2. The Junctions that the software performs
must be defined. Software functions provide direct benefit to end-users and also provide internal
support for those features that are user visible. 3. The behavior of the software must be represented.
The behavior of computer software is driven by its interaction with the external environment. Input
provided by end-users, control data provided by an external system, or monitoring data collected
over a network all cause the software to behave in a specific way. 4. The models that depict
information function and behavior must be partitioned in a manner that uncovers detail in a layered
(or hierarchical) fashion 5. The analysis task should move from essential information toward
implementation detail.

Design Modeling Principles:

1. Design should be traceable to the analysis model. The analysis model describes the information
domain of the problem, user visible functions, system behavior, and a set of analysis classes that
package business objects with the methods that service them. 2. Always consider the architecture
of the system to be built. Software architecture is the skeleton of the system to be built. 3. Design of
data is as important as design of processing functions. Data design is an essential element of
architectural design. The manner in which data objects are realized within the design cannot be left to
chance. 4. Interfaces must be designed with care. The manner in which data flows between the
components of a system has much to do with processing efficiency, error propagation, and design
simplicity. 5. User interface design should be tuned to the needs of the end-user. However, in every
case, if should stress ease of use. The user interface is the visible manifestation of the software. 6.
Component-level design should be functionally independent. Functional independence is a measure
of the "single-mindedness" of a software component.

Testing Principles:
1. All tests should be traceable to customer requirements. The objective of software testing is to
uncover errors. It follows that the most severe defects are those that cause the program to fail to meet
its requirements. 2. Tests should be planned long before testing begins. Test planning can begin as
soon as the analysis model is complete. 3. The Pareto principle applies to software testing. Stated
simply, the Pareto principle implies that 80 percent of all errors uncovered during testing will likely be
traceable to 20 percent of all program components. The problem, of course, is to isolate these suspect
components and to thoroughly test them. 4. Testing should begin “in the small” and progress toward
testing “in the large. The first tests planned and executed generally focus on individual components.
As testing progresses, focus shifts in an attempt to find errors in integrated clusters of components and
ultimately in the entire system. 5. Exhaustive testing is not possible. The number of path
permutations for even a moderately sized program is exceptionally large. For this reason, it is
impossible to execute every combination of paths during testing.
Verification: Verification refers to a set of activity that ensures that software correctly implements a
specific function. Validation: Validation refers to a different set of activities that ensure that the
software has been build is traceable to customer requirements.
Difference:
Verification Validation
Takes place before validation. Cannot takes place before verification
The objective is to ensure that the work products The objective is to ensure that the work product
meet their specification. fulfill its intended use in intended environment.
Evaluate codes, plans, requirements and Evaluates the products itself.
specification.
Question: Are we building the product right? Question: Are we building the right product?
Input is reviews walkthrough and inception. Input is the actual testing of an actual product.
Output is a set of nearly perfect plans Output is nearly perfect product.
requirements and specification.

Software testing strategy:

Software engineering: Software engineering defines the role of the software and leads to software
requirement analysis. Requirements: Software requirements establishes the information domain
function behavior performance constrains and validation criteria for software.

Unit testing: Unit testing focuses verification effort on the smallest unit of software design. The unit
testing focuses on the internal processing logic and data structures within the boundaries of
component. This type of testing can be conducted in parallel for multiple components.
*Interface: Data flows into and out of the program unit under test. *Local data structure: Data storage
temporarily maintains integrity. *Boundary condition: are tested to ensure that the module operates
properly at the boundaries established to limit or restrict processing. *Independent paths: all modules
must be work at least once.

Incremental integration: In incremental integration the program is constructed and tested in small
increment, where errors are easier to isolate and correct.

Top down testing: Top down testing is an approach to integrated testing where the top integration
module is tested and branch of the module is tested step by step until the end of the related module.
Bottom up testing: Bottom up testing is an approach to integrated testing where the lowest level
components are tested first. Then used to facilitate the testing of higher level components. The
process is repeated until the component at the top of the hierarchy is tested.
Deference:

Top Down Testing Bottom up testing

Top down testing is conducted from main
module to sub module.
Top down testing is good if major flows occur
towards the top of the program.
In this test condition is difficult to create.
Observation of test output is difficult.
Bottom up testing is conducted from sub module
to main module.
Bottom up testing is good if major flows occur
towards the bottom of the program.
In this test condition is easy to create.
Observation of test output is easier.

Sandwich Testing: Sandwich testing is approach to combine top down testing to bottom up testing.
Advantage of bottom up approach: 1. Easier test case design. 2. Lack of stub. Disadvantage: 1. The
program as an entity doesn’t exists until the last module is added.

Difference between alpha and beta testing:

Alpha Test
Alpha test occurs before beta test
Alpha test improves product quality and ensure
beta readiness.
This test is for software application
This test occurs in development site
Conducts at virtual environment
Beta Test
Beta test occurs after alpha test.
Beta tests improve product quality and ensure
product readiness.
This test is for software product
This test occurs in customer side environment
Conducts at real time environment

The system hierarchy: The world view is composed of a set of domains which can each be a system or
a system of systems in its own rights. WV={D1,D2,D3……Dn}. Each domain is composed of specific
elements (Ei) each of which serves a role in accomplishing the objective and goal of the domain or
component. Di={E1,E2,E3…..En}. Each element is implemented by specifying technical components
(Cic). Ei={C1,C2,C3……Cic}

System architecture: Three different architecture must be analyzed and designed within the context of
business objective and goals. 1. Data architecture. 2. Application architecture. 3. Technology
infrastructure. 1.Data architecture: Data architecture provides a framework to the information needs
of a business or business function. 2. Application architecture: Application architecture encompasses
those elements of a system that transforms objects within the data architecture for some business
purpose. 2. Technology infrastructure: Technology infrastructure provides the foundation for data and
application architecture.

System modeling with UML: 1. Deployment diagrams: each 3d box depicts a hardware element that is
part of the physical architecture of the system. 2. Activity diagrams: Represents procedural aspects of a
system element. 3. Class diagram: Represent system level elements in terms of the data that describe
the element and the operations that manipulate the data.