Lesson video

Hello, I am Dr.

Das.

Welcome to Computing.

I'm so pleased that you have decided to join me for this lesson today.

In today's lesson, we will be covering a Programming project: Subroutines part II.

Welcome to today's lesson from the unit Programming: Subroutines.

This lesson is called Programming Project: Subroutines, part II.

By the end of today's lesson, you should be able to implement a program from a design and perform testing to ensure it works as expected.

Some of the keywords that we will be using in today's lesson include: erroneous.

Erroneous: data that should not be accepted by the program, or it will cause an error.

Boundary.

Boundary: data that should either be accepted or rejected by a program.

It tests the data right at the boundary of a range, Normal.

Normal: data that should be accepted by a program.

This is the data that you would expect a user to enter.

This lesson is divided into three sections: Implementing a solution, Use a range of test data, Test and refine a solution.

Let's start by exploring the first section where you will learn how to implement a solution.

Implementing a solution is about taking a plan, for example, a flow chart or structure chart and creating the program.

As you can see on the screen, on the left hand side is our flow chart for creating the Copington Adventure Park ticketing system.

So according to the flow chart, you start by printing a "Welcome to Copington Adventure Theme Park" message and then call the display_prices subroutine.

As you can see, the text output of this flow chart would look like the screen that has been displayed on the slide.

So it starts off by welcoming the user to Copington Adventure Theme Park, and then publishes a list of entrance prices, which is what the output of the display_prices subroutine will be.

When implementing a problem with multiple subroutines, it is sensible to solve one problem or one section at a time.

Carefully consider where a sensible place to start is.

Which parts of the system do not rely on other parts being completed? This slide here shows the Copington Adventure Theme Park ticket booking system structure chart.

As you can see, it is divided into various subroutines.

The display ticket prices subroutine, calculate entrance price subroutine, car parking subroutine, collect payment and issue ticket subroutine.

Each of these subroutines has been split further into their identifier, parameters, and return values.

So as you can see, the display ticket prices subroutine has the identifier display_prices.

It doesn't take any parameters, it doesn't return any return values.

On the other hand, the calculate entrance price subroutine has the identifier calculate_entrance.

It takes parameters, booking name, adult total, child total, senior total, wristband total, and returns the total cost of all the tickets.

The car parking subroutine has the identifier parking.

It doesn't take any parameters but returns a value parking_required.

The collect payment subroutine has the identifier collect.

It takes a parameter total_cost, but does not have a return value.

Finally, the issue ticket sub-routine has the identifier issue_ticket.

Its parameters are booking name, the total number of adults, the total number of children, the total number of seniors, and the total number of wristbands, followed by the total cost and parking required.

It does not have a return value.

So looking at all these subroutines, Sam says, "I am going to start with the display ticket prices subroutine as it is the first thing the program needs to do." Furthermore, doesn't take any parameters.

It doesn't have any return value, so that is the best place to start.

Right, before we move on, let's do a quick check by trying out this true or false statement.

Implementing a solution comes before design.

What do you think? Is the statement true or false? Pause the video here and have a quick think.

Did you choose option false? You were right.

It is important to fully understand the requirements of a project and design a solution before you can start implementing it.

Well done.

Now, when implementing a solution from a flow chart, remember the flow chart symbols can guide you.

So the table here shows the different flow chart symbols.

You generally start off with the oblong start process.

So this oblong shape represents the start or end of a process.

The rectangle represents an operation or a set of operations.

For example, a calculation like x = x + 1 will go in a rectangle.

The parallelogram represents input or output.

So data is input by the user or printed out on the screen.

The rhombus represents a decision.

In programming, this is implemented with if statements.

Right, another quick check.

What does this symbol represent in a flow chart? The symbol is given on the right hand side of the slide.

What do you think? You've been given three options.

Pause the video here and have a quick think.

I'm sure you know the answer to this one.

That's right.

Option C, subroutine is the correct answer.

Well done.

This brings us to the end of this section.

Before we move on, why don't you attempt this task, just to make sure that you understood what we covered in this section? Task A is made up of two parts.

The first part asks you to use your design elements, your flow chart and structure charts, to implement your solution for the theme park booking system.

Remember, if you do not have a plan, you can always use the structure chart that has been provided.

The second part asks you to use the project brief to ensure your solution meets the requirements.

So the table here lists all the requirements that need to be met.

Your program needs to provide a welcome message, then display the entrance ticket prices, then ask how many adult tickets are required, ask how many child tickets are required, ask how many senior tickets are required, and ask how many wristbands are required.

Then it should ask for the lead booker's name for the ticket.

Then it should ask if they require a parking pass for the car park.

It displays the total cost after this, asks for payment, prints a message that says the machine only accepts 10 pound and 20 pound notes, and each note entered will need to be counted.

Display change, if any.

Print a ticket displaying the lead booker's surname, tickets purchased, wristbands purchased, today's date.

Then print a car parking pass if requested.

Use data validation techniques to avoid runtime errors through incorrect data entry, and finally, thank the customer for their purchase.

Now having all the requirements in this table format is quite helpful.

So as you kind of work through your solution, you can tick these off, just to know that you have completed the different steps.

Right, why don't you pause the video here? Look through the slides, the previous slides if you need to, but then attempt this task.

I'm sure you'll be able to work through the task.

Well done on attempting that task.

Let's move on.

In this section, you will be looking at how to use a range of test data.

Iterative testing is where you test that your program works throughout its creation.

By running your code and testing often, you will find that errors are much easier to detect and correct.

Final testing happens once the program is completed.

During iterative testing, you might test individual blocks of code or subroutines.

Final testing happens when all those elements have been put together into one program.

Okay, let's do a quick check.

Is this statement true or false? Iterative testing happens once the program is completed.

Why don't you pause the video here and have a quick think? The right answer is the option False.

Iterative testing is when you test that your program works throughout its creation.

Well done.

When final testing, there are three main types of data that can be entered to test your programs: erroneous, boundary and normal.

Let's look at what each of these mean.

Erroneous type of data should not be accepted by the program because doing so would cause an error.

For example, a string is entered where an integer is required.

The program should not accept this data at all.

Boundary: These are values that are at the limits of validity.

They should check that values at the boundary are valid.

They should also check that values just outside the boundary are not accepted and handled where required.

For example, this while loop should execute when the values 1, 2, or 3 are entered.

The boundary data at the edge of the range should be accepted.

In this case, you would enter a 1 and a 3 to check this.

So if you look at the program, the program the while loop is testing whether the number is greater than 0 and the number is less than 4.

So as long as that condition is true, the while loop prompts, you print that you're in the range and the number variable gets the input stored in it.

So the boundary values in this case would be 1 and 3, which are just inside the 0 and 4.

You would then also test that values just outside of the range are not accepted.

In this case, the values would be 0 and 4.

Clearly they are outside the condition, outside the test range, because the while loop is testing for any number that is greater than 0 and less than 4.

Finally, normal.

This type of data should be accepted by the program and is valid.

It is the normal data that you would expect to be entered into your program.

Okay, time for another check.

Which of the following would be boundary test data for the program below? So the program is shown on the right hand side of the slide.

You've got three options.

Pause the video here and have a think.

Okay, did you go for option C: 9? That is the right answer.

9 would be a boundary test value because the while loop is testing for numbers that are greater than 0 and less than 10.

So 9 would be a boundary value as it is close to 10, but inside the boundary.

Well done.

This brings us to the end of this section.

As we have done before, just to make sure that you have understood what we covered in this section, why don't you attempt this task? Task B has two parts.

Part one asks you to explain the difference between erroneous, boundary and normal test data.

Part two asks you to explain why it is important to use a range of test data when testing a program.

Pause the video here, have a think, look through the previous slides if you need to.

I'm sure you'll be able to work these two parts out.

Okay, let's look at the solutions for the two parts.

The first part, which asks you to explain the difference between erroneous, boundary and normal test data.

Erroneous test data is data that should not be accepted by your program.

Boundary data are values that are at the limits of validity.

Normal data is data that is valid and should be accepted by the program.

The second part, which asks you to explain why it is important to use a range of test data when testing a program.

Using a range of test data means that you have tested all possible values that may be entered into a program.

It is just as important that a program does not accept erroneous data as it is that it accepts normal, valid data.

Well done on attempting this task.

Let's move on to the next section.

In this final section, you will be looking at how to test and refine a solution.

Jacob says, "What parts of the theme park ticket booking system could I test?" Jun says, "You could test the ticket number entry to make sure it only accepts an integer?" That's a good idea.

A test table is a way to thoroughly check that a program is working correctly.

The tests should indicate data from all three types: erroneous, boundary and normal.

So given here on the slide is an example of a test table and you can see the different columns.

So test number, test description, input, if there is an input, expected output, actual output, and if the test was unsuccessful, how is it fixed? So these are the different columns that form part of a test table, and for each data type, each data that you test, you make an entry.

Okay, a quick check before we move on.

Fill in the gap to complete the sentence.

What is a way to thoroughly check that a program is working correctly? Pause the video here.

Have a quick think.

I am sure you'll be able to work this one out.

That's right, a test table is a way to thoroughly check that a program is working correctly.

Well done.

Here is an example of a test table which has been used to test the while loop from earlier in the lesson.

You remember we looked at this while loop a few slides ago? So the test table has these different tests that can be run to test that the program is working correctly.

So as you can see in the table, there are four different tests or four different types of data that were tested.

Two boundary tests for the while loop with two different data.

So 1 and 0, the normal test for input with the number 2 and an erroneous test for the input with a string value, Hello.

And you jot down the expected output for each of these tests.

So for when the input is 1, where it's a boundary test for the while loop on the lower end of the boundary, the expected output is "You are in the range." When the boundary test for the while loop is done using the input 0, which means it's outside the boundary, the expected output, well, not applicable.

The third test, which is run for a normal test for input with the number 2, the expected output is "You are in the range." Finally, an erroneous test for the input with the string Hello should give you the expected output is you should enter a whole number.

So then what do you get when you run the program with each of these input values, each of these tests? As you can see, we are going to do this step by step.

So we are going to look at each of the test data.

So the first one where it is the boundary test for the while loop with input 1, the expected output was "You are in the range." The actual output is also, "You are in the range." But the test wasn't unsuccessful, so nothing needs to be fixed.

For the next test where the boundary test was done, using the input 0, expected output was not applicable.

The actual output, there is no output.

For test number three, where it is a normal test for input with a number 2, expected output is, "You are in the range" actual output.

As you can see, the text output is "You are in the range." Again, it wasn't unsuccessful.

So there is nothing that needs to be fixed.

Finally, for the erroneous test for input with the value Hello, a string value.

The expected output was you should enter a whole number, but the actual output was a ValueError because as you can see in the program, it just hasn't been handled yet.

A string entry hasn't been handled yet, which means in the column where it says if the test was unsuccessful, how can it be fixed? You can say "added a function to handle the ValueError." Okay, let's do a quick check.

A test table should test.

You've been given three options.

Why don't you pause the video here and have a think? The correct option is option C, a combination of erroneous, boundary and normal data.

I am sure you were able to work this one out.

This brings us to the end of this section.

Why don't you attempt this task just to make sure you have understood what we covered in this section.

Task C is split into three parts.

The first part asks you to use the test table template provided to plan a range of tests for your theme park ticket booking program.

Remember to include a mixture of erroneous, boundary and normal test data in your plan.

The second part asks you to carry out the tests in your test table and record the results.

Finally, the third part asks you to make any necessary changes to your program.

Pause the video here, look through the previous slides if you need to and have a go at completing this task.

I'm sure you'll be able to do this.

So a possible test table for the ticket booking system program could look like this.

So the first test could be an erroneous test for input of number of tickets.

The input, a string value 4, expected output should be, you should enter a whole number and then give an example, like example, 3.

But the actual output when program run was a ValueError, which means something needed to be done to fix it and you could have added a function to handle the ValueError.

The second test could be a test with normal test data.

So normal test for input of parking ticket, the input could be y, lowercase y.

Expected output, the value returned, so your ticket_required value returned is True, For the actual output, the ticket_required value was returned as False.

There was a problem.

It did not like the user entering Y as a lowercase y.

So a possible fix could be altered, the condition, to accept both uppercase and lowercase Ys.

The third test, a boundary test for input of number of tickets, and the test input is 0.

The expected output, well, not applicable.

The actual output, there wasn't any output because the number entered was 0.

The test wasn't unsuccessful, everything was fine.

So no fixes needed.

Now this is just an example of test conditions showing you the three different types of data that you could have entered to test your program.

I'm sure you were able to test your program with more test conditions.

So well done on attempting this task.

To summarize, the implementation of a solution is where you take a plan and create a solution.

A program should be tested with a range of data.

Erroneous data is data that should not be accepted by the program or it'll cause an error.

Boundary data is data that should either be accepted or rejected by a program.

It tests the data right at the boundary of a range.

Normal data is data, which should be accepted by a program.

This is the data that you would expect a user to enter.