Lesson video

Hello, my name is Mrs. Jones and I'm pleased you decided to join this lesson today.

In this lesson, we will look at the importance of testing and the different types and ways to check your code, as well as the types of errors that could occur.

So let's get started.

Welcome to today's lesson.

Today's lesson is called "Testing Principles" from the unit Python Programming Project, and by the end of this lesson you'll be able to explain different types of software testing.

There are three keywords to today's lesson.

White box.

White box is a method of testing where all possible routes through a programme are identified and tested.

Black box.

Black box is testing that does not rely on understanding the inner workings of a programme.

Debugging.

Debugging is the process of finding and correcting errors in programme code.

There are three sections to today's lesson.

The first is define different testing methodologies.

The second, create a test plan.

And the third, explain the importance of debugging.

So let's start with define different testing methodologies.

Jun says, "Why do we test programmes?" Good question.

Testing helps to find fix errors before users experience problems. It ensures the programme works as expected with different inputs.

Testing helps improve reliability and user experience.

Testing is carried out throughout the development process.

There are also specific stages and methods of testing that can be adopted.

An overall approach to testing should be agreed and planned depending on the requirements of the system.

Let's have a quick check.

Fill in the gaps to complete the sentences.

Blank is carried out throughout the development process.

There are also specific stages and blank of testing that can be adopted.

An overall approach to testing should be blank and planned depending on the requirements of the system.

Pause the video to consider which words fill those gaps in those sentences, and then we'll go through the answers.

Let's check your answers.

Testing is carried out throughout the development process.

There are also specific stages and methods of testing that can be adopted.

An overall approach to testing should be agreed and planned depending on the requirements of the system.

Well done if you got those correct.

Iterative testing, sometimes also referred to as a module or unit testing, is carried out at every stage of development.

The programmer writes an individual section of code or part of the project, and then tests it to ensure that it functions correctly.

It is likely that errors will be detected, and these are resolved before the next section of the programme is developed and tested.

So you can see in this example here, module one, tested all works fine.

Module two all works fine.

Module three all works fine.

Module four, there was an error.

It was modified, and now it works correctly before carrying on.

Integration testing is where individual modules or units that have already been separately tested are tested together to ensure that they are compatible and function as expected.

It may be that an individual module works as expected, but when you try to incorporate it into a wider system, errors occur.

Can see in the example here all of the connections with the arrows, and when testing occurs, it's testing those connections.

You can see the ticks here as each test is created and checked, and then any errors can be dealt with.

Final testing is carried out once the programme or system is considered to be completely finished and is the last phase of testing.

This stage happens after the individual sections or modules of the system have been tested to ensure that the system works as a whole and that it meets the requirements of the project.

During final testing each particular pathway or route through the programme is tested to ensure that the system works correctly in all scenarios and with a full range of input data.

White box testing requires the person who designs the test to look in detail at the code that has been written and understand how it works.

Using carefully designed test data, the tests will check whether a specified input produces the correct output.

Black box testing focuses on functionality.

Tests will check that the system does what it is supposed to do without checking how it has been coded.

The tests are designed with reference to the requirements specification.

Test data is entered through the user interface, and the output is viewed in the way in which it would be displayed or provided to the end user.

Let's have a quick check.

Which of the following best describes black box testing? Is it A, testing functionality without knowledge of the inner workings of the code.

B, testing by end users to ensure that the system meets the requirements and is functional.

C, testing by the programmers prior to showing the system to the end user.

Pause the video to consider your answer and then we'll check it.

Let's check your answer.

The answer was A, testing functionality without knowledge of the inner workings of the code.

Well done if you got that correct.

Let's do the activity.

Write a short definition of the following types of testing, iterative, integration, black box, and white box.

Pause the video, go back through the slides, use your worksheet, and complete the activity, and then we'll go through the answers.

Let's check your answers.

Iterative testing is when you test as you go along.

You make a small part of a programme, test it, fix any mistakes, and then move on to the next part.

It's a cycle of building, testing, and improving.

Integration testing checks whether different parts of a programme work well when combined.

White box testing requires the person who designs the test to look in detail at the code that has been written and understand how it works.

They design the tests based around the code.

Black box testing is focused on functionality.

The test will check that the system does what it is supposed to do without checking how it has been coded.

Well done if you got those correct.

Let's move on to the second part of today's lesson, create a test plan.

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

The test should include a range of test data.

You can see an example here of the headings that might go on a test table.

Test number, test description, input, if required, expected output, actual output, and if the test was unsuccessful, how was it fixed? There are three main types of test data that can be entered to test your programmes.

Erroneous, boundary, and normal.

Normal.

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

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

Erroneous.

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

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

Boundary.

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

You should check that value just on or within the boundary are valid and those slightly outside the boundary are invalid.

Let's have a quick check.

Match the test data type to the correct description.

You have normal, boundary, and erroneous on the left.

You need to decide which of those descriptions does it match up for.

Pause the video to consider your answer and then we'll check it.

Let's check your answer.

Normal.

Data should be accepted by the programme and is valid.

Boundary.

Values that are on the edge of being valued.

Erroneous.

Data should not be accepted by the programme because doing so would cause an error.

Well done if you got those correct.

A programme can be tested with different inputs to check for errors.

A test table helps track expected versus actual outcomes.

The following sample test table is from a programme that calculates entrance fees for a theme park.

You see test number one, the description is, "Test entrance fee is correctly calculated." The input is people are gonna be 3, days 2, cars 1, and payment 200.

The expected output is total 160 and the change 40.

The actual output is correct because its total 160, change 40, which means that the last column is a pass.

Test two has failed because the expected output did not match the actual output.

If you look here on test two, "A test user cannot enter a negative number of days." People 2, days -1, cars 1, and payment 50 are the inputs.

You expect an error message, but the actual output is "Thank you for your payment of 50 pound.

Your change is 90 pound." So the test is a fail.

We to add validation to the days variable input.

In order to develop an effective test plan, you need to consider the original functional requirements of the project.

In this project, the functional requirements are split into inputs, processes, and outputs.

The inputs where the user inputs the total duration of the stream in minutes, the user inputs the name of each game to be reviewed, and the user inputs the review duration for each game in seconds.

The processes validate that the total duration is between 20 and 40 minutes, store the total duration of the stream, convert the total duration to seconds, store the name of the game being reviewed and the duration, store the running total of games reviewed, validate that running total has not exceeded total duration, stop asking for more games once total review time is equal to the stream duration, randomly select time from the total stream time to display a discount code giveaway.

And the outputs display the total number of games reviewed, display the name and duration of each game reviewed, indicate the time that the discount code will be given away during the stream, and display the total planned stream duration in minutes and seconds.

Let's have a quick check.

What test could you add to the test plan for the first input requirements for the StreamScheduler project, and the first requirement there is, "User inputs the total duration of the stream in minutes." Note, you do not need to complete the final two columns of the table as these are completed after the tests have been carried out.

You will carry out these tests In the next lesson.

Pause the video to consider what would go in those first four columns for a test against that 1.

1 requirement, and then we'll go through the answer.

Let's check your answer.

Test number one, test whether the user can input the total duration of the stream in minutes.

An input could be 22.

Expected output input, accepted and stored.

Well done if you've got that correct.

Let's do the activity.

Create a test plan for the StreamScheduler project.

Pause the video, use your worksheet, go back through the slides, and create a test plan for your StreamScheduler project, and then we'll go through a possible solution.

Let's check your answers.

So this is a test plan example.

Your test plan should include more tests than this sample answer.

So you can see there we've got the test 1 we already looked at.

Test 2 tests that the user cannot enter a value less than 20 or more than 40 for the stream duration.

So the total duration equals 10.

Expected output an error, display message, "Please enter a stream between 20 and 40 minutes." Test 3, the total_duration is converted correctly to seconds.

total_duration equals 22.

The expected output, 22 multiplied by 60, so the total_duration equals 1,320.

Well done for completing your test plan.

Let's move to the last part of today's lesson.

Explain the importance of debugging.

Jun says, "What if some of my tests fail?" Sophia says, "A failed test may mean your programme has a bug." A bug is an error or mistaking code that stops it from working properly or as expected.

The process of finding and correcting bugs in code is called debugging.

Every programmer will need to correct errors and debug their code.

Here are the five steps for debugging.

One, review the task.

What should the project do? Two, test the project.

See what goes wrong.

Three, identify the bug.

Four, fix the bug.

And five, test the bug fix.

Does the code now do what it should? There'll be different types of bugs and errors you will come across when testing programmes.

These include syntax errors, logic errors, and runtime errors.

Syntax errors.

These are errors that occur when you have not followed the rules of the language and they will be flagged by the translator.

A programme with syntax errors will not run.

Most IDEs, integrated development environments, highlight syntax errors when you try to run your code.

Common causes of syntax errors include spelling or typing errors.

Missing parentheses like brackets.

Missing colons or semicolons in statements in which they are required by the language.

Missing or unexpected indentation.

Printing a value without declaring it.

Let's have a quick check.

Identify the syntax error in this code.

Is it A, a bracket is missing.

B, print should have a capital P.

Or C, the speech mark is missing.

Pause the video to consider your answer and then we'll check it.

Let's check your answer.

The answer was C, a speech mark is missing.

And you can see that it was flagged by a different colour to the end of the bracket.

Well done if you got that correct.

Logic errors.

These are errors that cause a programme to work incorrectly or unexpectedly.

With a logic error the programme can be run without failing, but it does not return the expected result.

Logic errors are typically more difficult to detect and find than syntax errors, as the IDE will not be able to pick up the issues or produce clear error messages.

Common causes of logic errors include not correctly understanding what the programme needed to do.

Using the incorrect logical operator in a selection statement.

Missing or incorrect positioning of in mathematical calculations, which means that the incorrect result is returned.

Loops that execute more or fewer times than intended.

Runtime errors.

These errors occur when the programme is run, as the name suggests.

They occur when the code is valid according to rules of syntax, and it's also logically correct, but the environment that the programme is being run in or the input provided causes an error to occur.

Let's have a quick check.

Match the type of error to the description.

You have syntax error, logic error, and runtime error on the left and you need decide which of those descriptions does it match across to.

Pause the video to consider your answers and then we'll check them.

Let's check your answers.

Syntax error.

Errors that occur when you have not followed the rules of the language.

Logic error.

Errors that cause a programme to work incorrectly or unexpectedly.

Runtime error.

Errors that occur in the environment that the programme is being run in or the input provided causes an error.

Well done if you've got those correct.

Let's do the activity.

Explain the importance of debugging a programme.

Pause the video, go back through the slides, use your worksheet, and then we'll go through the answers.

Let's check your answer.

When you are developing a computer programme it is easy to make mistakes.

These mistakes are called bugs.

Debugging is the process of finding and fixing these bugs.

Debugging is important because it makes your programme work correctly.

If there's a bug, your programme might not meet the functional requirements set out in the project brief.

It can improve the user experience.

If your programme doesn't work correctly, it can frustrate users and they may decide to stop using the programme.

It helps you learn.

By figuring out what went wrong, you understand your code better and can avoid making the same mistake again.

It improves your problem solving skills.

Debugging teaches you to think logically and pay attention to detail.

Well done if you got that correct.

In summary, software testing checks whether a programme works correctly, meets requirements, and is free from bugs or errors.

Integration testing checks whether different parts of the programme work together correctly.

White box testing tests with full knowledge of the code, often focusing on logic and structure.

Black box testing tests without knowing how the code works inside.

After testing, debugging can take place to remove and correct errors in a programme.

Well done for completing this lesson, "Testing Principles.".