PPL_Unit-1
PPL_Unit-1
The design concepts provide the software designer with a foundation from which more
sophisticated methods can be applied. A set of fundamental design concepts has evolved. They
are as follows:
Besides reduction in cost (due to less customization, and shorter learning time), and
flexibility in design, modularity offers other benefits such as augmentation (adding new
solution by merely plugging in a new module), and exclusion. Examples of modular
systems are cars, computers, process systems, solar panels andwind
turbines, elevators and modular buildings. Earlier examples include looms, railroad
signaling systems, telephone exchanges, pipe organs and electric power
distribution systems. Computers use modularity to overcome changing customer
demands and to make the manufacturing process more adaptive to change
(seemodular programming). Modular design is an attempt to combine the advantages
of standardization (high volume normally equals low manufacturing costs) with those
of customization. A downside to modularity (and this depends on the extent of
modularity) is that low quality modular systems are not optimized for performance. This
is usually due to the cost of putting up interfaces between modules.
Modularization is a technique to divide a software system into multiple
discrete and independent modules, which are expected to be capable of
carrying out task(s) independently. These modules may work as basic
constructs for the entire software. Designers tend to design modules such
that they can be executed and/or compiled separately and independently.
Advantage of modularization:
Design notation
Design notations are used when planning and should be able to communicate the purpose of a
program without the need for formal code. Commonly used design notations are:
Pseudocode
Flow charts
Structure chart
Pseudocode
When designing a program, it is useful to lay out how the program might work, before writing it
in a programming language,.
Pseudocode is a design notation that is closely related to the logic of how a program will work. It
lets you detail what your program will do without having to worry about the particular syntax of
your chosen programming language.
There is no specific standard for pseudocode and programmers often have their own version.
Pseudocode can look a lot like code but it does not need to be implemented as strictly.
Programming languages like python, reference language (used by the SQA) and visual basic will
have specific rules around syntax and structure, whereas pseudocode gives more freedom.
There is no strict set of rules for pseudocode, but some of the most widely recognised are:
REPEAT
OUTPUT 'What is the best subject you take?'
INPUT user inputs the best subject they take
STORE the user's input in the answer variable
IF answer = 'Computer Science' THEN
OUTPUT 'Of course it is!'
ELSE
OUTPUT 'Try again!'
UNTIL answer = 'Computer Science'
A programmer who uses pseudocode as part of their planning is able to take time to think about
how their program will work, what variables they might need and what inputs and outputs there
are.
Flow charts
Flow charts show what is going on in a program and how data flows around it. Flow charts can
represent everyday processes, show decisions taken and the result of these decisions.
The diamond shape explains when there is a choice to make. The flow chart shows what happens
depending on the decision made at this point. Flow charts visualise the results of decisions,
showing what will happen in a program, and also when, for example an if statement, is required
to make a decision.
Any other answer results in the user being asked again. If the user does not enter 'Computing
Science', the program will keep going round and round, asking them forever until they enter
Computing Science.
Structure diagrams
Another way of representing a program design is to use a structure diagram. Structure diagrams
break down a problem into smaller sections. These smaller sections can then be worked on one at
a time.
This can be good for big projects where a large problem can be split into smaller tasks for
separate groups, or individuals, to work on.
Below is an example of how a structure diagram might be used to break a large problem down.
This shows how you can take a complex problem and start breaking it down into more
manageable chunks.
In reality, a complex project like building a house would have many more stages, but this
example shows that structure diagrams can help to break down problems when designing a
program.
You would most likely use a structure diagram if you were designing a game and wanted to
break down the overall design problem into individual elements.
Algorithms
An algorithm is a step-by-step procedure for solving a problem in a finite number of steps. It is
essentially some code that accomplishes a certain task.
You might therefore check that the value they enter is between 0 and 130. Anything outside that
range will be flagged up to them as not sensible and they would then be asked to enter an
appropriate value. This type of validation is often used when people fill out forms online.
Tables
A decision table is a good way to deal with combinations of things (e.g. inputs). This technique is
sometimes also referred to as a ’cause-effect’ table. The reason for this is that there is an associated
logic diagramming technique called ’cause-effect graphing’ which was sometimes used to help derive
the decision table (Myers describes this as a combinatorial logic network [Myers, 1979]). However, most
people find it more useful just to use the table described in [Copeland, 2003].
Decision tables provide a systematic way of stating complex business rules, which is
useful for developers as well as for testers.
Decision tables can be used in test design whether or not they are used in specifications,
as they help testers explore the effects of combinations of different inputs and other software
states that must correctly implement business rules.
It helps the developers to do a better job can also lead to better relationships with
them. Testing combinations can be a challenge, as the number of combinations can often be
huge. Testing all combinations may be impractical if not impossible. We have to be satisfied with
testing just a small subset of combinations but making the choice of which combinations to test
and which to leave out is also important. If you do not have a systematic way of selecting
combinations, an arbitrary subset will be used and this may well result in an ineffective test
effort.
A decision table is basically an outstanding technique used in both testing and requirements
management. It is a structured exercise to prepare requirements when dealing with
complex business rules. Also, used in model complicated logic.
Let’s take an example of a finance application, where users pay money – monthly
Repayment or year wise (the term of loan). If user chooses both options, the system will
create a negotiation between two. So, there are two conditions of the loan amount, mention
in the given below table,
Next, recognize all of the combinations in “Yes” and “No” (In Table 2). In each column of
two conditions mention “Yes” or “No”, user will get here four combinations (two to the
power of the number of things to be combined). Note, if user has three things to combine,
they will have eight combinations, with four things, there are 16, etc. Because of this, it’s
always good to take small sets of combinations at once. To keep track on combinations,
give alternate “Yes” and “No” on the bottom row, put two “Yes” and then two “No” on the
row above the bottom row, etc., so the top row will have all “Yes” and then all “No” (Apply
the same principle to all such tables).
In the next step, recognize the exact outcome for each combination (In Table 3). In this
example, user can enter one or both of the two fields. Each combination is sometimes
referred to as a step.
Actions/Outcomes
Process loan money Y Y
Process term Y Y
At this time you didn’t think that what will happen when customer don’t enter anything in
either of the two fields. The table has shown a combination that was not given in the
specification for this example. This combination can result as an error message, so it is
necessary to add another action (In Table 4). This will flash the strength this method to find
out omissions and ambiguities in specifications.
Actions/Outcomes
Process term Y Y
Error message Y
We will provide you some other example that allows the customer to enter both repayment
and term. This will change the outcome of our table, this will generate an error message if
both are entered (Shown in Table 5).
Actions/Outcomes
Process term Y
Error message Y Y
Design techniques
Software testing is a process carried out to check and confirm the delivery potential of the
software. In this procedure, a set of pre-decided inputs are fed into the software and the output
produced is measured against the expected results. This process helps to ensure that the
software is working as desired and can be released into the market. Software released without
sufficient testing can damage the company’s standing in two ways. First, it will generate poor
customer reviews, and second, it will lead to more serious problems such as the leakage of
the customer’s private data. This can severely impair the organization’s business prospects.
Software test design refers to the process of designing different tests that validate the eligibility
of a software before its release in the market. The process of test designing assumes high
priority, as a poorly designed test will lead to improper testing of an application. This, in turn,
leads to failure in identifying defects and consequently, an application containing errors may be
released.
While a developer has to ensure that the software meets the specifications, a business owner
has to ensure that it meets the business’ operational needs. To satisfy these individual goals
and the main aim of the software development process, that is a high-quality output, one will
have to plan, design, and conduct tests in different environments. To ensure that the testing
strategy chalked out is an effective one, following the below-mentioned steps is essential:
There are various types of designing techniques, each of which is suitable for identifying a
particular type of error. Hence, the challenge lies in selecting the right set of relevant test design
techniques for the particular application. Software test design techniques can be broadly
classified into two major categories: static and dynamic techniques.
Static testing can be further divided into two categories based upon whether it is
performed manually or with the help of tools.
Audit
Inspection
Management review
Manual Static Test Design Techniques
These are of the following kinds and differ in the formality of the process.
Walk through:
Walk through is not a formal process of review and is carried out by authors. The authors
guide the participants through the document and try and understand their thought
processes, in order to gain feedback and arrive at a common understanding.
Informal Review:
An informal review aims to improve the quality of the tested product through discussions and
is usually not documented. The preliminary stage of the review may involve assessment by a
two-member team whereas during later stages, the reviewing team size may increase and
may require more meetings.
Technical Review:
A technical review is carried out by a trained moderator or technical expert. It is less formal
as compared to an inspection. It is usually carried out as a peer review without any
participation from management.
Audit:
An audit is an independent examination of all the documents related to the software, carried
out by an external agent. Audits provide increased assurance to the various stakeholders of
the project that the document is up to standards and devoid of any defects.
Inspection:
An inspection is the most formal type of review and is conducted by trained moderators.
During an inspection, the documents and products are examined through a process of
reviews and defects are identified. The defects identified are documented in a logging list or
issue log and a formal follow-up is carried out.
Management Review:
The management review is a cross-functional review undertaken by an organization’s top
management. It includes analyses of customer satisfaction, determination of the cost of poor
quality, performance trends and achievement of objectives defined in the business plan.
The exact opposite of the black box test design technique, white box test design technique
necessitates knowledge of the internal structure of a program. Some of the methods
implemented in this type of technique are:
o Condition Coverage:
Most of the outcomes of test cases designed as per the white box test design technique are
derived by following the condition coverage method. By following this method, the test
cases are designed in a manner that the condition outcomes (the evaluation of a condition
as ‘true’ or ‘false’) are executed automatically.
o Decision Coverage:
In the decision coverage method, the test cases are designed in a manner that the decision
outcomes are executed automatically. It ensures that each possible branch from a decision
point is implemented at least once.
o Statement Coverage:
This method involves calculation of the percentage of executable statements which are
being exercised by the test suite.
o Multiple Condition Coverage:
Every combination of ‘true’ or ‘false’ for the conditions related to a decision have to be
tested in this technique.
As the name suggests, the experience-based technique neither involves internal, nor the
external structure, but is based on experience. Some of the methods followed are:
o Exploratory Testing:
This method, generally conducted by business analysts and experts, is followed to test the
applications without any documentation.
o Fault Attack:
One of the widely used method of the experience based test design technique, fault attack
involves testers anticipating the errors, defect data availability, etc., as per their
experience
The final process of this method is to write test cases to use each of the four steps in our
table.
1. Walk to paper.
1a. Walk to wall
1b. turn right
1c. move
1d. turn left
As this program is relatively simple, I think it can be left at just the one breakdown. However, more
complicated programs will require that steps 1a, 1b, 1c, 1d and 1e are decomposed several times.
For step 2 “pick it up”, the assignment says we can assume there will always be a paper there. To be on
the safe side, we might want to have a bit more detail here and put checks in place such as using an if
statement to check if a paper is present. Also, we could look here at pre-conditions and post-conditions.
We need to know where Karel will be after step 1 and where he needs to be to start step 3. In the
breakdown of “walk to paper” I decided to leave Karel at the inside of the door facing out… so a pre-
condition is that Karel needs to make 1 move to the paper. A post-condition I will set is for Karel is that
he has returned to inside the house facing west which means we need to remember that as a pre-
condition for step 3… returning to the start.
2. Pick it up
2a. Move to paper
2b. Check if paper available
2c. pick up paper
2d. turn around
2e. move (leave facing west)
Now we know that Karel is in the house, facing west we can break down step 3 as follows:
I decided to tackle point 3 a different way. Instead of sending Karel back to the couch the same way he
came in… along the top and right wall. I decided to make him simply continue west till he hits the wall,
then turn right and then move to the top wall.
Initial Solution:
1. Initialize data
2. Get data
3. Calculate results
4. Output results
Refinement:
1. Initialize data
2. get data
2.1 loop
2.2 get integer x
2.3 exit when x < 1
2.4 process x
3. Calculate results
3.1 avg = sum / count
4. Output results
Further refinement (of step 2.4):
o 2.4.1 increase count by 1
o 2.4.2 increase sum by x
There are several steps involved in the top-down approach to software development:
The first step is to define the overall goals and objectives of the system, as well as any
specific requirements or constraints.
Break down the system into smaller components:
Next, the system is broken down into smaller, more manageable components or
modules.
Once the system has been divided into smaller components, each component can be
developed individually.
After each component has been developed and tested individually, they can be
integrated into the larger system.
Once all of the components have been integrated, the entire system can be tested to
ensure that it is functioning as intended.
After the system has been implemented, it will need to be maintained and updated on
an ongoing basis to fix any bugs or to add new features.
It can be inflexible:
Since the design process starts with the big picture, it can be difficult to make changes
later on in the process.
It can be time-consuming:
Breaking down the big picture into smaller pieces can take a lot of time, especially if the
design is complex.
It can be costly:
The top-down approach may require more resources upfront, as all of the planning and
design work needs to be done before the project can be implemented.
With so many pieces and components, it can be challenging to keep track of everything
and ensure that everything is working together as intended.
The top-down approach may not be as effective for projects that require a lot of
creativity and innovation, as it can be inflexible and leave little room for experimentation.
Test plans-Design guidelines
What is a Test Plan?
A test plan is a detailed document that outlines the test strategy, Testing objectives, resources
(manpower, software, hardware) required for testing, test schedule, test estimation and test deliverables.
The test plan serves as a blueprint to conduct software testing activities as a defined process which is
minutely monitored and controlled by the test manager.
Let’s start with following scenario
In a meeting, you want to discuss the Test Plan with the team members, but they are not interested - .
Test Plan helps us determine the effort needed to validate the quality of the application under
test
Help people outside the test team such as developers, business managers,
customers understand the details of testing.
Test Plan guides our thinking. It is like a rule book, which needs to be followed.
Important aspects like test estimation, test scope, test strategy are documented in Test Plan, so
it can be reviewed by Management Team and re-used for other projects.
How to write a Test Plan
You already know that making a Test Plan is the most important task of Test Management Process.
Follow the seven steps below to create a test plan as per IEEE 829
1. List all the software features (functionality, performance, GUI…) which may need to test.
2. Define the target or the goal of the test based on above features
Step 4) Define Test Criteria
Test Criteria is a standard or rule on which a test procedure or test judgment can be based. There’re 2
types of test criteria as following
Suspension Criteria
Specify the critical suspension criteria for a test. If the suspension criteria are met during testing, the
active test cycle will be suspended until the criteria are resolved.
280 man-hour
Total