Lesson video

Hello, my name is Mrs. Holborow, and welcome to Computing.

I'm so pleased you decided to join me for the lesson today.

In this lesson, we are going to be implementing and testing a solution for a programming project that requires the use of subprograms. Welcome to today's lesson from the unit Programming Subprograms. This lesson is called Programming Project: Subprograms Two, and by the end of today's lesson, you'll be able to implement a programme from a design, and perform testing to ensure it works as expected.

Shall we make a start? We will be exploring these key words in today's lesson.

Erroneous.

Erroneous.

Data that should not be accepted by the programme or it will cause an error.

Boundary.

Boundary.

Boundary test data is data of the correct type, which is on the very edge of being valid.

Normal.

Normal.

data that should be accepted by a programme.

This is data you would expect a user to enter.

Look out for these keywords in today's lesson.

Today's lesson is split into three sections.

We'll start by implementing a solution.

We'll then use a range of test data, and then finally we'll test and refine a solution.

Let's make a start with implementing a solution.

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

So you can see on the left hand side I have a flow chart, which represents a theme park ticket booking system.

I have a print welcome message, and then I call a subprogram, which is called display_prices.

On the right-hand side, I have a sample output from the programme, so I have the welcome message printed, and then my subprogram is displaying the ticket prices for adult, child, senior citizen, and wristband prices to the user.

When implementing a problem with multiple subprograms, 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? Here we have a structure chart for the theme park booking system.

So we've broken the problem down into sub programmes, display ticket prices, calculate entrance prices, car parking, collect payment, and issue ticket.

The interface for each of the subprograms has been planned, so we have the identifier, the name of the subprogram, any parameters that are going to need to be passed to the subprogram, and then any return values that the subprogram will return back to the main programme.

Which subprogram do you think would be best to tackle first? Maybe pause the video here whilst you have a think.

Sam says, "I'm going to start with the display ticket prices subprogram, as it's the first thing the programme needs to do." That seems like a logical thing to do, and this subprogram doesn't require any of the other subprograms to work.

Time to check your understanding.

True or false? Implementing a solution comes before design? Pause the video whilst you have a think.

That's right, it's false.

Why is it false? It's important to fully understand the requirements of a project, and design a solution before you start implementing.

When implementing a solution from a flow chart, remember the flow chart symbols can guide you, so the lozenge shape represents the start or end of a process.

The rectangle represents an operation or set of operations, for example, a calculation.

The parallelogram represents input or output, so this is where data may be input by the user or outputted via a print message.

The diamond is used for decisions.

In programming, this is implemented with if statements.

Time to check your understanding.

What does this symbol represent in a flow chart? Is it A, a decision, B, input or output, or C, a subprogram? Pause the video whilst you have a think.

Did you select C? Well done.

The rectangle with the additional lines is used to represent a subprogram in a flow chart.

Okay, we are moving on to our first task of today's lesson.

Use your design elements, flow chart, and structure charts to implement your solution for the theme park booking system.

Note, if you do not have a plan, you can use the structure chart provided in this slide deck.

For part two, use the project brief to ensure your solution meets the requirements.

Here's a reminder of the requirements.

Provide a welcome message.

Display the entrance ticket prices.

Ask how many adult tickets are required.

Ask how many child tickets are required.

Ask how many senior citizen tickets are required.

Ask how many wristbands are required.

Ask for the lead booker surname.

Ask if they require a parking pass for the car park.

Display the total cost.

Ask for payment.

Remember, the machine only accepts 10 and 20 pound notes.

Each note entered will need to be counted.

Display change if there is any.

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

Print a car parking pass if required.

Use data validation techniques to avoid runtime errors through incorrect data entry.

Thank the customer for their purchase.

Pause the video whilst you complete the activity.

Okay, we are moving on to the second part of today's lesson, and you're doing a fantastic job, so well done.

We are now going to use a range of test data.

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

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

Final testing happens once a programme is completed.

During iterative testing, you might test individual blocks of code or subprograms. Final testing happens when all of those elements have been put together into one programme.

Time to check your understanding.

True or false, iterative testing happens once the programme is completed? Pause the video whilst you have a think.

That's right, it's false.

Iterative testing is when you test that your programme works throughout its creation, not just at the end.

When final testing, there are three main types of data that can be entered to test your programmes.

Erroneous, boundary, and normal.

Erroneous.

This type of data should not be accepted by the programme, because doing so would cause an error.

For example, if a string is entered when an integer is required.

Boundary.

These are values that are on the edge of being valid, they should check that values on the boundary are valid.

Let's have a look at an example boundary test.

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.

Normal.

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

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

Time to check your understanding.

Which of the following would be boundary test data for the programme below? A, 11, B, 5, or C, 9? Pause the video whilst you have a think, and look carefully at the code.

Did you select nine? Well done.

This while loop accepts a number greater than 0 and less than 10, so nine is on the edge of the boundary for this test data.

Okay, we are moving on to our second tasks of today's lesson.

You are doing a fantastic job so far, so well done.

For part one, explain the difference between erroneous, boundary, and normal test data.

For part two, explain why it is important to use a range of test data when testing a programme.

Pause the video whilst you answer the questions.

How did you get on? Let's have a look at some sample answers together.

For part one, you were asked to explain the difference between erroneous, boundary, and normal test data.

Erroneous data is data that should not be accepted by a programme.

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

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

For part two, you were asked to explain why it is important to use a range of test data when testing a programme.

Using a range of test data means that you've tested all possible values that may be entered into a programme.

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

Okay, we are moving on to the final part of today's lesson, and you've done a great job to get this far, so well done.

We are now going to test and refine a solution.

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

Well done.

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

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

So here's an example test table template.

We have the test number, test description, the input, if required, that will be used for the test, the expected output, the actual output, and then if the test was unsuccessful, how was it fixed? Fill in the gap to complete the sentence.

A is a way to thoroughly check that a programme is working correctly.

Pause the video whilst you have a think.

Did you select test table? Well done.

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

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

So we have four tests.

The first test is a boundary test for the while loop, and we're gonna input 1.

The expected output should be "you are in the range." Test two is an erroneous test for the while loop.

This time we're going to use 0, and the expected output is nothing, because the while loop shouldn't run.

Test three is normal test data for the input.

So 2 is the value we're going to use here.

Expected output is "you are the range" again.

And then test four is an erroneous test for input.

So this time we're gonna input the word "hello." Expected output should be, "you should enter a whole number." Let's go through and execute the code and fill in the test table.

So first time the program's run, we are going to enter 1 and our expected output was "you are in the range," and our actual output is "you are in the range." So the test is successful, and we don't need to do any amendments.

This time we're gonna run the code again, and we are going to type in 0.

The expected output was to be nothing, and our actual output was that we had nothing.

So again, we don't need to make any corrections.

Third time, this time we're gonna type in 2.

Our expected output was "you are in the range," and our actual output was "you are in the range." So again, we don't need to make any amendments to the programme.

This time our final test.

This time, we typed in the word "hello." We expected the output of "you should enter a whole number," but actually our actual output is a value error.

So we're going to need to do a fix here.

And the fix is to add a function to handle the value error.

So you can see here the test plan has helped to identify an error in my programme, or where the programme doesn't quite run as we expect it to.

Time to check your understanding.

A test table should test A, only normal data, B, only erroneous data, or C, a combination of erroneous, boundary, and normal data? Pause the video whilst you have a think.

Did you select C? Well done.

A test table should test a combination of erroneous, boundary, and normal data.

Okay, we're moving on to our final set of tasks for today's lesson, and you've done a fantastic job, so well done.

Use the test table template provided below to plan a range of tests for your theme park ticket booking programme.

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

Then carry out the tests in your test table and record the results.

If any of your tests were unsuccessful, make any necessary changes to your programme.

Pause the video here whilst you complete the task.

How did you get on? Did you manage to test and refine your solution? Let's have a look at some sample test data.

So in this test number one, we use some erroneous test data.

So instead of typing in the number 4, we actually type in the text "four." The expected output is, "You should enter a whole number, e.

g.

3." The actual output was a value error.

So to fix this, we add a function to handle the value error.

Test two, we used normal test data.

So for the parking ticket, we use the input Y for yes.

The expected output is that ticket_required holds the value of true.

However, the actual output was ticket_required was equal to false.

This is because the condition was only looking for an uppercase Y, so we altered the condition to accept both lowercase and uppercase Y.

The final test, we used boundary test data and we entered 0 for the number of tickets.

The expected output was nothing, and the actual output was nothing.

So we didn't have to fix anything for this test.

Remember, your test table will look very different to this, but this is just an example to show you how you may have recorded the information.

Okay, we've come to the end of today's lesson and you've done a fantastic job, so well done.

Let's summarise what we've learned together.

The implementation of a solution is where you take a plan and you create the solution.

A programme should be tested with a range of test data.

Erroneous data is data that should not be accepted by the programme, and it will cause an error.

Boundary data is data of the correct type, which is on the very edge of being valid.

Normal data is data that should be accepted by a programme.

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

I hope you've enjoyed today's lesson, and I hope you'll join me again soon.

Bye.