The Complete Developer Bootcamp. Learn Web Development best practices. | Maksym Rudnyi | Skillshare

The Complete Developer Bootcamp. Learn Web Development best practices.

Maksym Rudnyi, Teacher and YouTuber

The Complete Developer Bootcamp. Learn Web Development best practices.

Maksym Rudnyi, Teacher and YouTuber

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
29 Lessons (3h 34m)
    • 1. Introduction

      1:51
    • 2. The High Cost of Bugs

      6:33
    • 3. Code Quality

      13:01
    • 4. Code Quality Gates

      10:07
    • 5. Coding Standards & Guidelines 1

      6:35
    • 6. Coding Standards & Guidelines 2

      6:30
    • 7. Coding Standards. Tools

      7:05
    • 8. Code style documentation. Demo

      5:57
    • 9. Automated Code Analysis

      8:40
    • 10. Manual Code Review

      8:28
    • 11. Code review tips

      6:32
    • 12. Code review checklist

      8:42
    • 13. Testing as a Team Work

      14:43
    • 14. Functional vs Non-Functional Testing

      2:58
    • 15. Manual vs Automation Testing

      6:01
    • 16. Testing Approaches and Techniques

      3:08
    • 17. Unit Tests: What

      6:17
    • 18. Unit Tests: Why

      5:03
    • 19. Unit Tests convention Demo (JavaScript)

      4:47
    • 20. TA Place in Lifecycle

      3:56
    • 21. TA Goals & Metrics

      4:54
    • 22. TA Tools

      5:49
    • 23. Performance Testing

      7:46
    • 24. Security Testing

      13:22
    • 25. Software Release

      8:54
    • 26. What is Continuous Integration

      10:29
    • 27. Business Analyst Role on a Project

      6:39
    • 28. Project estimation techniques

      11:37
    • 29. Task estimation techniques

      7:07
  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.

14

Students

--

Projects

About This Class

Hi there! Welcome to The Complete Developer Bootcamp, the course you need to learn Best Practices in Software Development. This complete course is designed to educate and transform you into a job-ready, high-quality software developer. You will learn the most popular best practices in software development, such as:

  1. CODE QUALITY GATES

  2. CODING STANDARDS

  3. CODE REVIEW

  4. TESTING OVERVIEW

  5. UNIT TESTING

  6. TEST AUTOMATION

  7. TESTING OF NON-FUNCTIONAL REQUIREMENTS

  8. RELEASE AND BRANCHING STRATEGY

  9. CONTINUOUS INTEGRATION/CONTINUOUS DELIVERY

  10. BUSINESS ANALYSIS

  11. ESTIMATIONS

  12. AGILE

It doesn't matter are you a front-end or back-end developer, junior or senior - this course will provide a huge impact on your professional life.

By the end of this course, you'll have learned how do deliver high-quality software to a customer or production environment. How to do it fast and with minimal effort.

If you have any questions, please don't hesitate to contact me. I have a huge experience in development and would love to share it and help students learn something new. 

Meet Your Teacher

Teacher Profile Image

Maksym Rudnyi

Teacher and YouTuber

Teacher

Senior Software Engineer with more than 8 years of production experience in Web Development. Experienced both in frontend and backend technologies.

I would like to share my experience with others. You can find courses in Web Development (Front-end and Back-end) and specifically JavaScript. Use this knowledge to improve yourself as a professional developer.

Keep learning!

See full profile

Class Ratings

Expectations Met?
  • Exceeded!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Your creative journey starts here.

  • Unlimited access to every class
  • Supportive online creative community
  • Learn offline with Skillshare’s app

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.

phone

Transcripts

2. The High Cost of Bugs: Hello, my name is maximum Rooney. I'm a senior software engineer. And in this video, we will talk about the high cost of the box. So our plan for this lecture, we will talk about and sequence of barks in software. We will take a look on three different samples and we will talk about how much the arrow can cost for the company. Then we will talk about bug fixing. Force alters that the advantage of early detection of a box. And then the rules we can follow to prevent bugs. And we have to remember that bugs are unavoidable. But what we can do, let's start from samples. And the first one, it's Knight Capital case. Knight capital group was American global financial service from engaging in market-making, chronic desiccation and institutional sales and trading in 2012 was the largest rider EUS acquired with the market shares of around 70% of the New York Stock Exchange. There was a deployment mistake. Court before argued ordered diversification on detonated environment was executed on a production. So when exchange was open, these algorithms started by an Casals and enduring 45 minutes, it bought stocks for four belongs over doors. And the options that companies should solve this issue somehow and have to sell these stocks. And this mistake was caused to hire 50 millions of United States dollars and just 45 minutes of selling and buying stocks. After that, this company tried to solve the issue by buying these stocks again. And in the end to accompany was the whole company was bought by another company. And right now, there is no such company on the market. So this was very expensive box for this company. And other case is Arians five case. It's european rocket program, which was seven billions of dollars as the first rocket was explored and Dwight was exported after a few seconds after when it started, there was error in software when the 64-bit floating point number was converted to a 16-bit signed integer. This quarter wasn't Robin try catch section and become version of the code which should handle this problem, was implemented in the same way and soldier was turned off when it tried to convert this number and the rocket was destroyed. So they'll also 500 million rocket made is possibly the most expensive computer back in history. And the searcher sample, which I want to show you, it's something that the cost of software defect can be measured in dollars pair of fatal crashes. It claimed the lives of 346 people. There was a problem with boiling Exam three Saturn Max. And the first crash was an October 2018. And after a few months there was another crashed when there's a second plan was destroyed. And the problem was in outsourcing of software. Company was a social worker in a company where developers who are paid by $9 an hour. So the court wasn't asked Well, and the cause of this vector written corner was a crash of two planes, visits, deaths, bug fixing efforts. What do we need to? We need to fix a bug. So where Bach was discovered during the testing, we need to spend a lot of time for reproduces bug, ultrasonography mistresses biochar and need assigned to developer this bug. When we assign to discuss what was wrong and how we can solve the Bach, an opposite to take some time for fixing. So from my experience, it takes a lot of time for all of these tabs to read, register bug, reproduce it, especially reproducing, understand Wadsworth, fix it. After that we need this reaches the context, switch to another task or from another task. Tried to fix these bugs and options that you need to download, tacit, verify and calls. So all these tabs or require a lot of time. Also, we need to remember that fixing familiar accord, it's much more easier than fixing unfamiliar court. So if you work misquoted, even know how it works and it's much easier to solve the problem in court, we know, but in court, which was developed a few weeks, months, a year ago, takes more time. So we need to remember that the code that remember that fixing a bug today, is it cheaper than fixing this bug tomorrow? And here we can check that during the software development life cycle on the each stage it takes a lot sometimes. So during implementation stage fixing the bug can take five times more efforts than on design stage and at the same time maintain moments. Then you will find this bug on maintaining stage. It will, can take 100 times more efforts to solve the problem than during co-design. So the latest die when you discover and to try to fix this bucket will take more time and effort and it will take additional money. We can't avoid box. It's impossible to write ideal code. But what we need to remember that fixing a bug is expansive and we need to do everything to prevent bugs. So how can we do the auto steps and rules? We can fall, for example, we can write unit tests. You can create the court convention and try to follow this convention. Also, there are tools for static code analysis and practices such as continuous integration and continuous delivery, which help us to do the batter to become much more cleaner code. That's why we had to use best practices and tools and try to do the best what we can. 3. Code Quality: So in this video, we'll talk about code quality, what is called Quality, and why it's so important. Let's take a look on our plan. Today. We will talk about what Scott quality characteristic of a good court, why it's important, diamond cost and we'll talk about general guidelines, how we can use it. Also, we will cover tools which help us do do our code better. So first of all, let's take a look on this image, or do we assume? Usually it's a very common case when we had to developers and both of them working on the same court, one created Code and nobody knows how this code works, even the man who created it. So it's a problem and we need to award such problems. So talking about code quality, we can spit it into two different bars. It's a fossil called quality and structural called quote him. So what is functional code quality? Functional code quality is emitted to functional requirements without requirement's to create some software and we have some requirements. Functional requirements was this salt or should to do? High-quality if you will implement this requirements and the software will do what do? We can use unit test to implement functionality as its expected structural code quality is how well the Social gold is written. How, how do you write this code and do false our guidelines approach or, or not. So the next, what we are going discuss, mostly we will talk about structural court hardly you write it, how you write your code, maintainable and the court you can use. We'll talk about structural quality Muslim in the next part of this section. So to understand the importance of this quarter, we can describe the difference in two terms, such as written code and work in cotton. So working caught because our requirements and in case the fulfills this requirement, we can say that God is working and it worked with what should you do? The code develop its original caught, so it can be created, but it might not work as expected. How can we say that God is good when it takes on some requirements. So all characteristics of a good code. So the most important is it works with us on requirements called the works. And this requirements are fulfilled is a great. But another important part is pleasant to look at this court. It's very important when you can take a look on the court and you understand how it works called looks, beautiful result, different result, the useless comments without uses parts of court. And you do need to spend some time for understanding how it works. It's apart of easy to read. So you can read it as a novel, as a text or some nonfictional literature. You read and you understand what is there and how it works, why it works this way. And this way it should be simple and single. Means without copy paste, you don't need to copy this code in different places and it should lose some one single task, it's single responsibility. So when you create a function, it should deduce what the swatch is created for nasa nickels, then it's much more easy to understand this function and test. So in this case you will create software visa approach would cause testable in mind. It means then when you create unit tests for this code, you will create your code easier to read, easier to understand, and easier to test, because I think it's an important stage. And when you create the coordinates, this approach, you will try to do it without some useless dependencies or bizarre some global variables. You will try to do it as easy as it's possible. And the result of these taps is easy in maintaining and changing. So we have a coating, we have some new requirements or new, new bug we need to solve this bug. And if caught was written in a good style and it's a good code, we can easy to change something or update some functionalities. Why is important? So let's take a look how it worked with God. I will tell you a truth about writing and record when you are software developer. So mostly you don't write code. We can see here that 85% of time we just understanding CT. We read what was already written. From my experience I can say is that sometimes you can spend a day and just write one or two lines of courts and all time you spend for reading because a court understanding how it was written on, why it was written in this way, what requirements try to implement. And the Harvard towards an office at when you understand how it works, then you can change something, you can implement new requirements. That's why writing code it tells us to persons of our time. Also, you have modifying coexistence caught bandwidth are already written code. We will find the box. We can modify already existing code and add some new. But mostly we read this God of course is, the percentage is depends on the time of lifecycle development of your project. If you just started your project, you will write new code mostly. But with the time in a few weeks, months, a lot of coordinate Andy, you will read court of other developers because mostly you will work in a team with other developers. Why is important? Of course, it's about poor quality may, and I will show that it will lead to the next problem is functional defects. So as we mentioned before, Cold Wars, when it implements some functional requirements, if we write called batter, it might not implemented requirements and your software won't work as expected. Because of some problems. And the next one is the cost and time to make changes, it goes maintainability. How, how much time do you need to implement some new feature or fix a bug if your code was written well, according some court style, you can fix it in a short time and maintain a long periods of time. But if your code was created, result called qualities, result called conventions, I'd called style. And you don't know how it works. You can expend, it will spend more time to understand it for good quality may cause additional application performance issues that we need about it. Because useless part of court make do some users request in network and it will take some time and it will decrease the quality of your application in general. So also modifiability requirement for court which cause how easy it can extend or update your code. So if you have new requirements, you need to implement some new functionality. You need to understand this code and modifiability. We'll show you how much time you need to implement new functionality. Also, poor code quality will increase your technical debt. Technical debt, it's, it's what you should do, but right now you have no time or you can do it. For example, use keeping, writing unit tests. It may be your technical debt that you will need to implement it in the future. But right now, you can do it. Also some problems with your code, the same application performance it can be or technical debt which you should handle and so in the future. And so many other problems can be created by poor quality. So keeping chord quality, its commitment of each team, member of your team, SMA's should understand why we have to do the best that we can while we, while we have to create high-quality caught and what's the reason we need agreed and then motivate people to write this code according to our agreement, according our code style. Because of, we will know that in the future it will decrease the time for supporting and maintaining this code quality. And it shouldn't be your regular activity. It shouldn't be a habit. Every day when you write code, you write it resists Castile and tried to do it as good as possible without wasting time for some additional talking and discussing why two dynasties way or in another way. So how can we do it to use a court with high quality, we can follow the next rules or best practices. And the first one is a code review. Code review is a process where new manually check your code. Is it OK? Is it accordingly requirements you discussed? And if epsilon k, you can measure it or not, you can discuss it and solve problems. And another technique is the unit test. Unit test will fulfill to your functional requirements. You know what, you should implement, how it works. And then you create unit test, which tests your functionality and you're expecting. And the another technique such as functional tests or continuous integration and continuous delivery them. Also we will cover these techniques such as the code review process, testing, continuous integration, static code analysis. It's important part of automating automated and nails of airport and speed-up of development, and also training and onboarding. You need to share knowledge in your team how it should be done and it will help for each domestic due to fall quarter requirements. Let's talk about general recommendation. And of course it's for coding standards in India creators standards for your own team, for your own project and the HTML should fall is standards. Also, we need to try to follow design principles such as good, solid, or another PC. Just keep it simple. We need to create a quarter is a minimum effort. Why do we need it? Because it was the same requirements each developer can create solution in absolutely another way. It will be another record with another sin x is another minds behind and it can implement AS he or she wants. So we needed to do it as simple as possible to reduce the amount of time for understanding this course. Of course, we need introduce code review practice on our project to check the code was written as u expansion or not. And good practice is introducing automated unit tests or integration tests for your code and it will increase your court quality as much as possible and as severe developer, we do not want to spent a lot of our time in case if we can it too computers. So actually what can computer do it should do. And in this case, we have tools to assist. There are a lot of different tools for different programming languages you can use. For example, sonar cube is very popular tool which will follow your rules. You will create some rules and these two can check your court according to your rows as you want. Discourse should be done and the conclusion of what is important. It's important for each developer. It should understand the importance of good quality. Why do we need to follow convention and tried to write court as good as possible? We need defining guidelines for the project. How are we going to create a record and make sure you fall them. So each developer should have to follow these guidelines and tried to write cortical regions is called Stile and act on issue in your code. It doesn't matter. Created you co-star or guideline. It doesn't matter in case you do not follow this convention and you do not act on issues. So there wasn't created unit test or are those written notice you expect you have to act and prevent such problems in the future. 4. Code Quality Gates: In this video, we'll talk about code quality gates. So what's called quality gates? Good quality, it is sets of conditions based on measure two threshold. So what's the most popular quality gaze? Let's take a look on this picture and we will see that we have, right now here we have three courts. Quality gate is unit tests of the cardinalities and manual code review. And let's take a look on unit tests. So good-quality gate for unit tests, it might be code coverage. Approximately 80% of your caught, you set this threshold, us is 80% and you try that all your projects o, this project should have code to coverage at least 80%. And then it, it means that your chord quality gate unit test will meet this requirement as 80% of coverage. But sometimes they are team may decide to add an additional layer of OR gates. Let's imagine that you want to add the additional performance analysis layer and then it decides event where you're going to put this. It might be on Euler step of your pipeline, for example, before imagine into Corbay. In this case, it will be around frequently, often, very often, and you will get your feedback faster. But again, it will be a lot of time and it depends. Do you need this or many runs of this step? Because it may take lot of time, especially if it's a manual step and you don't use CI or CAD tools. Also, another case and you can put it on some later step of your pipeline. For example, often imagine into the code base. And in this case the step will be run not so frequently, but at the same time we will get feedback on the latest steps and it will take additional time for getting this feedback. Let's talk about unit tests. Unit tests. It's special ethnic approach when you test your piece of CT, for example, it might be a class or a function unit test shows you that to this piece of code, function of unit tests is doing what you expect in a coordinated fashion or requirements. So it provides a strict written contracts. That piece of code must satisfied. So you write the what do you expect in this court? It's happier, happy paths. And then when you run this unit tests, you will choose that this court is working according to your expectations or nuts. So unit test ensures better quality but will not catch every error in your program. So it shows that there are errors and you can prevent some of them, but not all of these arrows. It's what you need to estimate doing. Automatic gotten analysis is another popular stamp which checks your source code for compliance. Visit print defined set of rules or best practices. So it checks your code style. For example, camel case, four variable names or using some basis or semi-colons in the proper places. All these rules you will define, you will agree with your team defining some document. Cause court style, and then you can automate this process of checking your code and run before manual code review. So reviewer will see the final version of your code without some technical problems which can be solved by your computer. And also what's important in this quality gate that you get the quick, immediate feedback. You can get feedback before you push your code to source code on the server, you will run this step. For example, we have repulsion or recommend hooks and you will get feedback before you push this court. According to the Sara and very proposed technique, I recommend you to try to use it. And one of the most efficient it's manual code review. So manual contributes reading source code line by line in an attempt to identify potential issues. So, for example, as a developer created his metric West push to the server and you need to check, was absolutely implemented as expected according to the requirements. Or you can open a task, read what should be done, and then check. Was it implemented by this developer in this request? Because sometimes developer can miss some part or don't understand how it should be done or does he or she will work on this task a lot of time and just missed some simple solution. And another about developer can help to solve this problem. Also, another benefit of code review is lowering and knowledge sharing possibility for team members. For example, you have a new buy in your team or just some junior joined your team and he or she doesn't know how you write in your court how it works. So this new teammate can start your quadrennial process and have another Developers, antenna creatures and souls box in your project according to guidelines and the chord, the style, and it will help them to understand your project. Batter also was important in knowledge challenge that there is a procedure calls collective code ownership. When you have a team and HTML develops some piece of your project, you can understand the average scenic and you can't know every piece of code in your project. So when you're doing code review, you can at least read the work was done by another developer and you can understand what's going on in your project to what was written, what was changed, and you know, how to behaviors. And then our code review it, protects against the common oversights. It's very often when some developer working for a long time on some piece of code and missed some simple solution which can be implemented either and another developer can show him that you can do it in another way and better, fast and frequent checks. So when you create your small mesh, McMaster and other developers will check it fast and you will get feedback from your changes and it will improve quality. Also, as I mentioned, everyone can see what's happening and everyone knows what was changing in the project and understand what and why was changed. All these gates are leading us to continue integration practice. So at least integration, it's the social development practice where we tried to automate all steps and do it as fast as possible. For example, we have a LinkedIn profile record is automated. Code checking. We have unit test and whenever developer in your team doing some changes, create mesh request and tries to push his or her changes to the Sarah. This approach continued on all steps. In our case, all quality gates and checks if this quarter gates will fill this measured thresholds. And if something is wrong, we will get feedback with identifications that south obviously we changed or as Nick was good and we can continue our work. Also, it helps to integrate and ensures that social components work together. Sometimes you develop huge corpus solutions and we have to know is actually works fine and men are checking. It will take lot of time and time is money and you need automation of the process. Checking is absolutely works fine. Important requirement to disapprove that each person integrates at least daily. So another developer website functionality pushed to the server and you as a developer, have to pull the latest data from the server and integrate your changes and allows you to have the latest changes on your server. And sometimes it helps to solve some problems. Integration tools to help us to prevent such common progress events. For example, it works or doesn't work on your computer, but in the same time it works on, doesn't work on. And others computer or server. For example, you implement the sum for shelter or fix it a buck and it was fixed it on your computer. But when you push on Sarah, it doesn't work on the server, on dev server or stage, etc. And it means that something is going wrong. You need to check whether there is a difference and what should it be fix it contains integration. It allows us to follow strict court control because dramatically we know measure the thresholds. Would we have to fulfill it and meat would we have to keep in mind that good quality gates helpful to achieve better so we can set up and maintain mark poor quality gates, which will be run automatically on continuous integration process. And then you will be sure that you're cool, your code is good and or measure the metrics and conditions are achieved us to expect. And also what's important, you can get fast feedback. Twenty-five problems. If Samsung coursework, you will know that some piece of coordinates to work as expanded or a quality of your code doesn't emit your code style and should we checked? So that's why we need this code quality gates. 5. Coding Standards & Guidelines 1: So in this video, we will talk about coding standards and guidelines. So first of all, let's take a look on some facts from 40 to 80% of lifetime cost of software goes to maintenance. So why is it? Because developing a good tube jar, some period of time and options that we'll leave these projects for maintenance and support time because of data or development was finished and they will be using, and sometimes there will be some box it should be. And also there will be some changes should be implemented. And Mausolus, as time goes to maintenance. And what's the most important that a court author, the person who created is called irregularly maintains these court for lifetime of the product. And so for example, if some big project is who in development phi four years developer who created a part of the Hiroshima may work on this project just a couple of years. And then these projects, project goes to another developer. In this case, we know houses developer will work visit how he will create this code and what will be done in the future. So cost of box growth during a post implementation and maintenance stages because of they don't know why these got was created in this way. So Style Guide can help a lot because of Tang, God describes how we should grazes core towards the pros or cons, and we know how it looks in the future. So without coding standards, maintainance becomes more expensive because of we need additional time to understand the courthouse, how it was created. And let's take a look on goals and motivations for coding standards. Why do we need it? And the first of all, it's enhancing called clarity. We need to create court. It should be good for the good for read. Ours mostly over time we maintains, quote, we read this cause so we shouldn't be ranged from reentry perspective. We need to read and understand what was inside disease quarter, why we implement the z-scores in this way. And it helps us to reduce a number of risks in software development and reduce complexity of a court. And in future it will help us, it will help to reduce the time for maintenance and implemented some changes or fixing comebacks. This is why we are going to create a CTE, which will be to support in maintainability and we can change the future. So we know why do we need the coding standards? Who was benefits of these coding standards? So let's take a look on what is coding standard. So coding standard components is just a document. So they are team based on each team member experience, can seed or or organize a meeting and decide to how do they go in to create this court, what they want to do and what they want to avoid or skip during development. Or maybe exosome or already prepared code guidelines in your project or in your company and You can follow these already prepared guidelines. There may be different options, but you, you will choose for your team, for your project. What do you want to do? Also in this core standards, you can declare what they are going to do. How are you going to fall code review process? Or I am going to use peer programming or what tools are you going to use? For example, you can define that your project, you're going to use sonar cube or checking your code and then define all rules you want to follow in this tool for solar cube. And it will automatically check all your code doing on automatic code analysis stage, talking about according statements, we can split into two groups. It's the style guide and court convention. So what is titled guy concerns? What do we need to remember about when you're talking about style guard, stand regarding guide, it's mostly your layout of source code, how you organize your code them from a visual perspective. For example, inventions between blocks is two spaces for space, or you're using tabs, or for example, for constants, are using capital cases or another cases. How we organize the names of your classes, is it uppercase or know? Arsenic is, and describe in style guide. Contravention from the other point of view is highly organized euro project in general, for example, I organize your file structure. The uses, some programming principles and practices in your project. Do you have some recommendations from your team or from your project or for your company, what principles you are using for the whole company in each team. Or you can use some specific tools or practices specifically for your project. And also architectural best practices. What should be used on your project and what you should avoid. Why is important? Because of mostly Development team, it's a communication cause you talk with another developers who created part of CT or some functionality. And sometimes this is developer don't remember why it was created, what wasn't tangent inside this court. And when you create your guideline and try to create your code during these guidelines, it will create some clues or hints of what was under this function and why it was created in this way, not in another way. So actually, he's describing in Norway and it helps for each developer in your team understand some principles, how it was implemented and why it was implemented in this way. In the same time it makes errors or at least make some errors overs because of you following some rules and some general areas can be skipped dust because of there already are no known issues or known errors and can be awarded because of this knowledge which is described in your court style or core convention. 6. Coding Standards & Guidelines 2: In this video, we will continue talking about coordinate standards and guidelines. Why is it so important to following Coordinate conduits? So coding standards and conventions can help us to understand the court without documentation in the future, for example, or in case. We will have some newcomers in our team. These code conventions will help our new newcomers to understand this course better and faster and start working as fast as possible. Oscar helps us to answer the next question is, how should I write batter and readable code? How should I fragment code into meaningful methods? How should I name a variable so that everyone understands it? How can I make complex conditions look good and readable? How do I shape the code based on the packages and namespaces? All these questions can be answered with created in your team, court convention and code style, how you, how you should create your cortex. So let's take a look on one's simple sample. It's a couple of pieces of code how it was created. The first one, it's defining a variable. And here you can see that it's very hard to read and understand what this variable means. So it understandable. And the opposite. You have another case, the same variable, but you can really understand it, its duration timestamp so that you know that what is said here. And for this variable, you do not need some additional comments. This timestamp comment. Because of in future you can change or rename the variable, but not always your change commons. And it costs. Like comments can ally with the time when you change your code and don't change Commons. Commons becomes a big problem. The next sample its function. And here you can see that it was created like a temporary solution because you don't understand what's going on is this function was the cycle. If condition works, what does it mean this for number? And it looks not as a good court. So from other side, we can take a look on another implementation you should look, which looks much better. It here you can see this for margin compare chord. You can understand more or less how it works. We see that all headquartered values like for was replaced with some constant. And we at least can understand what does it mean fact or in the future. We can maintain or change it easily come to this chord becomes much margin batter. Also we can see the next chord which looks also better because of it's more readable and you can read and understand what was passed here or the parameters and how it works. So could conventions help us make our code readable as far as possible? And in this case, we don't need to do additional mental work. It reduced mental mapping. It means that you don't need to remember what was X. What does it mean? This list one was this variable means. Also, it helps us to create better variable names because we know that generation timestamp, it's much better variable name then DM HMS. I don't know what does it mean real em and always use pronounceable name so you can read and understand this variable without this where repairable solutions. So why do we need this clean CTE Standards and why it's important? Let's take a look on this image and we will see that we have visit Taiwan, cost of changes and rehab, optimal responsive, responsiveness, how you develop a CT. So at the beginning we need some additional time, this red line, we need additional time to implement it. And following court rules, coordinate the convention called style. But with the time it will take less and less time for holding kit and code will be better in maintenance and metro and reliability in the same time, cost of change. If we don't follow these cortical mentioned, coastal change will be increased dramatically, exponentially, exponential view because of We will occur is increase a number of technical data. We will increase the number of foreign street should be referred to as our change, will increase number of box or hidden box and visit time it you'd be much more expensive and difficult to maintain and change this code. So this is why we need tried to follow Queen code requirements and it will increase our reliability, tangibility, extensibility and maintainability features of our coordinate. So we need to remember that quote, which is based on a standard, is investment to keep the cost of changed constant as far as possible. Throughout the lifecycle. Software development, through the social life is life cycle. We know that lifecycle can take a lot, many, many years and in the future, some another developer will maintain your coder and we have some documentation describing this code conventions and standards. It will decrease in number of arrows and increase number of fixit box in short-time. And about cleaners. Why do we need this clip and where it comes from? So green coat. Because from a cleaning room from electronic industries, there is a principle that clean room reduce the defects during, during fabrication. Sounds like inner factories. So when we reduce a number of treasure or sounds in key users in your room, we will make fabrication batter in the same time is the same for a court. Whenever we remove uses part of courts, if we tried to create it as lean as possible, is the final product. The final coordinate will be bigger and higher greenness and you'll be better for maintains and understanding how it works in the future. 7. Coding Standards. Tools: In this video, we will talk about tools which help us to maintain a record more clean and for our guidelines. So first of all, let's start from various ID and ease integration development environment. Usually it's your map storm or del g or might be visual Court ends in court you want. So mostly all these tools help you to create your court more cleaner and automatically check option called. You need a lot of additional tools you can install or reuse for your project or for your specific language. For example, solar cube. So the loop is it's a tool which you can run on your computer locally from Docker, for example, or install on your computer. And it will analyze your quarter for example. It will, it can show statistic what approaches you are using, what variables you're using coord, parse, you're using coal for example, what different languages you're using. Web development, it shows how much email, CSS, and JavaScript is in your court. Also, it can show some corner smell. So water was, and what is bad in your coordinator shouldn't change. Also, it knows about some vulnerabilities and arrows, general errors in software. So it can show that this implementation can be changed or updated because it's not secure. Also the additional tools such as the ES lint or Peter, which can reformat and update your court. You just just run this tool and it will change direction, what it can update. And it helps you to do not waste your time because of actually quote, the machine can do, it should do, and they don't need to waste your time for such sin x. Also, here we can take a look on intelligent idea accord style. So here in this idea we have special downwind settings for specific language or for different ranges. For example, in our case it's JavaScript. And here you can specify a lot of options. How do you want to this code should look. And really it very useful and I use it very often in my experience. So you can describe here rules and design. Your IDE will show some hints or which will show you some errors, or to be updated and it will prevent a lot of errors and you're Coke will look the same for all developers who just need configure the same rules for each developer. You can use it, man. You can do it manually on each computer or you can create some file with rules and just upload this file. For example, here we have a schema with this following girls and you can manage it also what we need to remember, it's a practice of code refactoring. So refactoring help simply mats standards with a minimal impact. So why do we need this sort of factor, function and hire cooks refactoring is, you can say it's a second or third look on your code and you can see the same interface is same function names and how it looks outside, but inside you can change and update your core. For example, you had the first implementation of your cortex was George. But it worked and it was OK for you for the first time. But intellectually it as the technical debt, then it's sad to return to your code and updated. And from the third diversion, rituals, terrible inside and not efficient or with some box or some cases, it could not work. He decided to rewrite and Andrew factor to do it badger AS possible within your time range. And over time you have for refactoring and doing a file-sharing more efficient to have ID, which helps us to do it faster. For example, renaming of variables and classes. In case you have a big project with a lot of number of different files, different namespaces, modules, and age decided to rename your client glass because of the might be another class in an automobile or you decided that it shouldn't be more readable is another name and a incase. You will do it manually. You need define all class, impulse survey. It was inputted how it was used, and the rename it manually. And in this case it can miss some part. Your code won't work as expected. With the ID. You can do it automatically. And this tool, we'll find all your classes, land was used and replace it automatically without your effort. So it would have been much more safer and faster. So try to use these tools as much as it's possible. And general rules for using code, convention and Castile tools. So and in general, embodied comprehension. So always follow your standards. You need to define these standards and fold them. Tried to follow design principles, exam it's keys solid. Tried to greater convention and be consistent on this. So if you design it, describe convention in one project, you can use it in other projects. Or if you have some convention on the beginning of your project, should you follow this convention? Do recur project and don't change it. Visit time. Also, always remember about Boy Scout Rule. It's very important and interesting, cruel. It means that a court or a place after you shouldn't be better if it was before you in case it is called the starch referred in some piece of court, some general, some function or some class. And we can implement to refer to in practice here and do it better, unreliable. Maybe remove some box or remove some technical debt. And to optimize this code will do better and it will help you in the future and it will make your life better. From experience, I can say also, what do we need its root cause analysis? So in case you've paid through some bug or some issue is you need to find out the reason why it was created, why it was done in this way and fix the manual reason, not the result, but reason. And then you award this box again because of if you keep fixing the reason in the future, this bark or this problem, we'll face you again and you'll get more and more problems. So try to avoid it and do it right now, fix a bug, fix or reason, and then your life will be easier and better. 8. Code style documentation. Demo: So in this video, I will show you a demo sample page of vocal style, how you can use on your project is damaged. One of my projects and real live demo. And you can create your own project called style based on this demo or can change it as you want. So what we will start, this project is based on JavaScript and the main library, it's a react. And for Linton tool we use to ES lint, disco style is specially for front-end and for React, but you can change it for your own purpose. It may be for your own language or forefront handled or buy candy does matter. You can change it as you want. But there's a main ideas that some sections are some points. And by understand what you can add for your constant, then you can extend it as you want for your own purposes. Here is my example of code style I created in Google Docs. And you can use the same approach or you can create your own document and put it into your source code and share it with your core. It doesn't measure, depends. Ico team wants you can create as you want on your team wants. So what did we help with the title, of course, and it becomes the next section is wiped libraries and tools to use naming, consistency him support element and ability under the added ES Lee improved. And also some section for performance. You can add the different sections. It's absent is based on your experience on project requirements and team experience, what they want to add a field. So what's important here that I wanted to mention that dynamic and consistency. Let's start from libraries. Here You can share libraries you are going to use. In this case, I added, for example, Bootstrap for some common coal or so actually quotes is styled for styling is taken from this library. For some shared components, use the indifferent projects. We can create some separate repository whizzes library component components and use it in your project. Don't create it. Create a copy for your own projects. Also here what we can manage mandate EventHandlers. Here is mentioned how you should name your event handlers functions. It should be warped, starting with dorms. Also as an X1, it's Gad functions. All of them should be pure functions. So it means without any dependencies and shared state. Purification is the best practices for such approach because it's easily to test and maintain it. So naming for functions, for naming for Boolean variables, usually it should start with E's so easily these error is sounds like it's a good practice. Also for function which returns a boolean values you can use. Graphics has, his case, has empty field. For constants we use these approaches is uppercase, but you can use it based on your language or some specific specification specifically for your language or project or your team wants to do. Also seizures in kids. Some constants, they are shared or in your specific component. So also fragment or reactor allows to Joseph Singer and therefore friends. If you don't have a translation for French, for example, we use Translate shouldn't for English and add a fair prefix. And it's just, in my case for my team, for my project. You can judge it as much as you want. It doesn't matter. You can add entity keyword also for support and maintainability. We mentioned that we need to add the prototypes always define default prototypes. Also we write display name for tile components, and we're using style components instead of inline styles. And it worked for us very good. Also every to-do, if you leave a comment, Luis, To Do, you have to add a link to your ticket or any other Ticket Tracking system you are using a designer you will know why is it to do is edit and do what can be done or changed in your court in the future. Maybe it's time to update it and refactor because usually it's technical debt which should be updated. Again, pure functions we are using. Also as I mentioned before, ESL intervals. There are specific rules that you want to fall and do not do it manually. You create a file with these rules and the ESL integral check it. And here we added just Islamic standards rules. We can use Airbnb as approach Airbnb or best practices and then just extend to ease the rules we want. Specifically for us, what we lived and some for performance. It doesn't matter, you can add something else. So it's a sample of this court style. This is a Google document and you want to add the lean causes documentary or documentation. For example, you can open your project. Let's take a look on this project. You can open your project and here in your README file you can add sections, for example, called style and a link to your document and all this, all team members will know where to find this style and you can refer to this document in your code review or in discussion home should have your course should be done. So you can use this approach and you can extend it as much as you want specific loci for your team and for yourself. Thank you for watching. 9. Automated Code Analysis: Hello. Today we will talk about automated color analysis. So what is this? Automation announcing its approach when you analyze ALL court against predefined rules and best practices in automated way. It means that once you defined all rules, the rule set, do you want deal court will look like and then automatically it will run us often OS you want manifestos. This approach is that it's done, done much faster and much more efficiently. Compare it with the manual check so you don't need to waste your time against the check how it works. Automatically cut analysis was important that sold for analyzing soldier. So as I mentioned before, actually was computer can do it should do not have to waste your own time and it will be much faster and efficiently. Also, it's inexpensive because of it's done automatically without human. Doesn't cause almost any SIM come. Also, this approach helps you to easily detect any duplication of your CT and decrease the amount of fuel quartet and need to cover with you to test is the same courts twice, for example. Also it even may is accuses sulfur and doesn't do charcoal. In a real life automated coordinates, this can detect the different types of issues. For example, it might, it might detect security issues, got duplication, or even bogs, couldn't. Analysis can be executed in two ways. It as static code analysis results Veronica program it to analyze your CTO. Hollywood was written and can find the problems you use a structure or some are already known issues. For example, SQL injection or using some unsafe for functions and nicer way it's dynamically automated code analysis. In this case, tool can run your code and analyze how it works for and memory and the time perspective and disease is it's a combination of two previous cases. Talking about dynamic analyzing, we can meant that its program profiling, program or file that gets dynamic analyzing when it measures a memory or a time complexity of usage, occasion all of the different functions. So it can check function is efficient or not, how many times it was called and how much time does it take to run and to be finished, both types of coordinates and static and dynamic is a both. Caution you to improve your cord and it shows what can be improved and what can be changed. And the next lesson to talk about one of the most efficient and most popular tool for analyzing according to its Soma Cube. Sonar cube is an open source platform and it developed for different languages. So right now it supports more than 20 different parameters and it can analyze the next issues such as box called smiles and to security vulnerabilities. It's Mang, most interesting parts. And in the same time it can analyze your unit test, coverage and diodes how it was implemented. A lot, a lot of other synonyms. Let's take a look on this picture. So that were found for barks and allowing the vulnerabilities that the can and have to fix. Authors are called smells. It found 2.6 thousands called smiles, and it will take approximately 67 days for one developer to fix all these issues. These two Analyzing and can predict this style approximately somehow. And also code coverage. It shows that we have pretty good cuz colors is 990% and we have 18 thousand unit tests. So it means that you really huge project also in some period of time, or the house on improvements or not. For example, we improved code coverage is too easily can be integrated in your IDE integrated development environment or in a, or in your continuous integration pipeline using Dan because or silicon. You can use it everywhere where you want. Let's take a look on the next 3M vulnerabilities it shows. So Corps smells because mouth, it's not an error, is not the bark, but it's some part of your core that in the future may cause some problems. It may cause error or or it may take additional time for maintenance or fixing because a court, for example, it might be very difficult to written application or from a performance perspective, your unit, for example, 345 cycles inside and it will take order of time for execution is caught ME works, but in the future it will cause a lot of problems. So usually it would be better to improve. It can improve your performance or improve your readability, readability of your court. It's good practice when you try to fix all these code smells and try do not continue supporting exam and transforming into the box, the future marks box. It's issues in Soma cube that shows a deal court works wrong, and it shows that you're likely not viewing the intended behavior. So you want to do implements R1 functionality, but it works as not expected because so some issues and other parts of court. So it can find Creek is box and the box, they shouldn't be fixed Absolutely. Because they can create a lot of issues and the real, real, real problems for your software and your company because it may break because the whole behavior of the application. And also we want to build this on a cube helps you to find and track and securities in your code. A lot of different examples you can find or well-known issues. For example, security issues, a SQL injection or hard-coded passwords and badly managed arrows. As I mentioned in the first video, some badly managed arrows can crash the rocket if it wasn't handled us expanded. Also, there is the issue, for example, is with eval function which can execute unsafe court. So try to avoid such functions or some other functions which are not poeple are in your language, specifically in your language. And this tool works very good, but it has some limitation. So Menon digits, business domain and requirements, these two checks record based on some predefined rules, but it doesn't know about our intentions or domain, whereas the soldiers should be run and some specific locations. So in this case, a human can check and improve result. These are high divergence in opinion on what is good and what is bad. So for one-upping each good is a court can work good from Alaska one, It can work back, so it just shows some metrics. And asean last part here is that matrix handle it somehow and they have some meaning just in case you can observe and do something based on this matrix. Otherwise, it just shows that how we are quotes is organized, is written reasonable smells or mark smart. If you don't do last inquisitor, it will, it will be used. Those Soma Cube is just one of tools you can use. A lot of different tools specifically for your language or Korean environment. For example, ES lint and precursors are great for JavaScript and can be used widely for another language. You can find different tools which improve your code as much as you want. So to recap, automated coordinate axes is efficient and fast approach which helps you to analyze your code, find some box or vulnerability or codes miles without waiting gelato fueled time because it is running automated way. And as a result, it improves your code and decrease the time spent in the future for maintenance or fixing some bugs in this code. So try to take a look on different tools and find the best for you. Thank you for watching. 10. Manual Code Review: In this video, we will talk about manual code review process. So what is a code review? Code review is systematic examination of computers source code. When you finished implementation some piece of code, it might be fixing or finishing some feature you create mesh request and another developer on your team or from another team may check how you implemented this court was averaging implemented, was implemented according to court standards called style and was a functionality implemented. This process is taken every time when you finish your task. The main purpose of this process is to find and fix, overlook mistakes, improve the overall quality and security of software. So very often when developers create corps, he or she can missed some part which can be improved or should be fixed. And the country view, it's not automatic or manual process. And this process helps to improve these phases because of another developer who might be a bit more experience can review your code and suggest some improvements. In this video, we'll talk about the next Codreanu aspects is a process or also in code review process, review type, best-practice and tools. Why it's important. First of all, it's cost effective. Because of fixing. They're looking for embark on Codreanu stage. It costs much less than this bike will be deployed to production. And this is what we will find them in production stage by users. So it's cost-effective, but compare it to these dramatic gotten analysis. It's much more expensive because of some developer have to spend his or her time and take a look on this CTL. Another respect, it's a fewer bonds. So reunion record. The developer can find some well-known box or can best based on his or her experience, suggested what can we fix it and they're not alone. Glue, push your box to the main source code. Also important is knowledge sharing. Because of software development, it's a team work and a lot of developers can develop some parts of, of court. You can't no arsenic in the project. So when you review somebody's code, you can learn some new features which were implemented and you will know your project batter also code review helps us to implement such a feature like collective code ownership, where each team member knows the whole code in your project. And again, fix any part of your application, even if this developer D1 to work in the first place, the busiest caught, the next type is called, called. It improves good-quality because of not iris and can be fixed at or cached by static code analysis, some pieces of CT can be fixed, fixed and found just by looking at them by real person and understand that this court should be updated and security and performance standards. So code review, reviewers should check if all standards were applied in this mesh request or this piece of code. So and what is the process, how it works? So we have a court coding process. For example, you had the bark and the new fixing this bug and decorated all requests to the server. Then you assign this dot. You can assign these mesh requests to another developer. And the developer will check, check your code and we'll perform colleagues reviewed these developer Route check was absolutely implemented according to functional requirements in the task. Absolutely implemented according nonfunctional requirements such as a unit test code coverage, coding standards. It was absolutely implemented. The two and then you have two options. Either the awesome sick not implemented or the awesome comments could review ever can address commons. Reviewer will add comments to some particular align and matches it. This piece of code can be a fix it or this can be updated or scientists should be changed and then developers should the response to this comment, resolve them and fix problems. And again, code reviewer reuses code again and if everything was sold and fixed and the other questions or comments to your mesh request, developer can resolve all comments and approve marriage requests. Then match request will be approved and merged to the codebase and then your mesh request is caused and code review is finished. So we help code review process. We have address and commerce and everything cookie coordinate will be nourished. Also, let's take a look on roles in code review that messages are two types of roles is the person who rise because at court and it's called should be reviewed and reviewer a person whose targets coat and Mae's comment on need. So in case you created court and created push requesters, Sarah, you author, and somebody else. It might be one person or a couple of person in your team or for Moussa Kim, their reviewers, they can Europe in case somebody else created court and asking to check this code, you will be reviewer and Sort row it's moderator is optional URL. It's not always exist, but sometimes if there are some comments for mesh request and two people are to a new Can agreed. Was it ok or not? And they have some the agreement we can ask these moderator and aerosols is disagreement to find the best solution. Also, the moderator can double-check the court and double reviewed or everything cost, okay? It can be applied for various security part of your code or very important parks and hard to review. There are few types of review work. First of all, you can use pair programming coding. Two developers sit on one computer, one developer, romantic functionality, and other developer looking on this implementation and can add some comments and suggests what can be improved. From my experience, we use pair programming, but not in code review perspective. Also, there are two assisted code review, folklore, floors controlling systems as GitHub or some version. They have special tools which allows you to do your quadrillion efficient. It can compare files, current division and previous and shows the difference. Also, it allows you to leave comments very easily. And also you can assign mesh request to some developer, get feedbacks, get Review, and easily handle this process. So what do we need to review and why it's important? First of all, as we review worse, we invest, invest time in reviewing convenient to be sure that this code is readable and uniq will be easy and that we don't waste our time. The next what is maybe the most important is functional correctness. So we need to check these mesh requests implementing functional requirements from the task assigned to the two outer. So if we needed to fix a bucket, we have to check this court and the realizes mesh request fixing this bug also is Completeness. Was it finished completely or some schools more than finish? And we need to reassign this task again to author and he or she should update mesh request and provides a final version of his chord. Also we review test. It might be unit tests, integration tests, but they shouldn't be reviewed also. And we check if we used according standards agreed on in our code guideline and was absolutely implemented according to these guidelines. So it's why we have to review it. And what were you doing coding career process. So thank you for watching. 11. Code review tips: I will show you a few tips, will help you to do your manual code review more efficient and more enjoyable. Few tips. Let's start from the first one is them review less than 400 lines of code at a time, the brain can only effectively process so much information at a time. If you try to review more than 400 court, it will be an efficient limb. In practice. A good number is two hundred, four hundred lines of code, and it means that you will find 80, 90% of defects in your corner. Next one, Take your time. Expectation race should under 500 lines of code per hour. So do not try to review everything at one time because of efficiency of your review wouldn't be as good as you expect and you will, you can miss some box, so do not rush here. Also another important part, don't review for more than 60 minutes at a time. Quadrennial process, it requires the concentration from you end. If you try to walk more than 60 minutes, your consideration we will drop and number of arrows will raise. So why it's important? Also because you work in a team and the different team members can create mesh requests often and you need to review it. And it takes a lot of time. In case you will do all reviews first, you can miss some important fixes or critical bugs. And that's why you don't have to rush. Because of you have a lot of marsh requester hat and those are important. Deep is set goals and capture metrics for your review. We don't use very often in my practice, but it's a good approach when you know, what are you going to achieve using this code reuse. The next one is really important is after should annotate source code before the review. How it looks in practice, where you create code review in discussion section and we can write what was changed, why it was changed, and how you change it may be you can leave some nodes or some machines for important parts in your court. Eco deeply on these parts of your code and maybe this parse our most important and it will help increase cold-call term also, for example, if you are fixing them bucket, you can leave a comment. There isn't OSes Bach, so investigated, so squatting, investigated bug you reproduces Bucky know why it was why this bark was created. You can leave a comment, the reason and a solution, how you fix these Barker and it's a really important part. Another important tip is use checklist. We have teams for development projects and each developer in the team can do the same errors. It's very difficult to remember action code you should do when you create mesh requests on or when you review mesh request checklist will help you. And in the next video, I will show you one of these checklist you can use for your code review. We used it on our previous projects and really deep. Next one is establish a process for fixing defects found. So when some barcodes, phone or some defect, you need to provide the feedback or common to your author of these mesh request and design chair coup was this bug fix it and how it was fixed at all. So you can create some nodes in back-tracking system if it's okay for your project and other part, it's foster a positive Codreanu culture. So we review a corner node outers and it's important that area D member will be happy to create mesh request and they want to get feedback and get some improvements of the record. So you try to create a culture where reviewing is a positive process and everyone likes this process in your team. The next one, Embrace the subconscious implication of peer review. So it's important to get some results of you're your review unionists invested time for this process and author should understand to what was changed and why it is called should be updated to do the next one batter and is an expert. Do you tried to avoid the same errors? It's very often when reviewers left some comas after infix exam but didn't analyzed what was wrong. And then in the next, mesh requires two, has the same errors, the same problems. So unconsciously we have to understand what was done and how we can do better the next time. And the last one I can provide you is practice lightweight code reviews. It means that the trie nodes create a huge mesh request is a lot of files. For example, if you open metric west and you need reviews, mesh request, and there are 2065 files were changed and each file more than 100 clients. It's really very demotivating process and did not want to review this mesh requests because we know that it will take a lot of time and to do it good. To measure classes requires some steps. For example, you need open gala ticket to read and watch and be implemented here that you need to see which branch runs a court check, most African implemented according to the requirements, according to the design, and then review each line, understand how it works, why it wasn't implemented. And in case you will create a huge heavier code review. Having mesh request, it will take lot of time and in this case, some parts will be skipped unconsciously because of developer can spend a lot of time and he or she doesn't want to waste a lot of time for this process and try to do your match requests. Us. Pause as often as possible with not big number of changes, it will improve your process and the reviewer will be happier. 12. Code review checklist: From the previous video, we know that using Cogito checklist helps us to improve our code, review process and decreased number of error. In this video, I will show you one of possible Codreanu checklist. You can use your team to improve the process. We have a code review process and here few items. Ok, let's start from the first one. Korean branch from the latest monster is of course we need to grade all branches from the latest version of our code and name branch of the dura ticket or Osama nozzle dust dragging system. In our case, we have a drear ticket, dragons system and we have a project idea is Persian DNA. We have a task number that recreate a branch resist number. Why do we need it? A lot of tools. A lot of tools such as GitHub or Bitbucket allows us duly in general, and this is true and well, we create mesh request based on this project ideas and symmetrically generated a lean tool or a task tracking system. And you need just click in GitHub for example. And then you will be redirected to JIRA and you'll see that ticket. And other materials important is of course, where you create magic raster for code review. We did implement feature or bar according the ticket from Jeremy. So we have some requirements from just tickled when implemented in marriage request. The next one can be added or not. It depends of javier team decided, but you can rebase on latest master node bayes rebasing. It has some benefits comparing marginal. Also what's important is all called dev test. And so you implement this opportunity, you have to test it on your computer by yourself as a developer. Checkers is everything works. Or if you fix a bug or you need to check, was his Buck really fix it and then grade mesh request for already provide the functionality him and understand. We already mentioned, mentioned of automatic code analysis tools such like solar cube or ES lint. So we need around LinkedIn, check all box in our corner, fixed format code and does after that create mesh request, we don't want that review where we'll analyze code and found some box which can be fixed automatically you very easily and very fast. The next step, what I can recommend you, it's run unit test locally and update snapshot if you use except for testing on your local machine. So doing a great measure quest with non-fixed that or not created the unit tests and other recommendation. It's when you create the mesh equality you can add to commit message, ticket name and idea for example. And then this is a nice message would automatically description to your mesh request. The next one, it's CIC d. By applying, what do you need to remember that when we create mesh equations, do we need to provide a title? It should be the same as a JIRA ticket than the first one is automatically linked already before as the next one when you read the mesh request and starts go, Do you know what should be implemented here? Four bucks. As I already mentioned, we provide reasons, explanation why this bark was produced and the solution, how it was fixed. At the next one, we didn't add all relevant reviewers. For example, if you have mesh requests and team as are free for developers and minium to developers should check code. You can assign these mash request specific developers or any develops and then they will get vacations that disease in your mesh request. And they found two start to call the process also another good best practice. It's using some slack channels for, for reviewing, measure quest. You can create mesh request and then Santa lean disease much requests to the Slack channel or Skype, Skype and or L1 developers. You will know that Zazen, you mark and all relevant developers, we will know that there is a marriage request and they can review your CTO and other good practice. Changes status in a ticket tracking system to cognitive task had status in development. Then you move it into code review and when it will be finished, you can call this task. Also. Sometimes you can assign a task or the main reviewer. For example, it might be a team lead or some another developer experience in this area. And she will be the main reviewer and you can assign mesh request is distributing. The next important step. It's fixing comments. If there are some comments, that task wasn't implemented or something shouldn't be changed. We can add the API, working progress graphics to the title and reassign this task to after. And he or she should fix Commons resolved commas. And then again creating a better mesh request and do averaging. Do all steps again to check if Absolutely, according to this chord review checklist, when all comments are resolved, you can remove work-in-progress status or based on the latest master and Zen. Again, assign request and main Reviewer. The next step it depends on, on agreement in your team. For example, you can have minimum two likes to approves for your marriage request. It means that even a one developer already reviewed your changes, you need at least one more developer. He or she should check, was absolutely implemented from your side, was averaging. Okay and reviewed fine by another developer. And in case arsenic is good, then you will have to learn to approve and you can continue with the merge your changes into the main code source. Also, there is a problem. Sometimes when you create mesh request, you the utrification to all relevant reviewers. You can add link in Slack channel, but the reviewers of a BZ miss some, another task. And Leon, starter you incur process. So it's your it's your responsibility to facilitate the code review process. You need to push all developers who have to review your court and get your two approves and design just merge your task so you create a mesh request. You have two clauses, mesh request and it had to be sure that it was reviewed and there are no comments or issues in your mesh request. And the last one here, in case some conditions are met in this mesh request manner, you can close it and dog motion into the main branch. So if you implemented some bark and you've seen that the implemented this bug about two real, it wasn't implemented. Mesh request can be calls and you will, or another developer will fix the bug. Instead of. To recap. Here you can see the checklist, what you can use during code review, before quadrotor, during cornering and ostracon reviewed, you can extend it and add. What do you want, what was agreed on your team for your specific project? And try to use this approach. Also what I won't mention it, that code review checklist, important and useful part of your development process. And the you can create a median can your team and create your own code review checklist to improve your code quality and create your own checklist as you want and always tried to deliver best code quality product. 13. Testing as a Team Work: So we will talk about quality and the hard test in a, in a team can help us to improve this quality. First of all, let's take a look on our plan for this video. We will talk about quality. What is quality and how can we measure it? Also, how can the quality affect the speed of development and product at all? Also is not about quality in and team work, how we can improve it. And some tools which helps us to work with quality such as testing Pyramid and ideal dat and deadline in during a sprint. And we'll talk about collaboration between testers and developers who can help each other. So what is the quality? Alter it sounds to all those bar. It's the general and difficult describing details. What does it mean? We can describe a quote, give us a value for business. A good quality product brings bigger and bigger income for business. It's much more money. And other point is user satisfaction. High-quality products bring satisfaction for users to use this software and it improved collaboration with costumer and this product. Also, it means that fewer user complaints, so they are more satisfied and report allows marks say, happy to work and they use your product. And it means your protocol has a high-quality. How can we measure the quality? There are few attributes for measuring. And the first one is usability. How easy is use your product, how is all news and how it helps your customer? The next one is performance is very important. How was Peter, and how fast is your software, for example, or your product? Because right now as we know, the speed is very important and in case your product work slow, nobody wants to use it because time is money. The next one is availability. How easy is to use it? And all costumers, can you use it or does it require some additional time to understand how your protocols, or you can just take it and start walking. Next one, it's important security. Right now in our directory, eager to say our data, data privacy and didn't want to share it. Security is one of the most priority attributes, quote, quality and the quality of product at all, and a lot of additional different attributes. How can we measure a product quality? First of all, we can measure a number of defects or box we missed during development and disease bugs were found on production and reported by user, users. So in case you all on box, it means that we need to update our task Nick approach and find out what we can change to decrease in number of box in production. What is important is that we can't measure different products from different domains. There are different what we can do. We can compare the same. Our product over time. For example, may release and arteries is released two files at number of box where increased. That it means we did something wrong and we need to provide some. Analysis and find out what was wrong and improve it or fix it. Let's imagine that in the previous sprint two, we were pushed by our costumer or fourth managers, we need deploy something faster and we skipped writing unit test or whiskey. Greatness on another task and product wasn't asked us. It should be tested. And as result, after deploying to production with regard to bigger number of arrows, means that we need six unit test. We need a double test averaging and push of data changes. There is a magic, the fact contaminant effectiveness, which measures the quality of tests in itself, not quality of product but quality of testing. Usually it's a ratio of defects found internally to all found effects, including production defects. So the target of relished the 95%, at least. How can we describe quality at speed? So first of all, identify the facts early. Early we will find the fact, then it will cause less and it won't affect the user's in production and you will brew our quality and improve user satisfaction. The next one, what is important is finds the important defect. Defects are different. One huge blocker and production. It's more important than five or smaller defects which do not affect users directly. In the first place, tried to fixed the most important box. We can find and fix all box, but we don't need wasted time and testers QA, and they can't wait while all features you'll be implemented. So us, we implemented the first feature testers can start testing it and then continuing with the point, new features do not wait when the whole project will be finished and then start testing. How can we reach this goal? The regions we need to use clever proactive technique approach. We need to be proactive and analyze risks and progress which can affect us even if it's not our responsibilities. We can improve and deliver. Coordinate is a big number of unit tests, which covers a lot of tricky aspects and places of our product. We need to collaborate with developers to sit up coding practices. We need to communicate with business analyst to verify and provide business requirements in advance. Each defect is a waste. Each neat defect is a problem. Based on information from box, we can improve our product quality, even result weight and conditional time. Based on Barack and issues statistic, we can define the Mozi boggy configuration and know what places should be a double checked and where we need to take a look deeply to understand how we can improve our court quality. Debugging under the most popular configuration means that sometimes we can find out that we have no marks in Chrome or Firefox browsers, but the same features doesn't work as well as we expected in the Safari browser. It means that we do. And develop new features in. We need to fix the issues in Safari browser requirements is it biggest problem? And Ben, of all projects, it's very difficult to know average cynical. It shouldn't be done and don't miss any pieces of requirements or it should be implemented. We can quantify requirements in advance. Find all tricky places, communicate with developers and testers and to find out what should be improved, what can be improved, and what places shouldn't be tested. It can help us to prevent developing good features which do not bring Ka value for users. The next one was important is copper complex areas to be tested. B unit tests or automated test during development. And we know what are the most important. Ndi can dramatically affect users. These critical areas should be tested with unit tests created by developers and automated test doesn't work as Apache. You can refactor it and improve these places of court. Another approach, how you can improve quality, it's using production data. You can use data from production to analyze order was wrong and it can be fixed at different logger systems can help us to find out which parts of our application are used most frequently and do have some bugs, errors, or warnings. Bless of CT and then analyze them and improve if needed. Quality in a team work. What we need, it's requirement analysis. During a sprint, we have a couple of very important meetings such as sprinter grooming and Sprint. A Sprint grooming, we can analyze a task or do we need to implement asked questions about Mars? We don't understand how it should be implemented Y to be implemented. And maybe there are some tricky parts, or we have some walkers and we can start doing this task. And the sprint planning helps us to understand which does shouldn't be implemented. How should we position to be implemented and implemented during this? And the other part is risk analysis. Do we have some risks in developing this task? What can be done wrong, or do we have some problems during development? Also, continuous integration and continuous delivery pipeline. You have such pipelines on the project. If not, we can communicate with the team of developers and we can define what by applying steps should be added, which tests or another steps we can add to this pipeline. It's important step during the process of improving quality. Another option is a decimal pyramid, which covers all of different types of tasks. Let's take a look on this barometer. We have three layers. It's unit tests, service desk, and user interface desk. During the regular decimal permitted the biggest number of tests, unit tests, while it does more stable, cheaper, faster than other tests, these tests are written once and real mathematical Iran after each mesh request. Also unit tests. Tests help us to create more testable and stable. It means when you create a desk for a court, it tried to write the code more readable and Marshall were either in supporting can't maintain income. The next layer is RPI Layer Layer and user interface layer usually is a number of these tests are smaller because of it takes a lot of time for development and the support. Also these tests can be run on each request or magic into the main branch. We can run that as, for example, Satish desk to Henry deployed new rationality. And user interface tests can be run once a day or once a week. Usually it can be run nightly when nobody is working on the project. So Huike raise these tests. Usually tests are created by developers because of the creating main functionality. They knows how it works and it's easily to add unit tests. Also, they can communicate with us and get all Desk cases it should be covered are the I and the UI test usually are written by automation testers, but sometimes they're created by developers. On one of my project. I created, I was a developer and created the UI tests. It was one of the practice of this project. How did we test a broader during a sprint? So usually after planning, we start development. Development, we deliver features or we are causing tasks, visa, functionality and, and that's simply the stars. In the same time we're testers stars, their work during development. Even right now we have no software which can be tested, but that's just kind of create some requirements, documentation or test cases which shouldn't be covered. And Zan when we delivered the first package of nationality, they can start testing exists functionality. And after we finish delivering features during a sprint, does this needs some additional time to test the latest feature we delivered and then they can finish destined during a sprint. So how can testers help developers in development as yours can start creating automated tests even before called delivery. It means that when we have requirements and they can start do test based on these requirements. And then we will implement functionality which shouldn't be destined by this automated tests. Important part is the sharing checklist in at once developers has some test cases would shouldn't be task-based on requirements. And developers and QA scan describe, discuss what should it be implemented, how it should be implemented, and then the product. We'd go mountain basins, this checklist, the requirements. Sometimes they can review unit test to to provide is absent, which will be implemented, was implemented in this salt for sometimes for development we need some data which would be generated for specific cases and dancers or QA can help us to provide the specific data with other parties defined boggy components and configuration. Developers can to know average decompose a broad coverage works in all cases. In this case, testers can provide some buggy companies and configuration wherein you spend additional time to do it better. How can developers help testers? The most important feature is delivered core frequency. You finish line feature delivery it and deserts, we'll test it was actually implemented as we expect. The next one is develop some mocks. It can be a marker responses from the server or something else. Developers can add any control ideas to the product, for example, BDD texts or another text in the corner. We can extend the logs to provide additional information and data to develop the testers. And the test data generation developers can provide information about impact of code changes based on the requirements, what should be added or changed. We can provide information how long to implement new functionality or implement these changes. Do recap. Collaboration between developers and testers can help us to improve our code quality and as a result, improve our product which brings a bigger valid to business. So there are different tools and techniques that we can follow to improve CTE qualitative such unit tests des inquiry and using a factory with time during a sprint. 14. Functional vs Non-Functional Testing: Hello. Usually when we talk about testing, we discussed different approaches, techniques, tools, methodologists. But why do we need so many terms, so many beautiful war to describe those phrenology and testing, that subject works proper. Usually, when you talk about testing, we'll talk about mono functional task. What is functional testament? The term means that functional decimal is a quality assurance process and the type of black-box testing that bases its test cases on the specifications in the social component under test. Usually when we talk about functional testing, but talk about men or what? A lot of options we can describe this testimony, for example, approaches, doing it just started investigation in some software or we need to test the main focus area. So it might be regression or domain brochures, levels, how many tasks that we need, and how did we go. In this case, you can have, for example, smoke or critical tests. Type, what specific type of tests we will choose to deal with specific possible issues and disciplines are talking about nano or automation testing. When do you look in different application? Sometimes it's very obvious is it works or not. But sometimes we need to go deep, investigate some approach, some parts of application and fanout is it works really ASU expected or not. And we talk about different types of test, different type of functional test. Each of them points to different types of conditions when the application can work or not. Returns how functions work and how are they working together. Non-functional tests, however, is also important. We does not function works or not. Here it has all. These function can work in different conditions with different environment, with different input cases. The main well-known types of non-fossil testing, usually it's security testing and performance testing. In these cases, we kick, how good is our application security and how many users can use our application simultaneously. During a non-functional tests, we do not need to take a look inside our application. We need create some specific environment, specific cases outside. Take a wide, wide range look and understand can now application work in this real life environment? In this video is just a first look on non-functional requirements destined. We will go deeper in the section about non-functional requirements in this course later. This is just an overview of approaches. 15. Manual vs Automation Testing: In this video, we will continue talking about manual and automatic testing. What is batch and which type of testing you can use in different stations. So I can say is that most types are great and you can use area of them where you need, or sometimes you can use both of them and it's the best choice. So talking about different approaches, usually we show process of this approach and try to award cones. Let's take a look on process of manual tests and why do we need it? In short-term perspective, it's really costs because you can get the person and just in a few hours it he or she can start passing again. It will get with some results and you will get already tacit application. But from a long-term perspective, it's not a good idea. Each execution is slightly different, so different persons can dust your application in different way and you will get some randomized result. And it's a great because of different persons in different way and they can get different errors, different problems which you can solve and improve your product. Additionally is a grades at different small or big changes don't affect potassium approach. Even your environment could be completely changed to program interface can be changed absolutely about real human being person can continue testing it without any problems or blockers and does a lot of different processes for manual tests. And you can find it on this slide. The next one which we can cover, it's a cons of this approach. And the manual testing is a real time-consuming in case if you walk in with a huge project which developed by a huge number of people and in time it's monotone project. Malmo testing will take a lot of time because a lot of different pages, components and the different test cases should be covered. So manual testing in this case is, isn't the best solution. Not all tasks can be covered by human and performing manual. Additional why we have such a big product project, it's difficult to do the same time. All this and all is when you did some changes. This way it becomes more inequality tried to repeat the same and the same task. And again and again, additional, you can miss some parts when you do the assignment. Our time, in this case, it will be less accurate than automated tests. And let's continue with automated estimate. So strong side, it's coastal factor in long term. As we're talking about the same a long-term project, we have a lot of different parts, components, pages is much more effectively to do some script which will run your tests for all changes in your application and you can run it as often as you want. And he said, this test will be repeatable. You can repeat them again and again to get the data and get quick feedback after my task provide quick execution and you will get a quick feedback. It is run automatically without involving human, you had additional time for another task you want to implement or improve some CT or some tests. And of course, you can improve speed of execution these tests using sounds, for example, parallel execution, by running a part of tests on another machine which will improve and increase your speed. But what about weak sides? This approach is to rely on contours and if you change assumptions in your code, you need update your tests. Because of this test can, can don't work with new environment or changes in your project. Orthosis tools have some cost even if there are open source. You need, for example, a Sarah way where you can run this. And you need to buy some server. Additionally, there are some limitation. That's why when you change something or you need to add some specific tests that not all tools can cover your requirements. That's why when you start using automation tests, you needed to work in details. What tools are you going to use because of? It will be long-term cooperation. And in case you have some requirements, which is these tools can uncover it will have some problems in the future. Additional automation testing is not suitable for all tests genotypes. That's why you need to use manual testing. Angela's compare best best choices for each case. For Meno testing. It is a best case form when you need to test the usability and for example, accessibility because of automation, tests can cover such sparse. So manual testing is a great option for testing feasibility and usability. For example, at mesh intestine can cover such things because they are orbits and do not understand what is efficient and usable for a real person. At the same time after mesh intestine is a great approach for regression testing when you need to run your tests over and over when you change something in your application, in your source code. Also is a great ocean for load testing because of and Cantor on 1 million tests during one small period of time. And automatically desk is a great option here. And four repeatable execution when you need to run it again, again to get feedback. Difference, what was changed during this runs? So as we cover it here, two options is automated amino tests unit and the best case you can use them is using them both on your project. Manual testing covers some parts of our application, automation testing covers another. And as a result, you will get as good as possible test your application with the best result for you and for your business. 16. Testing Approaches and Techniques: We've already covered as a difference between manual and automation testing. And now it's the time to apply these skills on practice. So hotly applies is on practice and boost our performance. Let's take a look for a pattern but can testing and in the same time they are. So difference are some Meno and automation testing. So when you talk about from ten tests and usually we talk about user tests in QI and UX testing or acceptors have user works with this application. And here we need some real user experience and opinion. When we talk about back-end testing, we talk about data structures and algorithms, about using these algorithms. And here we need automation testing to cover all this huge amount of data for backend, automation tests are more stem because of they using the same data and can be run again and again to get the same result or get some difference and compare increase front-end from ten can be changed to so often. And it's very difficult to do the use automation tests in for Dan because of these changes, everything please change require fast and in end-to-end perspective tests. And how can you be sure that this application can be used by people with results, special skills? And it brings us again to non-functional tests. And can we use this application if, for example, some component will be updated? Will it work the same as we expected or it will be broken. Affirmation and manual testing for by Canada and from tank can assures that altercation will work in different conditions with different input data and indifferent to Ireland. Additionally, what do we need to cover its mobile testing? When you talk about noble gases, we talk about diversity because of the multiple mobile devices on different platforms, there is different configuration, hardware and software, and a lot of different types of the software and disease platforms. Un, for example, Slovak mobile network connection can affect the users of your application. For multi-ethnic, you need to take a look and additionally test average. So what you can, or these different platforms for remote testing, if we can, cars next parameters, what we need to call it will be different platforms, devices, networks, operators, and applications on your, on your device. So we need to ask the hardware and software. And to do it better, we can use different tools for different perspective and for different types of tasks. You can use different tools for them, for web services, for BDD and performance tests exist. Specific tools you can use and boost your performance. And knowing these tools how they're worse, can improve your skills and showed you as a great expert in this area, flow. Take a look on this tools and choose what is a best specifically for you. 17. Unit Tests: What: Hello. In this video, we'll talk about unit testing. What is unit test and how can we use them to verify the correctness of application? We're using a different type of tests. It might be unit test automation does integration test, RPI tests, or user interface tests according to the typical Testing Pyramid, unitized are in the bottom of this pyramid and they found the biggest amount of tasks in the scope of application. So what is the unit test? Unit test is a test which does the smallest part of your application. For example, it might be a function or a class. You can test the Javier functional works with the input data and the you can expect some output based on this input. Y is, is good because of talking about tasks. You can talk about scope of deaths. And the biggest scope we have is the biggest number over computation, resources and time. We needed this when you try to run UI data, you need environment, you need additional computers because it runs a whole application to get what you need. And it's the same time unit tests they does. They can be around us. Small piece of your, of your application in some fashion. To run it needs some additional environmental or some initial compute resources. It can be run locally on your machine. As you mentioned, unit test is a test which tests your smallest part of application is fun to o or classes. Additionally, these deaths are written by developers because of they knows how application awards enormous requirements and that's why developers writing unit tests together with the court. Another requirement, they're easily run in ID in your integrated development environment, you don't need some additional steps to run it. It should be very easy to run in your idea. What is important that they should be very fast and tag does a few seconds or a minute. Usually I don't recommend you write unit tests which takes more than a minute endosome case, if you have a big number of unit tests, is okay, but your intention to be executed very fast, as fast as possible. In this case, you all run them often. And other requirements, they're easily integrate through your CI. And when you push some code to this error against integration will run and execute your unit tests on each commit you create. And it's a great way to be sure that your code works as you expect. So let's talk about the decimal based on this sample. We have a login form and we have a Destin scenario when user enters existing username and incorrect password and click the sign-in button. It was red and that result is rejected and incorrect username and password message is shown. So we have this scenario. To this scenario we didn't implement unit, as we can see, that unit test scenario will be hashCode of Passover is not equal to provider such good and as a result we need throw exception, exception Aurora. And here we can see that R1, R3 has is test scenario. We can implement unit tests which will implement these functional outcome. When we check passwords and correct, we need throws the exception. And here we can check, we can catch this exception. Also they wanted to mention about unit tests and for psi means end up firms. It's a great term. Example for where you can use unit test, e-mail or phone number, email or phone numbers. They have some special format which we can validate. We know that email has some requirements with special characters. And when you create Unit Test, it can check your validation of your fields. Ddc, user inputted, proper username, or email, or phone number. You can validate these number. You can create a function which checks all cases. Whereas Apple minimum lens. Maximum lens is the same password or is it the mail or is it a phone? Because of all these inputs, they have some format. You can roll date and check the principles in unit testing. Principles in your intestine. The great acronym forced the first letters means faster. So your, your intention to be faster than the it means you can run it as often as you can. And the venue did some implementation or Tange substitute q can run your tests in your ID and get fast feedback was something broken or not. In case unit tests requires more time, it will be lazy to run it for you and the US keep running unit tests on each change. So fast is important and another one is independent. Each international independent comparator with another does. It means that each unit tests written appropriately and the tests, and what do you need and any changes on outside shouldn't affect your unit tests. So you can see which tests in different order and each of them should works as expected independently from a nozzle. Does. The next one is repeatable. You can run the unit tests on your computer or CI server or production server or some other sorrow. And always it should do the same and return the same result. Let oneself all data-ink Sappho dentist means that result of unit tests should be false or true. Was your test past or not? You do not need to read some additional logs or complex output. You just need to know what was your task executed or it pairs and you need to refactor unit test or CTO and time. It means that intentionally be written before production CT. And if you need to refer to a record, you can refer to it. Your intestines created after you finished developing projects that they do not have any sense for your approach would because I didn't validate addressing. So it's the main principles of unit tests. You're going to fall during your development. 18. Unit Tests: Why: From the previous video, we know what is unit test. In this video we'll talk about why do we need these unit tests? So the obvious answer is to find and fix bugs in your court model in the same time in the test car was to do our code more maintainable with a time. So let's imagine that we're developing and calm tone project for a couple of years and ponds are beginning to know how it works. And we have known victim and skipping and dust by the time we need a refactor already written court, sometimes we don't know how it works or who created this part in case if we had some changes to our team. Additionally, in case you have some newcomers in our teams. They do not know how it was implemented to how it works and they need to change something. They afraid to break some another part of your quarter. In this case, it has to help you to ensure that your changes will not break. And other pieces of court or another part of application on the beginning garage and appeal court Louisiana test? Yes. It will take additional time because of your team have to lower your testing framework. Discuss unitized convention and try to follow this convention says why this beginning, it requires additional time, a bit more time. But later, when you write your code more and more you will refer to the record. Unit tests will help you to be sure that you don't break anything. Can your code and visit time. Development of cuisine or test will take less time than development comes RG and tests. Additionally, you can use unit test as a recommendation because of incision tests. We have scenarios when then and we understand how pieces of code works. It's a good option for newcomers who doesn't know how your code works. They can read unit tests and understand what shouldn't be executed and water result we are waiting. In your test code coverage is another characteristic you can use in development. We tried to cover all lines are rubber coated with the test and be sure that disease line work as we expect. But in the same time, code coverage isn't a primary goal of unit tests and it doesn't guarantee or quality, even if you're caught will be covered with 100% it want ensures that the Squad Wars, I suspect, because of unit S can be written badly and you'll CT can be designed to be low quality. So Unit Tests got coverage is a great option does to show you what pieces of courts were uncovered and you need to take a look on this parse of CTE and tried to refactor them or influence them. Additionally, code coverage we can use as a threshold in continuous integration when we create new functionality. And the push to continuous integration you can check, was this neutron star g was coverage busy unit tests. And if our threshold tours these new order, we need to create additional unit test to cover a new lines of corn and other produce. Very popular in development is that test-driven development Describe is the approach. We can split it into two parts. The first one, it's called driven testing. What does it mean if the first one we write the unit test, we write Dutch intent before creating a complementation. To write these unit tests, you need to understand requirements, what we need to implement high, which it works. And then we create a unit test that I tried to run. These unit tests always am fails and is expected result otter, that will create a third version of our court. It will be the simplest version of our code, but the main goal here is to execute the unit test and fulfilled this test so they shouldn't be past 20. We have passed unit test. We can start the next part of TDD. It's refactoring. We had the simplest solution. The solution fulfills the requirements. We didn't implement a Anniston conditional or valueless parts of code. We just implemented requirements for this feature and then we can refactor our code to do it better, to do it cleaner and you have to maintain a discord visit time. After that, we again run unit test and be sure that all our unit test will be successfully executed. There are a lot of additional tools and libraries you can use for writing unit tests on all computer languages has some tools for unit testing. For example, for Java, it might be JUnit or destined. Easy mock libraries. For JavaScript, you can use just Karma and Jasmine, and another tool you can use for different languages. So just to choose a best testing tool for your specific language and run unit test during development, your functionality and your programs. 19. Unit Tests convention Demo (JavaScript): In this video, I will show you a sample of unit test convention which you can use during development in your team, is at least offer items you need to kick and needed to follow during development and great completed tests. So the sample is great, especially for project could create JavaScript and special with React framework. But disease checklist you can use for your own project and updated or changed us. You need specifically for your project or neural language. What do we have in JavaScript and react? You have a precedential components and container components present national competence. In our case, it should be 100% coverage because they are pretty simple and it's very easy to color four container components that we not require 100% of coverage with you in task. For us, 80% is OK. Because we understand that it's difficult to achieve such high coverage and there's such benefit, it won't voltage. But for project test coverage, we understand that it should be higher than 80% unit as Convention to very similar Reza Khan style. Why? And when we create a unit test, we need follows the same Euclidean called rules as for creating our regular court. And here what do we have? We have a few items in our case. We described 15 items. How we should write our unit test. For example, we did declare variables at the top on the separate lions, we create a readable variables and all this variables are declared in the top of our tasks and we know what data do we have. Another one, it's how it looks to be good readable. We add additional empty lines between describe and before each sections now is called looks better. The next one that we initialize variables, Justin before each section. So in the top we declare variables and before each we assign values with this our mock data with some mock, mock functions. The next one is a groping, groped variable declaration. Here you can see that when we assign some values, we move it to one before each. When we create spice, removed two separate before each. And when we create competent, we mounted, we put it to the separate before each. In this case, we separated all bars and now it's much more easy to support and maintain in case you need to change something in a way you can find it and it won't affect and other parts of your unit tests. Or here's a second option where you can put afternoon 1-2 gas in one before each. But in the same case, where initialization and greater spice separated with empty line. And if you another option that we can use, what can be refactored to, what can be updated. Initially, if we have some function which will be executed multiple times, if you can move it to a separate function, for example, render and called. Why do we need in before each section, do not copy, paste the same code. And again, groping what's important when you describe your unit tests. Here, we have described the first one. We put Enter name and then we put the second section of Describe is described when should something occur. So we describe test case and that ensured starting with world, should we, we write what we are expected. For example, should do. Think. Additionally added edge, we don't use em empty functions. We are using a cleanup function from o dash. So all these items in unit tests convention helps us to implement and right, much more cleaner unit test, which will be maintainable with a time and you can easily read and understand. Additionally, all the sanctions helps us to do this more similar to documentation. When you can read, understand that something happened in increase these N3 item. Then we have described when we mentioned what is going on and we have a result, what should be done. So this approach helps us to create the renewable unit test, which will improve our code quality. So you can discuss it with your team or another teams in the project. And greater orange or unit does convention to create high-quality product. 20. TA Place in Lifecycle: In this video, we will talk about the place of test automation in the modern development lifecycle development. So to understand the place of test automation, we need to take a look into to most proper delivery models. Is the development first, it's the classic and task first and the highest organized. Let's start froms or development first mode is the classic approach where first we develop some feature than recreate the tests for this feature, it might be unit tests or integration tests or UI tests. We will implement testing option development, some functionality him comparing with this one, we can take a look on the next. Another approach is testing first mode. In this case, when we create test first and then we implement functionality for these tests. Test can be a unit test and in the same time it might be automation, acceptance tests, poplar approach here it's using TDD, test-driven development. Do you beat covered in the previous section? And here just, I mentioned that this approach can be used here. Tdd can be used in this approach to write unit tests or another task. First, we need to understand the requirements of what we should implement, how it should be implemented. Clarify all places in requirements we don't understand, or maybe we do not have requirements at all, then we can implement the acceptance testing implemented cases and after that implement. And Sinatra Jim, this approach isn't so popular because not everything can be automatically before development. This wire, The first one development Porsche is mosque more propor, it's easier to implement and maintain. How can the automation testing can help us during development? Let's take a look continuous integration pipeline and how it works. So we have a delivery team, team who creates a code and fix some bugs or implementing some personality. When they finished one part of chords, a great marriage request or poor request to version control system. It might be Gita or long version. They create mesh requester. Then our CI server will trigger our pipeline and for example, unit test run. It's a type of pipeline. Usually we have some automation, automated cotton losses before IT about them. Now we can skip it. So we will run unit tests and incase something was broken or we didn't implement functionality. Us, we should, according requirements and unit test. We will fails its test and get feedback. Immediate glimpse. And when we will get feedback, we can rewrite our implementation to fix some bug or implement what we needed to implement. And after that, we go to the next step. Again, from the very beginning, we deliver pressure analogy to version control system. After that. After that, we will have a trigger which will run unit tests for the whole project, all unit tests and in case airship was fine, we will go to the next step in our pipeline. It might be integration tests and then they will be finished. Then we go to the next step in our pipeline. And Ben, actually cause successfully finished, you will get feedback that all tests, all steps in pipeline, well past and functionality works fine AS expected without any problems using test information in continuous integration process is a great way to get immediate feedback and understand what's epigenetic implemented. Okay, do we have some errors or bugs? And do we need to do sums new conditional to fix the issues we might get. 21. TA Goals & Metrics: In this video, we will continue talking about desktop automation. First talk about goals and metrics. In estimation. One of the most priority and important metric and test automation. It's ROI, return on investment. To represent this metric has built a chart. It will show a dime. Horizontal is the time and the vertical, it's a cost. And the we will represent two functions. It's Meno Tetlock and automated testing. When we show manual testing, we see that it's aligned with continue growing over time. Why is going on? He's going on because of during development, we create a lot of new features and all these features should be tested in the same time during which the Triassic new features we need to test already created features are such type of regression testing to make sure that not as GWAS broken with a time, Meno testing costs more and more to show it as comparative with automated testing. We, when we will add additional fonts, Automatic Test we will seems as its ally, which grow in two, but not so fast. On the beginning, we need to spend more time to create a data environment rise, creeps, but with the time, we will see that it would take less and less effort to maintain our test environment. Automation testing is not a silver bullet, but it can save some time if you will use it in a proper way. Now, let's see how ROI is changing during the project depending on its duration. So we can see that we have three time points during the development of products. Usually how some short-term project, we will see that the manual testing, it will cost less than automated tests because often, as I mentioned before, we need some time for creating automation test tools, set an environment and write scripts. So on. Short-term projects, it won't be efficient. It will be a physician does on the margin more longer period, for example, in our case is n plus two. You will see that on this time point, we will get some benefit of using automated tests in comparative wisdom. Manual testing is really difficult to build such chart before the project was started. But to calculate the ROI, we can use the formula. And other important metric is a coverage. Coverage. It's a number or percent of test, men or test which had been covered activities of committed. We can try to reach 100% of coverage, but it's not efficient and costs too much to be the most efficient. We can implement the most important tasks and tasks which we can easy to cover with automation tests. On the chart, we can see that we can cover eighty-five percent of tasks and for implementations is desk between inches. 50% of costs investments. So it means that we need to cover the art 15% because it will take a lot of efforts to implement it and we don't need invest so much time. The rest 15% we can recover by Meno. And it will significantly improve the cost of testing our application. And please consigned resist number dust are some numbers because of on different projects. They can be absolutely different. These equation, how can we define what is most important and what do we need to cover? It means, how can we describe a scope of automation testing to find out we need one more chart, additional czar to act as a priority and the cost. And now let's consider every task from this perspective. How easy is implemented, the stat and the whole report important this test or this test, we can split into four bars, sections and put them to this special area. And then you can choose what is most important and cause lasts for implementation. And then we will choose this tests because Apple does from the first section, they are most priority and costs less than other. So we can start with Berman implementations. This desk that's from the fourth section, priority is less, much more, less about the implementation of this test costs a lot. So we can skip these tests and the color them by manual testing. Additionally, we need to remember that visit time, some tests can migrate from one section to another. Using this chart, you can choose what tasks you need to implement in the first place and they will help it to save some cost on project of automation, testing. 22. TA Tools: In this video, we will continue talking about test automation approaches and tools we can use it. So what was the main concept in test automation is destiny pyramid. Pyramid represents a type of tests for different layers in application. Usually, application can be divided into few levels. Let's take a look on this levers patrons, this designate pyramid. Usually it can't be components which are covered by unit tests. Unit as scholars, a smallest parts of our application, usually it's a functions methods, classes we can cover with us. Then we have some services. It's a more complex parts which require some a PI task calls to decant, getting some data. And the CRF level, we can describe its UI tests when we have the final view of our application and the user scandal and goal, pages clicks on buttons and interact with our application. Time for each level is increasing from the bottom to top. For example, UI tests. They are most time-consuming. Usually can spend a few hours to for writing a query UI test, and it will be executed a couple of minutes in case you have a lot of tests. It can be run few hours from my experience, if you had Udacity took more than 20 hours who are running to go for all pages and we have to run it on the nightly basis. The next level, service or RBI does. They can took last times and UI, but anyway, it can take us an hour to write a test and we need to make some calls. And it's a middle level or level of time-consuming task. And the bottom layer, it's a component or unit decimal. There are the fastest because of writing a few thousands of unit tests, usually should take a few minutes. And if you have a few hundreds, it's very good if you can write less than a minute for all tasks and what tools we can use for each layer of deaths. For a component tests, for unit testing we can use XUnit family and tools. Usually it's J unit for Java or an unit for the NAD. All these tools are open source and you can use without any restrictions. For service static, we can use rest assured or as sharp tools. And for UI tests you can use Selenium WebDriver tools or a night watch. There's tool for testing. It's a return different languages. Also, if you want to test the mobile application, you can use RPM, its open source tool for mobile, native and hybrid applications. Additionally, with open source tools, you can use commercial solutions. For example, HPI, unified functional testing, radii or task complete. These tools are commercial, but anyway, you can take a look on them and maybe a really useful for you. And let's take a look on the most popular framework. Apologies that we can use. The first one, it's exceeded family tasks. It's usually a unit test you write in for our application for the smallest parts, functions or classes. The next approach are totally is a TDD test-driven development. When firstly, we create tests, unit tests for our application based on requirements. We have enzyme. When we understood how it works, how it should work, what do we need implement? We created, tested and will create functionality to run this test. And when they test our past, we know that we implemented arsenic, what we needed. After that we will refine for our code to do it more readable, cleaner. The badger in maintainance and other similar approach, its acceptance test-driven development. In this approach, team collaborates to write exception testing befores in writing functionality of our obligation. The next popular framework is a keyboard driven development. In this approach, tester's bill covers and can be put in different approach in different order. And z can be used to estimate without programming background. The next pop or approaches behavior-driven developer. It's, it's a bit similar to test-driven development, but the test cases are written on a special language, Dworkin, which is English similar language. This language is easily readable by developers, test automation engineers, and what is the most important is easily written by business people. You do not need to have some programming background to use this language. And that's why business people can contribute in development tests using this approach. And one of the most popular framework is that data-driven framework, which uses data as input. So beta on different input data we can get different results. For instance, if we create application for social insurance or some other type of insurance based on input data, it's age, salary, previous accidents, we can get different result data. So each test case can be run multiple time series, different input data and resort data. It will be an Asaro. Last approach we can use, it's a hybrid frameworks, is a framers un, we can combine different approaches. For example, we can combine keyword driven with data-driven approaches to get some new results and do our destiny more efficient. This approach allows us to get the best from each approach and do our work much more efficient. 23. Performance Testing: Hello. In this video, we'll talk about non-functional requirements. Non-functional requirements describes how a system works. While Functional Requirements describe what system shouldn't do. The most important non-functional requirements are performance, security, reliability, maintainability, usability, supportability. They are the most important. And if sound was lambdas quirky or application can be broken and denote work as you expect. So these are the most important. And in this video we will talk about performance. What does performance is a property of the system which indicates its ability to be a powerful, fast, scalable, stable as a required performance is, first of all, it's a response time and time which needs a system to respond for user request response time, some measure how fast the system is. Capacity is a highest Vandal offload the case the system can handle without increasing the response time and decrease instability. This is a measure of how powerful this system is. Stability, property of the system, which indicates its ability to maintain its level of operation. Scalability, property or the system which indicates its ability to be readily enlarge. It means that capacity of Ideally scalable system should increase as fast as powerful system resources increases performance testing. It's an iterative process which typically starts from engagement planning, which includes collecting Requirements, built-in test plan, chosen approach, metrics and tools which will be used during testing, also became scenarios and workload, writing scripts and collecting resources. The next step we're going to prepare on system we need prepare, testing data, build, and prepare tectonic environment, right? Testing scripts and scenarios. Now, we go to the search step test. On this tab, we need to run tests. It means dust execution. Then collect results and start monitoring over these results that we can go to them. For. Step number four is analyzing. On this tab, we can analyze performance issues. Also. We can compare result numbers, will requirements, and we can correlate observations. May be you need to change some smoke. After that, we go to the step number five, its report. On this tab, we can provide some recommendations and to prepare test results report. And there is a fixed tune step is not required and sometimes you can message, but on this tab, we can do some Court fixes implements on profiling, or we can reconfigure our hardware. Also, it can be used for web apps, Eric tuning or database tuning and redeliver. Because the final step is delivery. Van, we prepare a final report with recommendations what should be improved from performance perspective, this takes you for all of these steps in more detail. In the first one, it was, it started from engagement plan. On the engagement plan, we need to collect all requirements such as response time. Normally. Load, common traffic patterns on the scenario greatness tab, we can define what virtual users we will create and how we are going to yield them. Also, we can define what tools we're going to use. It might be open-source tools free or some commercials tools Authors at, when we codify some metrics that we can create, develop, and test script, it escaped to automate behavior of our virtual users. It looks simple, but a lot of heat and mistakes. And let's try to find out how we can award such mistakes. Very popular mistake. Incomplete requirements is very important to define final requirements. So what we are expected, for example, response time two seconds for a page. It's a good for high level management to learning. But in real lifetime we need clarifier all cases when we want to achieve. Next one is unrealistic load model. We need to know that when we run functional tests and functional tests and IQ and performance test is absolutely different. And when we run unfortunate destiny, we can get one results. But in real life test cases, we will get another result. So we need to be ready for such difference. Different tools are better for different purposes. So it depends on what you're going to test. You need to choose a proper tool for the specific area. These tools requires specific knowledge and they have advantages. As disadvantages, selecting the right can have significant impact on the testing process. And S1 is test preparation. Test preparation collects all steps or building a test environment, preparation, testing data, right, and scripts and scenarios. Be sure that we will test arrogant properly. We need to create a copy of our production environment and run all our tasks on the same copy of environment. That means that we need the same network sam, database capacities as Sarah, operational capacity and correlation capacitor. It's a big problem where we are habitats and environment, some small computer BAD design when we're on, on production environment, we will get some arrows, problems. So the best-case is when you have a copy of your classmates environment and run Zara tests. Testing mechanical action of test results. Step became when does environment is ready and deaths, scripts and scenarios are written. Destiny includes test execution, monitoring, and the collection of results. One propeller mistake here, when we monitored just one aspect of performance testing, for example, login or this system. But it's very important to collect all other information such as memory usage, CPU utilization, network traffic, and all other aspects which can significantly impact your system. A little bit generator, it's a machine which runs your testing scenario and they are part of the system. So just like a collect performance measurements from the system in age, collect performance measurement from the load generator as well. We needed to detect its status and define all possible bottleneck in this system. Next, we tried to analyse the test results. On this tab, we need to identify all performance issues, compare our numbers, visa requirements, and correlate observation, and do the last step is reporting other apportioning. We can provide some recommendation or to be changed and repairs. A final test results report. You need to understand what exactly you are measuring all your new ways to entrepreneurship. 24. Security Testing: In this video, we will continue talking about non-functional tests. And now we will talk about security testing. I just want to mention is that in this presentation we will told us about web application only and therefore security desk Animal Biosecurity test and are out of the scope. So what is an application security? Application security is a very general term. So we will try to go to fight for the simplicity. We will tells us Application Security testing is a set of activities focused on analysis and testing the application for security vulnerabilities. There are three most popular approaches for security testing. It's a static Application Security DESERTEC assessed, which is focused on analyzing the application source code and compile the source code for security vulnerabilities. There is dynamic application. Security testing desk is focused on simulating attacks. Again, running a complication and interactive application security testing, highest combination of sassed and desk. The main idea of interactive application security testing. It's to culminate all benefits of static. The dynamic security testing approaches and improve the overall quality of test Nick results fast is focused on analyzing of the application's source code. The main purpose is to identify security vulnerabilities on the first steps, the most proper after mattered and semi automated static application security testing approaches. In this case, it's a special tools which analyzing your application source code or application compiled source code to identify and find out all possible security vulnerabilities. Such tools can be integrated into our development environment to prevent developers doing such errors and issues during development. The pros of this approach, One of them is it's very good for different programming languages. It can be run fast for your court and find the all issues additional. You can edit our step two, continuous integration and continuous delivery pipeline, and it will be run automatically round dueling continuous integration process. The next one is a good for finding certain types of vulnerabilities, such as SQL injections, cross-site scripting. For example, hardcoded the synchronous courts or password in your courtroom. Additionally, this approach can provide a good report, but in the same time as are a lot of cons. For example, the high number of false positive results, not all issues can be fine automatically, such as issues with authentication, access control, session management, multi-step issues or obligation logic. Also, it can find the different configurations issues which are not represented in the court. And now US talk about dynamic application security tastant. It's a tactic which is performed against the application of any ceramic. Developer tries to simulate a tugs on the application based on his knowledge, housed application works and how it can be broken and stroke about two different types of such tests and which are aware offer confused is vulnerability assessment and penetration testing, vulnerability assessment approach when we tried to find as many vulnerabilities in the application as possible, but do not exploit them. During this approach, retired to identify issues during the prioritized list of issues, the penetration test has a specific goal. During such testing, we can find one specific vulnerability and exploited to reach the goal or this test took. The next difference is that vulnerability assessment can be automated. A lot of tools which can be used to identify, well an ability issues in the Colt and recognize us vulnerability assessment testing. This new approach, interactive application security testing, which combines static and dynamic application security testing. The main idea is that a special piece of software usually caused a salt for agents can be added to your software application. It allows us to connect different applications and security events. The different process OSes approach. For example, it reduces the number of false positive results. Also, it has better caught covers because it can analyze code during execution process and it's the same time. There are some cons of this approach currently, not all lambdas are supported depended on the solution. It might take a lot of time to configure, to, to work properly. Now, it's time to talk about classification of risks. The most popular is from OWASP, Open Web Application Security Project Lead Program is a prioritized list of most critical about application security risks. The first one is injection. It's a general term for different types of attacks, is a common term for all injections. For example, a scale or nanoscale injections. The main idea set is a hacker puts some comments, some court insert fields for fields and design. This code will be executed by the application. Second is broken authentication and session management. Very often application of identification functions are written, not very good. And it allows to compromise passwords, tokens, keys of a user. The third one is sensitive data exposure. Sensitive data usually is saved in database and had to be hidden from the user. Sensitive costumer application data shouldn't be exposed. The next one is XML external identities. This is an attack against a Web applications as parses the XML input, this input can reference an external entity attempting to exploit a vulnerability in the parser. The best way to prevent such attacks are to have a web application except they're less complex dipole for data such as disown or at the very least, to patch XML parsers and disables the use of external entities in z XML application. So next one is a broken access control. Access control refers a system that controls access to information or functionality. Broken access controls and loss attackers to bypass authorization and perform task AS those Xj are privileged users such as administrators. For example, a web application could allow a user to change, which are cause they are logged in, as simply by changing part of URL without any other verification, access controls can be secured by ensuring that a web application uses authorization tokens and thus dof controls on them. Number six, security misconfiguration. Securities configuration is the most common vulnerability on their list and is often the result of using default configurations or displaying exclusively verbose arrows. For instance, and application could show a user overall descriptive errors which may reveal vulnerabilities in the application is can be mitigated by removing any unused features in the court and ensure exact error message are more general. Number seven, cross-site scripting. Cross-site scripting vulnerability occurs when Obama application allow users to add custom code in a URL path or into a website that will be seen by other users. This vulnerability can be exploited to run malicious JavaScript code on the victim's browser. For example, an attacker could send an email to a week term that appears to be form of trusted Bank. We visually to the bank's website. This link could have some malicious JavaScript court tacked onto the end of the URL is the bank side is not properly protected against cross-site scripting that malicious code will run in their victims were browser, was the user click on the link number eight, insecure deserialization. This thread targets are mainly a web application which frequently centralized, decentralized data. Serialization means taking an object from the application code and converting them into the format that can be used for another purpose, such as storing the data to disk or streaming get. The deserialization is adjust the opposite, converting centralized data back into the object. The application can use. An insecure decentralization exploited is the result of the digitalization data on trusted sources and can result in serious consequences like those attacks and remote code execution attacks. Number nine, using components with known ruler abilities. Many mandrel web developers use components such as libraries and frameworks in their applications. These components are pieces of software that help developers avoid redundant work and provide the needed functionality. Common example includes runtime frameworks like React and smaller libraries that you use to add, Share, icon or AB testing. And number ten, insufficient, organised animal, toric. Many web applications are not taken enough steps to redact data breaches. The average discovery time. A breach is around 200 days after it has happened. This gives attackers a lot of time to cause damage before these annual response. And now let's briefly take a look at the methodology. This can be used for security testing. All WSP testing guide is a guide which you can use in your team for the Ashaninka application, for the most popular web application, issues. From security perspective, if you are looking for a checklist, you can use in your team, you can take a look on this or WSP decimal guide, BTS, a detailed description how penetration tests should be performed. Open source security testing methodology manner, it's very good for big applications. Next one, information system security assessment framework. It's too for a big project and for big companies. And the last one is technical guide to information security testing and assessment. During security testing, we have some typical goals and approaches to simplify our work, we can use the following phased approach. The first one is preparation phase. On this faster we can clarify some restrictions, clarifies the scope and the contacts information gathering. During this phase, we analyze of different of donation sources, foreign blogs, social groups, social networks, and different other sources without ability, analysis and exaltation, together with automated testing, basic manual testing for finding security vulnerabilities reported on this tab, clarify all found vulnerabilities, security vulnerabilities, and provide the final report, presents the report stake holders, make sure read it and understand what was written there. Now, let's talk about tools which can be used for security testing. There is no tool which can do our sink. It means there is no silver bullet you can use for all cases. Some of them are open source and free and acinar commercial and the need to pay for them. But you can choose what is better for you. And 2-3 can split into two different areas, is scarce and proxies. And each of them is related to different desk approaches. And what also you have to remember that security testing is destructive from zonation to be sure that you have all required a Bruce and optimization to do such testing. Make sure that you discuss to visit your project managers at your going to start writing such tests. Before starting, you need to provide a list of plant activities or do you go in to do war unbarred possible risks. Make sure risk are accepted. Don't forget to get a written permission to perform such tasks. And all this amplifier when testing stars today is very important to be aware about the non-functional tests, unique and special about security. To ask him, how can you save your data and sub-issues that nobody will still? Your important information. 25. Software Release: Hello. In this video, we will talk about soar through releases. What is a process of Salzburg earlier, we will talk about source for release of the software product. So let's start from the definition. Product release is the process of launching a new product for a specific market or user base. And one was the most important parts, OZ cirrhosis and salt. Bernoulli's salts for release is the process of delivering IT functionality to production. It means where fish development of a sulfur we built averaging together, corrected is data and through the pipelines, we deliver it to test servers than to stay chunk servers. And after that, when delivery to production environment and, and users can take a look and start using pure product to print the maximum value for a business, we need to plan all releases, how we're going to deliver functionality to end-users. We can take a look on different release cycles. Usually there are two types of cyclists, shortly cycle and go on curly cycle. That's comparison and find out what is the best special for you. Shortly cycle is a great option. For example, development websites, where you need implements our functionality and deliver it in a short time. It allows you to be a dial and it allows you to change the functionality in your site very often and get feedback from the end-user. And if something happened, you can update again. Usually such updates can be happened on a multiple times a week. To do so, awkward, you needs after measure of all processes and aspects. To do it, you need to continuous integration and whole-steps shouldn't be automated and run on this condition, a gradual process and automatically to be delivered. And that's what is important is analytics and monitoring. You need to collect all data after your release and in case something happened, you can roll back to the previous versions and fix them, fix the version, and then update your product with a fixed version. Additional What is importantly, personally for developers, development tests and echo or deaf testing. And they're testing is a process van developer who created with rationality or some piece of software. He or she showed the test it by himself or herself. And when everything works great, the anode will deliver it to test environment, test that two-stage income environment is causes environment to production and banners and cross task that you, we can deliver it to production where we check analytics and monitor how it works. And if Erickson Kesher k, We can leave it in introduction. Additional benefit of this approach is that you can skip a QA's in your team. Arsenic was automated. And using short releases, you can leave developers who will test their functionality and then deliver to production. The next cycle type is all grilles cycle. It might be a more than six months is this approach is good for soldier is very difficult to deliver. For example, if you have a car and say some software in a car, or you have satellites, or maybe some magical staff and it can deliver functionality very often because of we need to, do, you need to have some strict processes. Check are pursuing a double Tacitus multiple times on different environments, different stages. And then when you double assures that actually works fine, that you can deliver it to the stage where you will test it and after that to production. As we have a lot of production, although we will have a slope print back, it might take on a lot of time to get feedback. And sometimes when we get to sit back, it will be too late to do some faeces or some improvements. On this slide, we can see a sample of release cycle. How is going on from the beginning is collecting all requirements, analyzing them and for delivery to production. The first step is collecting all requirements are what we need to implement, communicated with business, get all necessary data. And when we have Azure unquote, we need or at least some minimal part. We go to development of ant developers implement this functionality, take greater CTO. Here's step. Using dev environment usually is developers computers. When we finish some functionality, fix the bark or implemented a subset, we can deliver this functionality to test environment. Usually static environment doesn't environment, it's a simple low weight computer or machine that can be simplified and didn't have such power AS statute or production. Initially, you can mock or stop by any dependencies or models in this environment. Testers will finish quality assurance process, will check arsenic. And if Ashaninka k, we're going to go to the next step is delivering this functionality to stage and environment. Statute environment is a causes to environment to the production is a good case when staging is as good a US election and with the same machine sends the same hardware and software. Attention environment is the last step when we can find all box. We'll test averaging again. After that, we will leave it to production and production environment and the users who will use his production and can find boxing production and what is not a good case. But anyway, you will have some analytics animal editorial tools and can find disease box and revert all changes, fix them, and go step-by-step again to launch one very important requirement is tap is fulfillment quality gates. What does it mean when you have different environments? The intestine, for example, to go from one environment to another, we need fulfill some quality gates. We already talk about. This quartic is usually the unit tests through some code coverage, threshold or automatic code analysis. When all these tests steps will be fulfilled, will be passed. You can go to the next step. And for each environment going for one to another, we have specific quality gates we need to fulfill to be sure that the average sink works fine. We didn't miss subsidy and forget to any important step and is green in case raisins, amplitudes, progression between its delivery tools. We can go to the next step is important because of fixed and embark on the latest stages. It's much more harder than on the previous stages. So if you have some bug in their environment, you will fix it in a couple minutes, for example. But foreign production, it will take more time to do this process fast and automatic way using a continuous integration process. For example, we can see that there are different steps for continuous integration. For example, wearing finished our development, we can push our code to a source repository version control system. When it will be built. After that, we will err on unit tests for example, or integration tests we have. And on the steps that we will pass our quality gaze, we will be sure that the tests are passed to add functionality is implemented as we expect. It's continuous integration process. Next one is continuous delivery and continuous deployment there where similar, we will talk about content delivery on this slide and about continuous deployment on the next section, where we pushed our functionality and the finish building, run all the unit tests, integration tests that we can deploy it to staging environment are true that we can then rather than ACS tests. For these tests, we need a real environment. Upside to lungs is replication and try it. And ultrasound, we can deploy to production. We can do it manually or automatically. And very we deployed it, he began on some initial smoke tests. This approach helps you to deliver functionality of your website, of your software product to the end-users and against the veil for a business as soon as it's possible. 26. What is Continuous Integration: Hello. In this section, we will talk about one of the most important practices of development is continuous integration. We will talk about what is continuous integration? What is contains digression prototype and which tools we can use to build this continuous integration. And the most important, I will tell you why continuous integration is so important. Why do we need to learn this practice and spent time for integrating it into the project on our team. So what is the continuous integration? Let's imagine that you have a project and you have some tasks to him for implementation, implemented some task and you want to merge these changes into the main branch, main source. And you need to be sure that your change doesn't break any else in your application. So how can you assure, Of course, you can check your code manually. This is OK with your code style guidelines. Then on reveal double-check if epsilon was implemented and whether you will marriages core, main source, you can check the whole site and check arsenic works or not. But what are you going to do is a site will be big, very big, huge, and you don't know how all part works. To solve this issue, we have continuous integration. Continuous integrate its development practice that requires developers to integrate their court into a shared repository several times a day. And what is the most important that we have verifications that built was built successfully and we didn't break anything. How can we do it to be sure that arsenic works fine? We are using different tests which automatically RR on any changes reimplemented. What do we need to remember? It's a practice, developers practice and we, as a good developers, as a top rated developers, we need to know what is contingent aggression and how can we use it. The main principles of continuous integration, as I mentioned before, it's a process, process to check integration of any code changes from any developer into your main line, we need to be sure that lesson cause broken and we don't break anything. And adding new functionality and added new features. Also, it's important for a new bars in your team. If somebody arrives 13 and here she does know how our application works or parts they have and they afraid to break Samson is important. Also, is important if you're doing some refactoring of your application. After refactoring or a new chance, thompson, You need to be sure that eugenic break and asset. And how can you do it? You merge your changes into main court or an old tests. And in the end you have feedback was absolutely best ok? Or you break something, you can, you need to fix it. The next one is, every change must be integrated into credit. It means you have main source, main line, ct, and EG, some changes and should it be integrated to be sure that you didn't break and arsenic and was the most important, that all of this process is automated. So you have Automatic static analysis, court integration tests running, and unit tests running. So after each step of your pipeline and will be run automatically, you can do it manually because of a lot of steps and for all changes you need, you need to run this test. And it will take a lot, a huge amount of time. This is automated. And does this approach allows us to catch box as early as possible. So when it just created a push on the first step, you will get the result of your unit tests or integration tests or any other tests you have. And you will know that arithmetic works. Okay? So let's take a look on the prototype, how we can organize our continuous integration process in the team. First of all, communication with people, with a team, with management, the stakeholders. We need to know what do we need really? We need to get information about current process we have and to find responsible people who will implement it or who can provide some information. The next one, we need to find out the best tool so we can use. I will show you some tools. You can take a look on these tools and why they are important and useful. Where we have to we can design our architecture is all steps by pipeline, run all our tests, uses convinced to question, and then we will have feedback. So what is continuous integration pipeline, the most important part, pipeline, we haven't a version control system. It can be Git or GitHub. And we have some changes. We create push request and is a trigger which triggers the whole pipeline. We create a build, we run unit tests and integration tests. We run automated court style chicken tools. And as a result, we have some reporter is data was absolutely fine or something should be changed. And let's talk a bit about tools you can use. One of the most important and purple R2 is Jenkins, then it's continuous integration. Y is Jacqueline sopra laurel. First of all, it's open source. It's free for users. You can use it as you want. It's not a problem. Additionally, it has more than 15 hundreds plugins and you can use them because Jack is itself is easy and empty too. You can't do a lot of things, but you can extend your disability V This plugins and what's important, it has a big community. You can find all answers for all your questions you will have. So let's take a look why it's so propor, Okay, let's open JetBrains.com and we will get information. It's a survey, the most popular tools. We can open team tools and on the first place, which continuous integration system do you regularly use? You will find out that Jenkins, or the old name hot sun, is on the first place, 59% of users using Jenkins. So it's a real popular two main site is this one. Jenkins to four contains integration. The second place is MATLAB ci, eclampsia. It's another tool. I use it on my previous project. Additionally, I use Jenkins and of course, and MATLAB is really great to do. And you can take a look. The next one, it's Travis CI. I use it for my own project once. Real interesting thing and the Circle CI, circles, I'll see I, it's pretty new to and we are using this tool on our current project. Very interesting. Two, you can take a look as Jenkins is very popular. I can recommend you my course, free course of Jenkins, Continuous Integration with Jenkins. You can take a look and learn how Jenkins works. And one more to its atlas and bamboo, it's a tool for contains progression as well, but it's not a free, completely free just for open-source three by four Enterprise project, you can, you need to pay. Benefit of using these two is that it has a great integration with OT Lawson tools. So if you go to Analyze and.com, you will find, although they have such a general conference and these two will have a great integration with all these tools and they sitting city. Another powerful condition integration tool from the box and it's free, free forever. We cover the most popular tools for building Continuous Integration. And now let's take a look on some tools which will help you to create a BWT which will be run on us step by applied in continuous integration. The Ummah support tools such as Gradle, Marvin apache at Andover park. All of these tools can be run by CIE, CD82, for example, gentleness can run all of these tools. Create, built, run unit test or another test. And you will get us artifact, the ready prepare, rebuilt. You can deploy it to your production servers. Tools for static code analysis. We already mentioned these tools on the previous lectures, but it's very important to remember that these tools such as Soma Cube, Yes, Lint, greeter. They can be run by continuous integration tools. And you will get feedback, most averaging created according to your code style. Or you need to rewrite, do some refactoring and Zen, publish your changes again to recap. And this integration, very important practice which allows your team deliver quarter frequently. You will know that nothing will be changed or breaking because you know that all your changes are verified by automatic run of static code analysis, running unit tests, integration tests, and in the end, you will get feedback. It might be some report or email which provides information that all steps up past and you have any errors. So really a very popular tool and additional eats, very important and very often is asked on any technical interviews. So if you're going to find some job, I would recommend you to learn Continuous Integration and learn at least one tool which allows you to implement continuous integration in your team. And thank you for watching go to continuous delivery. 27. Business Analyst Role on a Project: So in this section, we will talk about one very important role on the project. It's a role of business analysts. So in this video, we will talk, who is a business analyst? Why is this role so important? And what does he do real m, How do they do they work and what results they provide? According to meetings analysis, body of knowledge. Be this analyst. It's a person who performs business analysis task describing that guide, no matter their job title or organization role. Also, I want to mention that on some project, it's possible when you have no such person or you have no person who plays this role. But it doesn't mean that business analysis is not performed. Business analyst, it's a bridge between customer and team. This person can talk business language and transform this language to specific requirements which a team can implement. We can say that a person is a good business analysis if, if this person understands domain area or even know this area better than owners and can provide this data to this information to a team. This person has system thinking and ability to work with large volumes of data, unstructured data, which will be transformed to some specific data. This person knows how to use business analysis tools and techniques. And what's very important is strong communication skills because of if this person knows business area, those tools and how to use these tools, use some data on. But if this person can to communicate with the customer, can communicate with team, can transform this date and deliver information from customer to a team. It will be very difficult to work with such person and it won't be a good business analyst. So why is it business analysts is so important role? So on the very beginning, this person identify costumer problems and needs or use pains. And together with a team, they care model and the suggested solution, how we can solve a problem of this customer or fix his pain? Business analysts breakdowns a whole functionality into the smallest stories and tasks. Business analyst support a team during development. Here she can clarify requirements and provide all necessary information and helped on block a team if they do not understand substance from the domain area. Also, they help is scope management and handles customer expectations. So one does business analysts do? It depends on the phase of the project. If it's just the beginning initiation, business analyst, we'll dig into domain, will gather and collect information. He'll plan B, this analysis activities and strategy. And as a result of his work, we will have some vision of the project, scope of the project, some tasks, and we will have first business requirements. On the planning phase, business analysts communicate with all stakeholders, plan business analysis, specify and the model requirements. And as a result, we have approached specification and project backlog on the Executing Phase. Business analysts can provide dam was glorified details and provide some solution evaluation and changes in scope. As a result, we will have user stories, presentation and change requests can happen during development and we need to handle these change requests. During controlling phase, business analyst takes part in acceptance testing, conducted user training, provide some documentation and information. As a result, we will have some user guides and manuals. And on the last phase, business analysts preparing final documentation, what was done, how it was done? It was a work of business analysts. They use a different tools. As I mentioned before, a very important part, the focal point is medication for communication can be used Skype, slack or Outlook to say as some data or some presentation. We can use cloud storages. Or if you need prepare assumption, could we gotta use Microsoft Office or we will cloud documents to create some documentation, tutorials or presentation. We can use all the JIRA and Confluence for creating tasks and assign in this task. Different medallion soldiers can be used for preparing different models and diagrams. And also different techniques can be used during development such as interview, brainstorming, business, process analysis, functional decomposition, mind-mapping, and many others. During the project development, there are a huge amount of information which games from customers, from different stake holders or any other related persons. And this information can affect a team and a peg their performance. So very important role or business analyst. As I mentioned before, he or she is a bridge between costumers and a team. So this bridge also should collect or data, clarify it, make it more structural and the systematic should make some order HRM, this chaos. And as a result, we can have some product backlog with user stories with a clear acceptance criteria. And the team will know how they can solve this problem and how they can implement this user's story. As a result of their work, pieces, enlist, prevent teams from doing useless work. They can analyze what is the most important customer. And based on this information, can prioritize stories and team will do the most important stories for a costumer. This makes it possible to achieve valuable result using class airport additionally will improve the velocity and they will do more and more tasks. So to improve team performance, business L is this very important role which can help you to translate data and information from customers, from users, to the structured data, which can be used by team during development. 28. Project estimation techniques: So in this video, we'll talk about project estimation techniques. What is a project? How we can estimate project and where do we need to take a look on our project triangle estimation, anchor it matters and summarize what we know. Let's imagine that manager comes to you and brings five pages document and ask you to estimate the project. So you take a look on this document, spend three minutes and set. Okay. Three months was dissemination, years. It was estimation. But how correct was this estimation? It's another question. What is a project estimation? To understand? What is project estimation? First of all, let's take a look. What is a project? Project is a unique set of coordinated actions with the start and end date em to achieve the end result within time, cost, and resources. So it means that during a project, we have just three constraints we need to work with is a schedule, scope, resources. So it means schedule is a time. We have some limited time. What we can do, we can reduce a scope of work or increase the number of resources. For software development. It means remove some tasks or add some developers to a team. We can see a formula that schedule its scope, divided resources. What is the successful project? To finish projects successfully, we need, first of all, we need to finish a project and successfully fulfill all requirements. Snacks, or we need to finish this project on time. Also, we need to finish this project with acceptable quality of this project. And this project should be valuable. We need to have some interest to do it. We need estimate three areas. It's a number of tasks we need to implement. It's a limit of time and resources which we can use during this time. And now we take a look on the core of uncertainty. It means that depends on the project phase. Difference in estimation will be very different. So when we started this approach, we can estimate our project between four times more or 50-50 percent last time we needed. And during that time, we will start some development. We will decrease time boundaries. And in the end we will know the real-time for romantic this product. In this case, if we can clarify what is estimation, a good estimation. A good estimation provides a fairly clear picture of the real state of the project and allows a project manager to make good decisions about how to manage the project to achieve the goals, goals we mentioned previously. So let's go to algorithm of estimation. What do we need to estimate finished project on time and do it successfully? First of all, we need scope estimation. Estimates, the general scope of work we need to do. The next one is effort estimation, where we know what we need to do. We can create a list of tasks we need to do. The next one is scheduled estimation. It's a time when we need to implement these tasks. The next one is risk estimation, what can go wrong and how we can handle it or prevent these problems. The next one is resource estimations. What resources do we have? We can estimate the, for example, when people will go to vacation or do they have some holidays during development period? Do we need to increase the team? Or maybe in some time we need decrease a team. And the next one where we know everything else and we calculate our budget. Budget estimation. We will know how much money do we need to implement this project and what methods of estimation we know. We can split this matters into two groups is rough and accurate. For R, we can prevent an orgy decomposition and expert judgment methods. And for accurate, let's say we have storypoints, functional points, and use case points is the most popular. There are another method, but during this course we will skip them. So let's start from analogy estimation. What do we need to use this approach? To use this approach, we can take the previous project, compare current project with the previous one. And based on the experience from the previous project, we can estimate this one. How can we do it? We can split projects into tasks and compare each task. And then if their difference, we can calculate the difference between tasks. And then we will sum all tasks and we will know what we will have. What are the benefits of this approach? It very easy for estimation because of you have already implemented a similar product. You don't need to wait a lot of time for estimation. The new one, you do not need to know business area. Because of you can use just experience from the previous one. This matter doesn't make big mistakes usually, and it can be applied on different phases of product development. What are disadvantages? First of all, you need to have this previous projects. It's very good if you have some database or knowledge base of projects you imagined before. And beta on, the quality of estimation will be based on the number of projects he implemented before. Also, when you compare current project with the previous one, you need to be assured that previous one was successful and you finish it on time. The next one is decomposition mattered. What do we need? We need create a feature list. We need to split product into the features that we want to implement. During this process. We don't need to skip any functionality. Next, split to work package size. This means that all tasks should be splitted to small versions. We can estimate an implement during this process, use checklist to not miss some important parts. And with this approach. The law of large numbers works. It can be a good estimator and spiral can't be a bad estimation. As we go to the next one is expert judgment. How can we estimate the project during this approach? First of all, we need an expert who can estimate this project based on his or her experience. Additionally, these experts can take a look on the current tech stack you're going to use. And based on changes in text tech, he or she can provide some changes in estimation. And it's very good to when this expert can use another approaches and techniques to estimate the project. What's the benefit of using this approach? First of all, it's very easy to do it because of you need just to find export and additional. It can be very good estimation if you have a great expert and disadvantages the same. If you're expert isn't very good. Your estimation can be not so clear. And, and otherwise, it's very difficult to repeat this estimation based on the experience of another developer. So you will have two or three developers. Each of them will provide another estimation. But how can we solve this problem? To solve these problems of different estimations, we can use Delphi method. It means that we have a list of tasks in this project and we give this task to different developers. And they are independently estimate these tasks. And then we organized estimation session where all developers provides their estimation. And based on this information, we can collect it and provide one solution, one estimation, based on experience of each developer has gone to alkali metals. First one is storypoint, or do we need, we need to split the project into tasks again. Then the find easiest is this task for a team. Then we will use Fibonacci Sequence is the complexity of a task. So let's imagine that because the easiest task in our case to be one story point and all other tasks we will calculate based on what the difference in difficulty of implementation this task, let's imagine that next task is just two times more difficult than previous. Or the next task is five times more difficult than previous. And based on this calculation, we will know how many story points we need to implement the project. To provide this estimation. In 1235 story points you can use planning poker. Planning poker it's approach. A team facet cars with these numbers and they provide a estimations this task. The next approach is a functional points. So a functional part is a unit of measurement to express a mode of business functionality. It's functionality which we provide to a user. Partial points, measures sought for size, not time, resources, not price, just a size. Benefits of using this approach that it doesn't depend on. Language may totally shoe or a team we should will be used on developing this project. The next one is use case model. A use case is a series of related interactions between a user and the system that enables the user to achieve a goal. Use cases are a way to capture functional requirements of a system. The user of the system is referred to as an actor. To use this approach, we need to remind unadjusted use case await. Also the next one we need determined and adjust actor weight. And we need to summarize this ways to estimate the project. So let's wrap it up. What do we know? To provide a good estimation? We need estimate, real functionality, not document size. So if you have to documents five pages and 100 pages, it doesn't mean that documentary is 100 pages. It will be bigger project and you will need more time. The next one is you need to filter information. The person who will provide a summation need to filter information for managers because sometimes a lot of useless information which can affect your estimation. And also if you're a manager and you want estimation from somebody, do not share your thoughts and your ideas about estimation with experts. Because if you can effect these experts opinion and they can provide estimation based on information you provided them. Right now we know some techniques how to estimate project, and let's go to Tasks, estimation. 29. Task estimation techniques: We already know how to estimate a project. So let's take a look how we can estimate each task in this project. So our plan for today, we will take a look what is a grooming or night calls refinement. We will take a look on Story Points, then, Poker and very popular estimation technique. It's three-point estimation technique or parrot. Let's start from the group and what is a grooming? And why is it so important for estimation technique when Tim starts doing subtasks, not all they know how to do ever since. In this case, we need somebody who can describe, clarify some questions, issues, and provides an informative heartbeat. Need to implement these tasks. Usually it might be business analyst. We already talked about business analysts. Or sometimes it might be a product owner who knows what do we need to do and Backlog Refinement or just refinement is emitting where product owner and some or all of the rest of the team review items in the backward to ensure the backlog contains the appropriate items that they are prioritized and the items are the top of the backlog. They are ready for delerium. Also, what's very important during this process, the team can ask all necessary information if they don't know how to implement something, and they can provide some correcting estimates in light of newly discovered information is very important because of to estimate some tasks, you need to know how to do it. What should be implemented during this task, where we know what we need to implement. We don't have any blockers and know what to do. We can organize some estimation session. And on estimation sessions, we can use very important technique. It's planning poker. And the basement of this planning poker is a story point for people is very difficult to estimate sums to Qin ours. For example, can we do this task one hour, two hours, or the next task will be implemented in 15 or 20 hours. But for people is very easy compared tasks, which was more difficult, which was easier for implementation. Using story points, we can find the easiest task for a dim. It works for teams. And when a team knows what is easiest, ask for this team. They can compare these tasks with others. And for example, next task can be two times more complex than aside two story points for this task. The next task can be eight times more complex. Eight times. It means that the, a lot of uncertainty and maybe we don't know assumption. So we will add some risks in this estimation using Story Points to estimate effort we need to do to implement a story from backward. Because storypoints are present, the effort to develop a story and teams estimate must include averaging that can affect the effort, that could include the amount of work we need to do, the complexity of this work and risks. We can use Fibonacci like format with 12358 story points. But also we can use T-shirt sizes is where people are prone to also buy. We will estimate the tasks in the shirt sizes, sizes such as Excel. And then we will know how complex is this task. And for team, if they know how many story points they can implement during some period of time, usually called a sprint. We can calculate how many tasks we can do during this time. To estimate every task in some story points, we can use technique of planning poker. How can we use this planning poker? It's like a usual poker. Each team member has a deck of cards. We see Banaji numbers we saw in the previous slide. This team should choose a person who will be a moderator. During this process. That the moderator provides information about task we need to estimate and each Demetri privately choose a card or the complex task is he or she think, and then provides this cart privately. And in the end, when all providers estimation, the moderator, can open all these cars and we will know the task estimation from each team member in the first row of, it's very likely that the estimations vary. The high and low estimators explains the reason for their estimate is by often different domestic and provide different estimations for the same task. You have different vowels. Each team member can provide. Why they choose this cart and why these tasks will be difficult to implement. What can go wrong, can do what we need to do. Maybe they know some pitfalls during implementation this task. After that, when we provided all the information, we can start the next round of estimation. And on the next round, usually we can find some consensus and we will have final result. The next barrier popular technique is a technique Program Evaluation and Review Technique. Or usually it goes three-point technique. While the three-point, because of to estimate some task, we need to calculate estimation based on the formula per uses a three-point estimation approach for a task, and the task will miss uncertainties, can have a wide range estimate in which the task actually will get completed. Uncertainties include both favorable conditions, opportunities, as well as unfavorable conditions threads. So you calculate pair, we need to calculate optimistic estimate, pessimistic estimate and most likely estimate. For example, if we think about a task which involves travelling in a crowded city from a specific location in the city to the airport. Actual time taken will depend upon the traffic condition on the road. This may take optimistically 30 minutes, pessimistically, 90 minutes, and most likely 60 minutes. So the range in which the travel time will fail is 30 minutes to 90 minutes. So isn't this formula, we will calculate that actual time will take approximately 60 minutes. For prevalent, there are a lot of different techniques you can use to estimate the task. But this one is very popular and provides very likely estimation time. What do you need to do the task?