WEBVTT

1
00:00:00.000 --> 00:00:02.040
In this lesson we will learn

2
00:00:02.040 --> 00:00:06.660
about continuous integration, continuous deployment testing.

3
00:00:06.660 --> 00:00:09.400
Continuous integration, continuous deployment,

4
00:00:09.400 --> 00:00:14.400
or CI/CD testing systematically evaluates code changes

5
00:00:14.790 --> 00:00:18.131
to identify and address security vulnerabilities,

6
00:00:18.131 --> 00:00:21.472
and functional issues before the code is deployed

7
00:00:21.472 --> 00:00:23.220
to production.

8
00:00:23.220 --> 00:00:27.195
CI/CD testing concepts include canary testing,

9
00:00:27.195 --> 00:00:32.195
regression testing, automated test and retest, unit testing,

10
00:00:32.264 --> 00:00:34.950
and integration testing.

11
00:00:34.950 --> 00:00:38.820
Let's learn more about canary testing, regression testing,

12
00:00:38.820 --> 00:00:41.760
automated test and retest, unit testing,

13
00:00:41.760 --> 00:00:44.130
and integration testing.

14
00:00:44.130 --> 00:00:47.040
First, we have canary testing.

15
00:00:47.040 --> 00:00:49.530
Canary testing is a phased approach

16
00:00:49.530 --> 00:00:52.860
to deploying changes named after the practice

17
00:00:52.860 --> 00:00:54.904
of using canaries in coal mines

18
00:00:54.904 --> 00:00:57.630
to detect hazardous conditions.

19
00:00:57.630 --> 00:01:02.035
Just as miners would bring canaries in cages into a mine

20
00:01:02.035 --> 00:01:06.780
to warn them of dangerous gases before humans were affected,

21
00:01:06.780 --> 00:01:10.350
canary testing involves rolling out a new feature

22
00:01:10.350 --> 00:01:13.325
or code update to a small group of users

23
00:01:13.325 --> 00:01:17.490
before releasing it to the entire user base.

24
00:01:17.490 --> 00:01:21.392
The goal of canary testing is to monitor the performance,

25
00:01:21.392 --> 00:01:25.533
and behavior of a system under real world conditions

26
00:01:25.533 --> 00:01:27.750
with a limited audience.

27
00:01:27.750 --> 00:01:31.500
In this way, canary testing allows organizations

28
00:01:31.500 --> 00:01:35.550
to detect issues such as security vulnerabilities,

29
00:01:35.550 --> 00:01:37.530
memory leaks, or crashes

30
00:01:37.530 --> 00:01:40.500
within a controlled small scale deployment

31
00:01:40.500 --> 00:01:42.540
before a full rollout.

32
00:01:42.540 --> 00:01:45.720
If problems arise during canary testing,

33
00:01:45.720 --> 00:01:48.720
developers can roll back those changes

34
00:01:48.720 --> 00:01:51.960
without affecting the entire user base.

35
00:01:51.960 --> 00:01:56.960
So canary testing offers an extra layer of quality control.

36
00:01:57.210 --> 00:02:00.300
Second, we have regression testing.

37
00:02:00.300 --> 00:02:03.464
Regression testing ensures that new code changes

38
00:02:03.464 --> 00:02:07.950
do not negatively impact existing functionality.

39
00:02:07.950 --> 00:02:12.060
Regression testing involves rerunning previously successful

40
00:02:12.060 --> 00:02:16.474
test cases to verify that everything still works as intended

41
00:02:16.474 --> 00:02:19.500
after a change has been integrated.

42
00:02:19.500 --> 00:02:22.620
For instance, if new code is introduced

43
00:02:22.620 --> 00:02:26.250
to enhance user authentication, regression testing,

44
00:02:26.250 --> 00:02:28.650
will ensure that previous features

45
00:02:28.650 --> 00:02:31.110
such as user profile management

46
00:02:31.110 --> 00:02:34.830
or password recovery, remain unaffected.

47
00:02:34.830 --> 00:02:39.000
In continuous integration continuous deployment pipelines,

48
00:02:39.000 --> 00:02:41.670
regression tests are typically executed

49
00:02:41.670 --> 00:02:45.930
after a new code is merged into the main branch of code

50
00:02:45.930 --> 00:02:47.880
to maintain stability.

51
00:02:47.880 --> 00:02:51.930
Due to its repetitive nature, automated regression testing

52
00:02:51.930 --> 00:02:55.410
is often utilized, bringing developers to focus

53
00:02:55.410 --> 00:02:59.040
on writing new tests, or resolving issues.

54
00:02:59.040 --> 00:03:03.210
Third, we have automated testing and retesting.

55
00:03:03.210 --> 00:03:05.760
Automated testing is where testing scripts

56
00:03:05.760 --> 00:03:10.320
are run automatically every time new code is integrated.

57
00:03:10.320 --> 00:03:13.890
This automation ensures that bugs are caught early

58
00:03:13.890 --> 00:03:16.020
in the development process.

59
00:03:16.020 --> 00:03:18.583
In the context of automated retesting,

60
00:03:18.583 --> 00:03:21.690
if a bug has been detected and fixed,

61
00:03:21.690 --> 00:03:25.482
tests are rerun to confirm the issue is resolved,

62
00:03:25.482 --> 00:03:28.898
and that no new issues have been introduced.

63
00:03:28.898 --> 00:03:33.270
Automated tests and retests can cover a wide range

64
00:03:33.270 --> 00:03:36.464
of testing types, including unit testing,

65
00:03:36.464 --> 00:03:41.010
integration testing, regression testing, and more.

66
00:03:41.010 --> 00:03:43.744
In the end, automated testing helps ensure

67
00:03:43.744 --> 00:03:48.540
that a system remains stable, as new features are developed,

68
00:03:48.540 --> 00:03:52.650
and integrated into the CI/CD pipeline.

69
00:03:52.650 --> 00:03:57.650
In all cases, this type of automation reduces human error,

70
00:03:57.870 --> 00:04:01.192
and speeds up the testing process significantly,

71
00:04:01.192 --> 00:04:04.320
especially in large code bases.

72
00:04:04.320 --> 00:04:07.110
Fourth, we have unit testing.

73
00:04:07.110 --> 00:04:11.670
Unit testing is the process of testing individual components

74
00:04:11.670 --> 00:04:14.280
or functions in isolation.

75
00:04:14.280 --> 00:04:17.130
Each unit of code, whether a function

76
00:04:17.130 --> 00:04:20.940
or object oriented class is tested to ensure

77
00:04:20.940 --> 00:04:23.370
that it behaves as expected.

78
00:04:23.370 --> 00:04:25.440
This level of testing focuses

79
00:04:25.440 --> 00:04:28.611
on small, specific parts of the code base,

80
00:04:28.611 --> 00:04:32.490
allowing for precise identification of issues.

81
00:04:32.490 --> 00:04:36.120
For example, if a function takes in an input

82
00:04:36.120 --> 00:04:39.381
and provides an output, then unit testing can verify whether

83
00:04:39.381 --> 00:04:44.010
the output is correct for the given inputs.

84
00:04:44.010 --> 00:04:48.360
Unit tests are typically written alongside the main code,

85
00:04:48.360 --> 00:04:51.810
and run frequently to catch errors early on

86
00:04:51.810 --> 00:04:54.030
in the development process.

87
00:04:54.030 --> 00:04:57.120
While unit tests ensure that each piece

88
00:04:57.120 --> 00:04:59.400
of the system works on its own,

89
00:04:59.400 --> 00:05:03.450
unit tests must be complemented by integration testing

90
00:05:03.450 --> 00:05:06.259
to ensure the whole system functions properly once all

91
00:05:06.259 --> 00:05:09.000
the components are assembled.

92
00:05:09.000 --> 00:05:13.140
Fifth and finally, we have integration testing.

93
00:05:13.140 --> 00:05:16.560
Integration testing focuses on the interaction

94
00:05:16.560 --> 00:05:20.790
between different units or modules of a software system.

95
00:05:20.790 --> 00:05:24.690
While unit tests check individual pieces of code,

96
00:05:24.690 --> 00:05:27.814
integration tests check how units work together,

97
00:05:27.814 --> 00:05:31.286
especially in environments where different services,

98
00:05:31.286 --> 00:05:34.050
or microservices interact.

99
00:05:34.050 --> 00:05:37.830
For instance, testing how an authentication service

100
00:05:37.830 --> 00:05:39.750
communicates with a database,

101
00:05:39.750 --> 00:05:43.980
or how the front end interacts with a backend server.

102
00:05:43.980 --> 00:05:48.360
Integration tests like these help identify issues such

103
00:05:48.360 --> 00:05:51.360
as data mismatches, broken APIs,

104
00:05:51.360 --> 00:05:54.470
or misconfigured communication between services.

105
00:05:54.470 --> 00:05:58.475
The integration testing phase is essential in environments

106
00:05:58.475 --> 00:06:01.890
with complex multi-layered systems

107
00:06:01.890 --> 00:06:03.840
where many different components

108
00:06:03.840 --> 00:06:06.360
must function together seamlessly.

109
00:06:06.360 --> 00:06:11.190
So remember, continuous integration, continuous deployment,

110
00:06:11.190 --> 00:06:15.665
or CI/CD testing helps identify security vulnerabilities,

111
00:06:15.665 --> 00:06:20.665
and functional issues before deploying code to production.

112
00:06:20.730 --> 00:06:23.912
Key testing types include canary testing,

113
00:06:23.912 --> 00:06:27.870
regression testing, automated testing and retesting,

114
00:06:27.870 --> 00:06:30.954
unit testing, and integration testing.

115
00:06:30.954 --> 00:06:33.960
Canary testing allows for phased deployment

116
00:06:33.960 --> 00:06:37.618
to detect issues early on while regression testing

117
00:06:37.618 --> 00:06:42.030
ensures new changes don't break existing features.

118
00:06:42.030 --> 00:06:46.560
Meanwhile, automated testing speeds up bug detection.

119
00:06:46.560 --> 00:06:49.950
Unit testing checks individual components,

120
00:06:49.950 --> 00:06:52.287
and integration testing ensures

121
00:06:52.287 --> 00:06:56.343
those components all work together properly.