Lesson video

Hello, my name is Mr. Hogan.

I'm excited to be learning with you today.

We are going to have such a great time learning about programming iteration.

I will be supporting you with our learning during these lessons.

I'm so pleased that you've decided to learn about the programming project for iteration.

This is part two.

We are going to do brilliantly.

I can't wait to teach you this lesson.

It's going to be amazing.

The outcome will be that I can develop a programme and apply testing techniques to ensure that it works correctly.

So we're gonna develop a programme and test it.

It's gonna be great.

We've got two keywords in this lesson.

So we've got test plan.

So this is a document that sets out the test that will be carried out during testing.

And then we've got test data.

This is the input values used to check whether a programme works correctly during testing and to see how it behaves in different situations.

You may want to come back and rewind the video to this part so you can review where we do use these keywords in the lesson.

This lesson is split into two parts.

With the first part is build a programme that meets requirements.

And the second part is to test a programme using a test plan.

So I can't wait to teach you these parts of the lesson.

So let's start with the first part, which is build a programme that meets requirements.

When approaching a problem that will be solved using code, it is useful to follow the software development lifecycle.

So we have here, we start with planning, go to analysis, design, development, testing, and then implementation.

And we're at the design part of this software development lifecycle.

In real-life software development, design and implementation are often done by different people or teams. A design team plans how a programme will work.

They break the problem down, decomposition, create flowcharts and clearly outline each step.

Then this plan is handed over to a developer or a development team to turn into working code.

The design team has been asked to develop a game using Python.

FizzBuzz Challenge Station is a new game terminal being trialled at Hill Top Holiday Park.

The system must prompt the player for the number of games they would like to play.

For each game, the player sets a range of numbers, for example, from 1 to 20.

The system then plays the game automatically using the FizzBuzz rules and displays the results.

The design team has created a project brief, decomposed the project, and provided a flowchart and the rules of FizzBuzz for you.

So the project brief includes these system requirements.

Display a welcome message.

Ask how many games the player wants to play.

For each game: ask for the start and end of the number range; validate the input, numbers only and sensible range; play FizzBuzz using a for loop.

After each game, ask if the player wants to continue.

Display a goodbye message.

So this is what we are going to use this lesson.

So you may want to pause the video at any time or even rewind it to see what's been in previous slides.

So the design team has decomposed the project brief for you.

And so we can see we've got different parts.

So display a welcome message.

The system will need to display a welcome message to the user.

Ask how many games.

So ask the user how many times they want to play.

Ensure they enter a valid whole number.

Ask for a start and end number.

Get the range for the FizzBuzz loop.

Validate inputs and check that start is less than end.

The next part is go through the range.

Use a for loop to go from start to end print number "Fizz", "Buzz", "FizzBuzz".

And then finally handle errors.

Use try and except blocks to catch errors.

When developing a programme from a flowchart, remember that the flowchart symbols you can use.

So the flowchart symbols are the terminal symbol represents the start or the end of a programme.

And we then we've got the process symbol, which represents any action such as calculations or steps where data is manipulated, so a calculation.

We've got the input and output symbol, which represents any action that involves user input or output.

Then we've got the decision symbol in a flowchart, which represents a condition.

So, for example, when using selection or a loop.

Let's have a quick check.

What does this symbol represent in a flowchart? Is it, A, input or output? B, decision? Or C, process? Remember you can pause the video at any time or rewind it.

Let's have a look at the answer.

It is C.

Yes, it's a process symbol.

Well done if you got that right.

So this design team has also created a flowchart for us.

So we've got start.

Display the welcome message to the user.

Input number of games.

Is the input valid? If it's not loop, back and go to input number of games.

If it is valid, move on.

So let's look at the next part of the flowchart.

Then it's got ask for a start number.

And, again, it's asking, is the input valid? If it's not, it will loop back to the ask for a start number.

If it is valid, we move on.

This is very similar, but it's asking for a finish number.

And if it's not valid in the decision box, it will loop back to ask for a finish number.

If it is valid, it will move on.

And then it's asking in the decision box, the condition of is end number less than start number.

If it is, stop.

If it isn't, calculate the result, display the result, and add 1 number to the start number variable and loop back to decision box.

You may want to pause the video or rewind the video at any point just to refresh your memory when we come to develop the programme.

So we also know need to know the FizzBuzz rules.

So these are the rules.

Print "Fizz" if the number is divisible by 3.

Print "Buzz" if the number is divisible by 5.

Print "FizzBuzz" if the number is divisible by both.

Otherwise, print the number.

So development is the next stage after design in the software development lifecycle.

So we've got all the materials, all the resources, we now have to move on to the development part of the development lifecycle.

Let's have a quick check.

What is the first piece of information the FizzBuzz challenge station system needs from the player? Is it A, the range of numbers for the game? B, the FizzBuzz rules? Or C, the number of games they would like to play? You can rewind or pause the video anytime to see if that will help you answer the question.

The answer is C, the number of games they would like to play.

So let's have a practise.

One, develop your FizzBuzz Challenge Station for Hill Top Holiday Park using the project brief, the project decomposition, the flowchart, and the rules of FizzBuzz, which is provided for you.

The plan and flowchart are also provided in the additional materials.

So you may want to look in additional materials or pause and rewind this video and play parts again as you develop your FizzBuzz Challenge Station for Hill Top Holiday Park.

So take your time, pause the video, and good luck.

Excellent, hopefully you have completed the FizzBuzz Challenge Station programme.

That's brilliant.

That's really, really good.

And I'm so looking forward now to moving on to the next part of the lesson, which is test the programme using a test plan.

So we're hopefully gonna test your programme that you've developed.

Testing is the next stage after development in the software development lifecycle.

Jacob is saying, "When I enter 1 for start and 15 for end, I expect the last number in the loop to be 15.

The loop stops at 14 and does not include 'FizzBuzz' for 15.

There must be an error." I wonder what Jacob's thoughts are.

Iteration is a key part of this programme because it repeats code for each number in the range function.

If the range is wrong, your whole test could fail or miss a value.

range() does not include the end value.

It uses the end value as a stop value.

So Jacob has realised, "I should use range(start, end + 1) to include the last number." That's correct.

You can see in the code on line 1 that's where he needs to put it.

So he's put it in now, Jacob has, and he's saying, "Great, it now works!" A test plan is a document that sets out the test that will be carried out during testing.

Tests should be planned carefully, using data that might cause errors as well as data that proves the system works as it should be.

A test plan will usually specify the following: a unique identifier for each test, so that it can be referred to during testing; a description of each test; the test data that is to be used for each test; and a description of the expected results of each test.

These are normally put in a table as headers of the first row.

Let's have a check.

It's a true and false one.

When creating a test plan, you should only use data that you expect the programme to handle correctly.

Is this true or false? Remember, you can pause or rewind the video at any time.

Let's have a look at the answer.

It is false.

Why is it false? Well, the effective test plans include data that is likely to cause errors to ensure the programme is robust.

In final testing, there are three main types of data that can be entered to your programmes, erroneous, boundary, and normal.

Erroneous.

So an erroneous test, this type of data should not be accepted by the programme because doing so would cause an error.

So, for example, a string is entered when an integer is required.

This is a test using erroneous data.

Boundary tests use boundary data.

These are values that are on the edge of being valid.

You should check that values at the boundary are valid using these tests.

Normal tests and normal data.

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.

Let's have a check.

If a programme asks the user to enter the age as an integer, which of the following inputs would likely cause an error? So you can see some code there.

Okay, so will it be, A, 15? B, fifteen spelled out in characters? C, 150? So have a think about it and you can rewind the programme or pause it at any time.

So let's have a look at the answer.

It is B fifteen because it is not a number.

It is spelt out using characters.

Well done if you got that correct.

Time for the practise, So one, open the FizzBuzz Challenge Station programme for Hill Top Holiday Park that you have created previously.

If you don't have a previous version, you can access the version at oak.

link/fizz-buzz.

So after you've done that, we can move on.

And two, carry out these tests and record the actual results.

So follow this test table and input a different test data into the programme, and then complete the actual results for each test.

So test one is normal input, so valid number in the ranges and the expected result there should be the programme runs two games and outputs FizzBuzz results for numbers 1 to 5 each time.

Test two, T2, is erroneous input.

So we're gonna input a non-integer value for plays.

So we're gonna actually type in "three" using characters.

And then the expected result would be an error message, something like, "Error: Please enter a whole number." T3, test three, is a boundary test.

So we are going to enter 5 for the start and 5 for the end.

Hopefully the expected result will be "Start number must be less than end number.

Enter the start number." Okay, let's see if we can do this.

You can take your time.

You may want to pause the video or rewind the video at any time.

Excellent.

So the actual results are for test one, the correct output shown for each game.

So that that was fine.

Test two, yes, the programme shows an error message and prompts the user again.

And test three, the programme shows error message and prompts the user again.

Brilliant, well done on completing your first tests.

Really good.

Okay, so we move on.

Now three, create three new tests and add them to this table.

You may find these test scenarios helpful for you.

So what happens if the user enters 0 or a negative number for the number of plays? What happens if the start number is higher than the end number? Can you test a range that includes a large number of values, such as 1 to 100? So add to the previous test table.

You can think about these scenarios and think about how you can put them into the test table and test your programme.

You can just pause or rewind the video at any time.

Well done.

So let's have a look at a sample answer.

Obviously yours can vary slightly depending on what programme you're using.

So test four, so we're thinking about a normal test, a valid standard input and standard range.

So plays 1, start 1, and end 15 would be the test data.

The expected result is game runs once and print correct FizzBuzz values from 1 to 15, and the actual result was correct.

FizzBuzz output shown for numbers 1 to 14.

Excellent.

So there's a slight difference there.

However, it is correct in playing 1 to 14 because 15 is used as a stock value in our programme.

T5, test five, it's the erroneous test.

So user enters text instead of a number.

So we've got the test data being "two" spelled out there.

Programme shows error "Error: Please enter a whole number," and prompts again as the expected result.

And the actual result, so what actually happened is that the programme shows an error message and prompts the user again.

And then in test six, T6, this could be a boundary test.

Start number is equal to end number.

So we've got plays equals 1, start equals 5, and end equals 5.

The expected result is error message shown: "Start number must be less than end number.

Enter the start number." And then we've got programme shows error message and prompts the user again as the actual result.

So well done if you've got these or very similar tests for your programme.

That's brilliant, you've actually now done three full tests and done your own descriptions, test data, expected results and actual results.

Brilliant, well done.

Now four, if any of your tests failed, now it's time to refine your programme to ensure it works correctly.

So go back and refine and amend your programme so it's absolutely perfect.

Excellent, brilliant.

We've come to the end of the lesson.

So in summary, a complete programme meets all the requirements set out in the brief and works as intended.

And a test plan helps ensure that the programme behaves correctly.

Test data is used to check different inputs and scenarios.

Amazing, well done.

Really, really pleased that you've made it to the end of this lesson.

It's been amazing to teach you.

Well done.