QA Engineer From Scratch (FULL AUDIO COURSE)

Hi, this is lesson number zero in the course QA Engineer from Scratch. Yes. It sounds a bit strange what lesson zero is, but let me explain. My course on this channel was recorded in the period from 2020 to 2023 as probably the main videos. But it is gradually updated, some other lessons are added, but in general. If we talk about the main backbone, it's somewhere around this period.

In that time, of course, a lot of things have changed. Yes, in terms of some of the approaches to testing, in terms of tools, the interfaces have changed. In general, the market situation has changed a lot and my some other training formats have also emerged. So today I And I want to emphasize on that and tell you about some things that were in the first lesson and will probably be further on if you are just starting.

Discourse and the first time you see me at all, but I did it on purpose beforehand. Let me say right off the bat about some inconsistencies that might be. With what I'm in the market for right now, if you see the pattern in the first lesson, in the next lesson, I mean SDLC, okay, it's clear. It's a general process involved in the development of day-to-day software. Further down the course you'll learn what it is.

The responsibilities of a testament In general, nothing much has changed, that is to say. We work on the same things, this is the development of test documentation, this is conducting tests, this is drawing up defect reports, including if we are talking outside the context of a tester.

There is such a process as quality assurance, where we are working with processes specifically with the in the process of how we introduce this quality at the project, some preventive measures. That is, we can add another point here. And there will be a separate lesson about quality assurance. You will learn about it too. As for skills, look, soft skills and

are the same. Soft skills in fact are a set of your personal characteristics that is conditionally what you should have even before you start studying a particular area of testing and some hard skills in fact some technical skills.

You always have to separate them. Separate personality traits or flexible skills, separate technical skills or hard skills. So as far as soft skills are concerned, we take all risks at once. We are attentive, diligent, trainable, communicative, responsible. It goes on and on. If you don't have this set of skills, especially attentiveness and communication skills, you will probably have a hard time and responsibility in testing because We communicate with a lot of people.

And it's not only our employees, conventionally, colleagues, yes. We don't have employees. We are also employees like everyone else. Our colleagues, developers, designers, analysts, including we communicate with the customer. Yes, this also happens on projects with business representatives. We may even sometimes take on a support function and talk to customers. So there is a lot of communication.

attention because guys we are working to make sure that everything works great. That we do not have any defects in the system. That no mosquito has poked its nose into our documentation, so without this, we will not go anywhere.

I must here on a course on step conditionally why how I'm inattentive what to do. Well what to do. It's likely to be very bad in that direction. And responsibility, because we have Responsibility related to our quality, the quality of the product that we produce and we as flagships of quality on the project.

must also bear some responsibility for it, and we primarily organize the process around it. And by the way, the whole team is responsible for the quality of the product. No matter what anyone says, this is also for your future. And hard skills. Look, there is also such a thing our knowledge is at the level of an advanced user. Obviously we should be able to work with the command line at some level of basic queries.

And we will learn how to work with Linux somewhere near the end of the course, conventionally. And you should also have an understanding that the computer is not just about Word, Doc, and FunFarm, yes, some games. This system these systems have to manage and understand the stuffing. So these skills you will also need to get some knowledge somewhere, maybe even additionally. English. Look, as far as the English language is concerned, so I have the majority of the Russian speaking audience.

And the majority of the audience, strangely enough, from Russia English language, it is not the most important requirement for the region of the Russian Federation. Here in the Russian Federation you can find a job without English. And you can get training without English and write documentation in that language. If we are talking about English for Belarus. for Ukraine, for countries that are involved in custom development.

outsource, outstuff, English is mandatory there because the market, it works for the foreign market. And the universal language, the international language is English, you will need to be able to speak and write documentation and perhaps even solve some managerial tasks if we are talking about further ways. Uh of your development.

To learn in English because most of the materials are not even translated into that language. So for these countries it is obligatory to learn, and for everyone. That is conditionally if you're from the Russian Federation, it does not mean that you have to forget about English. If you plan to live in the Russian Federation all your life.

To work in some product company where only English, Russian, or rather you can of course think about it. But if you plan to develop, to look for some international projects, to go somewhere, to become a man of the world. And to learn, first of all, English language you will definitely need.

knowledge of programming languages. If we are talking about manual testing, which I give on the course, it is optional. If we are talking about the fact that we need to know a programming language anyway in the future to automate something, this is an important theme. And now there's a general trend to hire specialist

who can do something with their hands and write code. Therefore, probably some stage of your career development, unless of course you go into full management and management of of your team. You will not need a programming language, although to understand and speak the same language as your team it would be better

To learn something, at least some basics. If we are talking about the manual tester, then yes, programming languages are not the most important thing for you at the moment. But if we are talking about an integrated specialist, you will need to learn it in some language anyway. Knowledge of web technology, mobile applications, scamdev, this we will all learn in the course.

Probably not Gamdev, because Gamdev is a very specific field. If you want to test games, you need to look for someone else, and very often there are not even separate courses and most likely you will be taught the specific stuff. Game testing at work? Here, these are the kind of important specifics I wanted to talk about specifically in terms of skills. Duty is a little bit more specific. and about the benefits of the job, low entry threshold.

I'm not retracting what I said. I'm not talking about the easiest entry into it, the easiest point of entry into it. Many people for some reason when they watch the video think that's what I mean, although I clarify there that it's not. The low threshold of entry has to do with the fact that testing will improve faster.

Conventionally you can in a few months already have some basis related to functional testing. If we are talking about development, you will only spend six months or even a year learning the language itself. That is why we have a lower threshold in this respect. In terms of how the requirements for specialists have grown now, they have grown.

And to say that a tester is just a person who read Savin's book twenty years ago or not twenty, okay, ten years ago, and that's it. And he's ready, and he knows English, he is ready to work s that's not true. You have to learn a lot of things. Quite voluminously and intensively. If we are even talking about my course, which you are going to watch next, it is exactly like that. And you have to learn a lot of things in a few months. It being easier than for example.

Uh development, one hundred percent. Career growth. Well, it is clear the benefits of the job are related to career growth, yes. You will grow if we're talking about it, everything is quite transparent there, and there are no incomprehensible formats related to salary revision, as in some state companies. You will always understand where to develop. Where to grow there are certain requirements there are.

Assessments, evaluations of your work or performance reviews, evaluations of your effectiveness. They're once every six months, once a year. And you will always get some kind of salary increase once a year if you really show some big delta in your development how you have grown from point A to point B. The salary is also quite high. We are not talking about entry level positions, the salary is different there. I'm even afraid to name numbers now so that no one will say anything to me later that

No you say too little. Talking too much? Open some services on salary collection statistics in your countries and look it up there. Haber Career Headhunter does periodically some analysis in Belarus WI in Ukraine Doa or Gini or some general reports, articles on this topic. And orient yourself on them because I am watched by people from different countries. And I myself

M Belarusian, by the way. Yes, who does not know and always says that I am a Russian blogger. I am not a Russian blogger, I am Belarusian. Yes, that's why I can't say for sure that you will have a salary of five hundred or a thousand dollars and that's it. And work for me. But it will be reviewed. If you have a normal company with normal processes, the growth will be Can be quite fast and

There in a year or two you can grow to the level of X two, X three that is. A salary to receive a Two minus three. times more than your initial salary, especially if we are talking about entry level positions. If we are talking about positions at higher levels, there of course, the revision rate is not so high. The work itself is interesting. Someone says that uh Tester is a chore, but actually

No, it's very interesting, there are a lot of tasks, especially if you change projects frequently, you won't get bored, believe me. So nothing much has changed in terms of the benefits of the job. Perhaps I would even say you could add disadvantages here. But the disadvantages are related to the fact that the market is oversaturated.

with specialists without experience. In testing because, let's say, thanks to a large number of courses that didn't just use this thing as a low entry threshold, but used it as a simple entry point into it, where you only need there The ability to read and that's it. Without English, without programming, without brains and so on you can become a tester. So here? The peak was probably when the pandemic started. Everybody abruptly went into this.

from those and a lot of course creation. By the way, my course also appeared in 2020 but it's free. There's no arguing about it anymore. And I generally never had a goal to make a lot of money from this activity. Because of this myth, a lot of people have flocked here, so there are a lot of specialists on the market who cannot find work.

And now those who have this work experience in the form of internships. In the form of some commercial projects and so on have an advantage. So always look for third party projects related to the fact that you have finished the course and you need to get an internship.

Otherwise without an internship you are unlikely to find a job. These are the realities of the market now, and you have to be ready for it. That is, you are now taking all the risks associated with learning this profession, so that there are no surprises for you later. Okay, I will not talk about business users because the next lesson will be devoted to even more aspects of this business. Tabs, charts.

I just made accents related to what are some starting points, why you need this course at all, yes. What does a tester do in general, what skills you need to pump? If you don't have them pumped, you don't have them yet, and we will close many of them on the course, at least related to hard skills. And here too I told you a little bit about the advantages and disadvantages because

Because you have to give some explanations. A lot of people don't realize this. I will also tell everyone once again that the course is not a panacea. Finishing any course, even a paid one. You will not get a one hundred percent job guarantee. No matter what anyone says, and on what sites would not write. You will need to do a lot of things on your own afterwards. That is fifty percent of your success depends on you, not the course. Fifty percent of the course I think

You can say such percentages. Next comes the job search, building a job search strategy, resumes, feeds, networking. We will talk about networking in one of the next videos that will be on the channel. That is all of this together will give you some kind of springboard for you to find this job. We don't rely only on core.

And that's why I recorded this lesson in the first place. Because this course, which you will continue to take, you can take not only on YouTube you can take it and on Stepic first of all. Please note that on YouTube, on my channel, there are two Playlists, yes, related with it.

Well not with it, but with this with the course. Yeah, my tester from scratch. In the first one, which is the basic course, there's only thirty three videos. And in the professional course there's eighty eight. I would advise you of course to watch the professional course because there's more information, there's more work with tools.

And the thirty three video basic course, it's the most basic that is. It's the theory of testing is some Really basic base for you to understand who a tester is and what he does. If you want to go deeper, then we'll go into the second playlist. And here's the second playlist, it's right here on Stepic. Why I encourage you to learn not just by watching YouTube videos, but on some kind of platform. This course is absolutely free, which I've posted here.

There's about seventy videos here. Not even all of them that are in this playlist are in professional. In addition to the videos themselves, if we open up the testing principles to show you how the course is structured, there's a video that's just copied as well. From this playlist, you will watch a video seek here on Stepicon. Then there's more information, some links will even be different, some new links will appear. That is some updated

Stuff, not just what's on YouTube. Most importantly, there is a text format. Not for all lessons I'll tell you right away, primarily for testing theory. Here are the first three modules complete Contained text format in addition to video and web testing I also began to fill in slowly. Some lessons related to tools they will not have.

Text accompaniment because seems to me that practical things should be shown exactly on video, so that you watch, repeat, and work with me specifically for this reason. Uh that is the text where something is described, then there are tests. There are my notes of the auto course, if you need to explain something, to give examples, examples from practice, from real processes I try to add. For example, some things they weren't on YouTube either.

And here, most importantly, corrected the errors that were in the videos themselves because they are yes, all people always include the human factor. So here is the actual information. I would advise you to connect in parallel to watching videos also this format. In addition to the tests there are assignments practically well in some lessons where they are necessary.

There are tasks there on SQL, there are tasks on APIs using Postman, there are tasks related to describing test documentation. In general, there is enough material. There are about one hundred and eighty tests and tasks in the course, so you can use it to your heart's content. So for each lesson, open it, look for it.

What else is interesting? There's a final test. This is a purely test simulator. In fact, all the questions from the course are collected in one place. You can pass and when you finish the course. Conditionally repeat what you have passed and check your knowledge. This is what the course on Stepic looks like. You can get certified here, importantly through a third-party platform. In introductory lessons.

There's a separate slide dedicated to this because I was not given the opportunity to connect a certificate for the free course. Then use this here are the instructions, take the core. At eighty, leave a review, not necessarily positive, any review leave, I just want to receive feedback and I will tell you why. It is important to me a little further on. And that's it, that is how the course is organized. There is

A comments section where you can ask questions about the assignments I try to answer if someone doesn't answer from the students. Also, is our community in Telegram, all the links I will leave in the description. You can also connect and communicate within it. In other words, the format of the training is as follows. Watch the video, read the text, if there is any, and do the assignment. And so for each lesson. If we are talking about some practical lessons

Then watch the video, repeat everything I do in the video, and then close the video and try to do it without me. Or by solving these same problems on some other cases, on other sites and resources. A lot of self study is needed, well, in principle it is logical. Because the course itself also implies self study in the first place. in one lesson. There are additional links to bonus materials, that is you can watch. There is a simulator for

Practicing practical skills of tester, if you lack practice on the course you can go here and so on. In other words, study the structure, connect, use it. You can just watch videos on YouTube, no one forbids you to do that, but there is no feedback here, there are no tests to consolidate some tasks, there is no community. That is, you can write a comment, but there is no feedback on the course. You may not be able to respond because

I have a million views under some of my videos, there are either three hundred thousand or three hundred thousand, and I don't have time to respond to everyone, and I don't have the task of responding to all the comments on this channel. And don't forget that there are other videos here so you don't have to focus only on these two playlists. There are videos related to job search, hiring, some specific

There are live broadcasts on the channel. Yes. Uh you can watch the broadcasts with resume parsing, with some conversations, with experts, panel discussions, with parsing of test cases. I mean it's all on the channel. It seems to me that this is one of the most saturated channels on testing in the Russian speaking segment of YouTube, so I will be happy to see you. In addition to the fact that you can learn for free, both on YouTube and on STEPIC, I have a paid alternative.

Here in one lesson, if you're interested, you can read what my paid courses are. My pride is my course I'm going to show you now. My course on testing it's called functional testing. It was completely recorded in the spring of this year twenty twenty three years. So if you go over here, let's turn this thing off, let's go. To select a course you can see all my products, but we're going to focus on functional testing by I mean I recorded the whole course in the spring, added new tasks, new tests.

It can be bought on UDME and intern platforms. UDME does not work in Russia and with part of the banks in Belarus, intern can be bought from any country, from any bank. The rates are the same, just on different platforms. That is by cost. Look the relevance of the course as I said. In twenty twenty, three years, it is recorded there are fifty plus lessons again. The same thirty plus hours.

Pre recorded content questions about three hundred is issued a certificate by the way, and well said, on Stepic is issued a certificate, yes, through a third party platform. There is also a closed chat. You forever get access to all the course materials and all the updates you will have. The terms of training are as follows. How much to learn? Well, it is not particularly interesting.

Well, and further you can read what is here. The course is in principle, I think, not bad. They are somewhere at the intersection of junior, junior plus strong junior specialist, middles find even a lot of interesting in it, so you can study additionally. It is completely different from what is on YouTube and contains more.

Information, more tools and everything is up to date there. These are the junior independent junior plus our group rates. The next enrollment will not be until two thousand twenty-four. In the spring, and there I'm already doing group work with people, we'll be revising this whole thing soon. There will only be one fair left with a different cost. With a different number of people in the group.

What's good about the rate is the live webinars, which means I'm there every week or every two weeks with the guys we discuss some hot topics. There are practical assignments about twenty pieces of different ones quite in depth which give you a complete base. There's feedback, which is important because uh on Udemy and um on the internets I don't give feedback. The feedback in that form is just the solutions to the assignments themselves from me.

Well, what's most important is internships, meaning the best students I offer internships. Again, this can all be explored on my website if you are interested. So there are some paid alternatives you wanna choose for yourself, you want to work on the free course, which is also constantly updated, I support it because initially I want education to be accessible to everybody.

As for my training, the whole plan is on Stepik. You can watch it. On YouTube, the videos may be in a slightly different order as they are on Stepik. On Step Eak they are in a more logical order, so again, I would advise you to use this platform for your training. Plus you'll get some sort of confirmation in the form of a certificate after you run out. If you still have any questions about this video, about my course, feel free to ask them in the comments.

to my other social networks, there is also a lot of useful material. You can read where, what, when. There's a link, it's coming up now. And I'll see you in the next lessons in this course. I'll be happy to help you become a tester.

Hello YouTube, my name is Artem and today I want to announce a new free course on software testing for all those who are interested in this topic and have decided to further link their life with quality assurance. I think it's worth starting with what testing is. My favorite definition is the search for discrepancy between the actual and the expected result. That is, if the customer wants to see a certain icon on the page, this will be our expected result.

And how it will be implemented in our product is the actual result. If they differ from each other, then this can calmly be attributed to a defect, the search for which is what a tester does. The role of a tester in a project, in my opinion, is one of the most key. Any major IT company cannot do without this little person on the project. Let's talk a little at the main stages in the software life cycle.

or as it is also called, SDLC Software Development Life Cycle. There are several models of such a life cycle. We will think about this with you in one of the following lessons. SDLC. The first stage in any project is initiation or the idea. That is, some business understands that its user, its consumer, has a certain need for a product. This product will really take off. It collects some data on what it wants to show its user after all, and he has an idea.

With this idea he comes to an IT company and if there is an agreement that this project will be developed in this company, business analysts join the case and begin to collect requirements. They communicate with the customer, with the end user, form a pool of requirements that will need to be implemented in the final product. Further, one can distinguish such a stage as design. UiUX designer who, based on the requirements, draws if we are talking about a web application for example.

mockups or templates of the site that our customer wants to see. If the customer has no questions about the requirement and the design, then developers get down to business. And the actual development begins. That is, developers write code that will subsequently go to testing by testers, as totological as it may sound. After the product Uh it is tested, it is handed over to the end user for operation.

And if the business understands that this product is no longer in demand or comes up with something new and forgets about supporting the old product It is withdrawn from operation. Let's think with you at which stage the tester is connected. Of course, it would be logical to assume that this stage is called testing, but in fact it is not. The tester connects to all the people. Testing already at the stage of development and collection of requirements.

What does this consist of? Let's talk a little bit about each of the stages and what types of testing can be associated with them. I will tell you not only in passing because later we will discuss each of these types of testing in more detail with you. For example, development and requirements gathering. The tester tests the requirements themselves for their compliance, their main properties, how correctly they are written, whether they contradict each other, whether they are complete.

If everything is okay, then at the stage of design development, the tester can test both the template itself for compliance with the requirements and conduct usability testing, that is how convenient it will be for the user to use our product. At the developEman stage what our developers wrote is tested, that is here both the UI, that is user interface, what we see on the screen when we open a particular site.

And what is under the hood or back end, that is. What an ordinary user cannot see can be tested. And in principle, as far the introduction into operation. Acceptance testing, alpha beta testing can be carried out here. I think those who play computer games are familiar with these phrases. Again, we will talk about each type of testing with you a little later in subsequent lessons. This is what concerns the stages of software development.

The roles of a tester at each of these stages we will talk to you in more detail. About the life cycle models of software a little further, since now we were talking about the classical model. But there are also other more interesting ones, for example, the same agile methodologies, agile scrum, by which most modern IT companies work. Now let's talk about the responsibilities of a tester. There are several types of activities. So let's talk a little about each of them responsibilities. Yeah.

First, it is the development of test documentation. That is, it can be, for example, a checklist or a test case based on which certain checks will be carried out. I want to note right away that we will also talk about each of the artifacts characteristic of a particular activity in subsequent lessons. So stay on this channel, I think you will be interested.

The second stage is conducting the test. That is, based on the test documentation written by the tester, whether it is a checklist or a test case, a series of checks is carried out. And If we understand that our actual result and expected result differ, then we draw up a bug report. Or it is also called a defect report.

This defect report goes to the developer. Based on it, a bug fix is carried out, that is the correction of a certain error or defect. And if everything is okay, then it is sent back to the tester. The tester verifies that the bug was indeed fixed. And in principle, at this point the work I think of a beginning tester ends, as other types of activities are more suitable for middle, seniors or leads.

That is, to those people who are a little higher on the career ladder than you. So we talked with you about the main phases of the project, about the duties of a tester. Let's now talk a little about what basic skills a tester should have. Skills. There are two large areas of skills, so-called soft skills and hard skills. Let's add two subtopics, hard skills and soft skills.

What are hard skills? These are essentially your technical skills. If we are talking about a tester, then the following should be noted here. This is knowledge of the operating system at the level of an advanced user. That is, it is not enough just to be able to work in Word. You need to understand a little what web technologies are. what mobile applications are, how Windows works, perhaps go to the command line, write simple commands,

Here in fact the field for maneuver is quite large. I will tell you a little about some aspects of testing web oriented applications about testing mobile. So I think that this knowledge will be enough for you to start your career as a tester. English language. Yes, it will be very difficult without it. Why?

Because most IT companies that work are oriented towards the West, that is to Our customers are English speaking, all documentation within the company will be in English, communications will be in English, plus a huge amount of educational materials are also in English. And software included. Therefore without it I think that being a tracer is not your destiny.

So learn English. The minimum entry threshold for a tester is the intermediate level. You have time, there are courses, there are videos on YouTube, there are books, so we learn English. It would also be nice to know. programming languages, at least some basics or fundamentals, this will also come in handy for you. Well, as I already said, this is knowledge of web technologies, mobile applications, possibly game development.

That is, it will depend on where you will work in the future, which company, and this company will have its own requirements for a tester. Since you will be testing either the web or mobile. or working in game development and testing video games. So we talked with you about hard skills, technical skills, let's now talk about soft skills. Soft skills are your personal characteristics. For example, for a good tester, it is worth noting such as attentiveness, perseverance, teachability of course.

Communicativeness. Without it, not at all, because the tester, like it seems to me, and the business analyst just have to communicate with every member of your team, your team. Without this skill, it will be extremely difficult for you. Responsibility of course. You are responsible for the quality of the finished product. Without this characteristic it will be extremely difficult for you. This list can be continued indefinitely.

In fact, sub skills also pay a lot of attention, so don't think that if you are good in some technical area, you know, I don't know, in web technologies at the level of a box. But if you behave not very well as a person. Then it will be extremely difficult for you to work in it. I would also like to note that you need to understand that the developer and the tester have different. Mentalities The developer creates programs and

writes code that is he is interested in creating something. The tester in turn wants to break what the developer wrote, find as many defects as possible, critical for the operation of this or that system of our finished product. Against this background, conflicts can arise between the two sides, so I also warn you in advance that this may You need to abstract from these situations and understand that you are responsible for the quality of the finished product.

You do your job and you came here not to play games and not to make friends, but to really take a responsible approach to work and release a quality product. Let's talk to you about why testing is necessary. There are always two sides. This is a business. and the user. And each of these sides has its own need.

Business wants to release a quality product that will bring it profit. The user in turn wants his personal data to be protected. What he pays money for, really, for a quality product again. That is, in fact, both the user and the business do not want to take risks. Business does not want to lose money. The user does not want, for example, data about his finances, about health, about Members of his family did not get into Strangers Hands, that is the same thing.

He also takes on certain risks and wants the product to fulfill everything that was laid down in it by the business and what the user wants to get. Why am I saying this at all? Because there are not a few examples when companies suffered simply huge losses associated with the fact that they released medical equipment with a huge number of defects or with one. But very critical. From which people died or became even more ill. Or a personal user data fell.

Into public access, for example, at the same Facebook. I think everyone knows very well that there were such moments as it affects both the fact that the user does not want to use this product further, as well as the reputation of the company itself. Plus, the company incurs huge losses because the fines for disclosing personal data or they are also called sensitive data that is sensitive data. of users are now simply huge. Also, returning to the question of loss of profit for business.

There is a very famous model related to how the cost of fixing a defect changes with the detection of a defect at one or in other states. Product development If a defect is detected at the stage of development and requirements gathering, it is one money that is the same.

There you just need to change the requirements themselves in the documentation. But if this defect is detected at the stage of release, introduction into operation, when it reaches the end user and for example The sensitive data of this user becomes known to the general public. Then the business will lose just huge money. Firstly, in order to fix the defects themselves, since the code has already been written.

It will need to be rewritten again, again tested, possibly recalling product from some platforms. From the same app store or play market. Therefore, testers should always be involved at the very early stages. of the project. In principle, these are the main points that I wanted to tell you in today's lesson, but so that you are convinced once again how cool it is to be a tester. Let's talk a little with you about the benefits of working. A tester.

Firstly, it is a low entry threshold. It is no secret that it is much easier to become a tester than to learn to write code. So many choose this specialization as the first for entering it. Indeed, yes, it is, but if even ten years ago anyone who, for example, knew English could become a tester, now the requirements for The tests are much higher. As I noted earlier, you will need to know web technologies, mobile, and maybe even programming languages.

Basic level so don't think that it's so easy and simple to become testers. Career growth, yes, in fact, this is also an interesting aspect since in principle. With your great desire and constant learning and self development, you can grow very quickly up the career ladder.

Starting from the level of a junior, that is a beginning tester, not ending with the level of a lead and managing your testing team in one company or another. You can also change your development vector at any time become, for example, an automator if you started with manual testing which we will actually talk to you about during this course. Or you can become a developer or a business analyst

a project manager managing the project as a whole. That is, you have a huge field for change in your activity. salary. Since many of you know that in it, they receive much more than in others. At least if we are talking about Russia, Belarus, Ukraine, At the same time, you must understand that testers have the lowest salary in the IT field. However, it is still higher than the market average when compared to other industries. Well, of course the work is very interesting.

You will not have to be bored at work, as you will always learn something new, both from your team in which you will work, and at various seminars, conferences, reading professional literature or again going. YouTube and finding interesting videos related to this area. So dare I think you will succeed? Well, this was an introductory lesson for beginning testers. Further it will be only more interesting. We will talk about both the theory and practice of testing.

The knowledge gained in this course will help you get your first offer, I really hope so, and start your work in the company of your dream. If you found this video uh interesting, then be sure to subscribe to this channel, click on the bell, leave your comments, I will definitely answer everyone. And we will see you very soon. Goodbye.

Hello, YouTube. In our last session, we discussed why a tester is needed, what kind of creature it is. And And I'm glad you stayed with me to continue learning in this course. It's time to start studying the theory. Today we will learn about the seven principles of testing, which every self respecting tester should know. Principle number one Testing shows the presence of defects.

Testing can show that there are defects in the product, but it does not signal that there are no defects at all. That is, in the process of testing, we reduce the likelihood that defects remain in the product. But even if we did not find any at all, we cannot say that they do not exist. In my experience, there are always bugs in the product. Principle number two Exhaustive testing is impossible.

It's simply impossible to test absolutely everything in the product, and even if you think otherwise, you will spend a huge amount of time on it, as you know time is money. You might ask, how can you then be sure that the product works correctly? I will answer this by saying that there are always risks and priorities. To minimize the former, there are special test design techniques that help testers design their tests so that

with minimal effort. They cover as many test cases and functionalities as possible. We will talk about the main ones in the following lessons. But now let's talk about principle number three. This is early testing. Let's remember the cost of defect correction model from when it was detected. If you have forgotten about this model, you can always remember it if you follow the link that will now appear at the top.

This model characterizes the principle of early testing as well as possible. That is, test activities should start as early as possible and always pursue specific goals. In this case, saving the customers' funds. Principle number four, clustering of defects. It states this, a large number of defects are hidden in a small number of modules. If we remember the Pareto principle, then it is applicable to this principle as well. 80% of the defects are found in 20% of the functionalities.

That is, we must understand that the largest number of defects is concentrated not in the entire application, but in some specific functionality. Therefore the tester must distribute their efforts proportionally to the actual density of defects. For example, if he understands that in the user login module to the system,

There are always some critical defects, then he should focus more time on finding and eliminating these defects precisely in this functionality. A very interesting principle called the pesticide paradox. Let's talk a little bit about it. Running the same tests over and over again, you will encounter that they find fewer and fewer new errors. As the system evolves, many of the previously found defects are fixed.

And old tests no longer work? To overcome this paradox, it is necessary to periodically make changes to the used test set. Review and correct them so that they meet the new state of the system and allow finding as many defects as possible. For this, it is also necessary to constantly study new methods for testing and implement them in your work.

Also, to overcome this obstacle, you can have other team members run the tests, or rotate personnel so that different testers test the same functionality at different times. By the way, the question of minimizing this risk is often asked in interviews, so be sure to remember the answer to it. Why is this principle called the pesticide paradox? It's very simple. Draw an analogy with the use of some chemical against insects or weeds.

If they are constantly poisoned with the same insecticide or pesticide, then they develop a tolerance, they adapt. And fewer insects die or are destroyed by the action of one or another toxicant. The pesticide paradox works the same way for testing, principle number six. Testing depends on the context.

What does this rule state? The choice of methodology, technique, or type of testing will directly depend on the nature of the program itself. For example, software for medicine requires more thorough testing than a computer game. Or a website with higher traffic should go through serious performance testing. To demonstrate the ability to work under high load conditions. Therefore, the tester must always responsibly approach the choice of the environment in which they will test.

The choice of documentation to be implemented. It is better to choose test cases rather than checklists. About these artifacts, as I said earlier in the first lesson, we will talk a little later, but we will definitely touch on all aspects of test documentation and the correct choice of it for this or that project. And the last principle for today is the fallacy of absence of errors.

Every tester should not assume that if testing has not revealed any defects, then the program is ready for release. Finding and fixing defects will not be important if the system turns out to be inconvenient to use and does not meet user needs. Well, these are the canonical principles of testing that help the tester in real work.

You see there are only seven, but you should definitely know them, because they are often asked about one principle or another in an interview, and this will not hurt you at all. As it would build a structure in your head on how to approach testing and minimize the costs of conducting it. Well, that was a short lesson, much shorter than the first. Be sure to follow the link above to watch the first lesson, so as not to miss anything important for our learning with you.

And in the next lesson we will learn to distinguish what QA, QC, and testing are, and talk about such processes as verification and validation. And of course if you found this video interesting, then be sure to subscribe to this channel, click on the bell, leave your comments, ask questions, I will try to answer them for sure. And we will see you very soon. Bye.

Hey guys, happy holidays to everyone. It's already past New Year's Eve and old New Year's Eve and Christmas Eve, so I wish everyone the best of luck. this year, and that all your wishful thinking and job search leads you to some cool result. But I have an unusual video today. You may have noticed that the video the third lesson in the basic course tester from scratch related to QC, QA and verification and validation testing has disappeared from the share.

So the reason why it's missing I'll tell you sometime later, but in general today I'm going to offer you an updated version of this lesson. I've made some updates and brought it to a look that E sticky bee fans will probably like because the certifications require exactly what I'm going to tell you today. And I'm also going to tell you a little bit of information from Kulikova because I think this is one of the best tutorials, one of the best tutorials that's out there right now.

On the theory of testing in Russian, which is distributed absolutely free of charge, and I think it will also be useful. To learn something new for yourself. Also this lecture in a slightly modified form will be included in the updated versions of the courses that will be on Udemy on the core platform. And as part of the junior package of my group, because I'm updating all my videos, all my videos and the guys who

want to buy this course, they will get the most up to date lessons and lectures that can be. On YouTube I don't plan to massively update all the videos, but maybe some selective ones I will replace too so that you have up to date some information. On testing theory, on practice and so on. That's it. Said what I wanted to say, shared a little bit of updates.

And now let's talk about what is testing, quality control, and quality assurance. If you and I turn to the STKB glossary, it's basically a dictionary, which contains a large number of terms. Then, according to HTTP translated into Russian, because there's also an English version, which people like better, but still we have another format that you may find useful and facilitate your learning.

I remind you that HTTP can also be taken in Russian, including in the certificates. It is not indicated anywhere. I myself passed this certification in Russian because I had limited time, So don't worry you can do it in Russian too. So testing is a process that contains all the life cycle activities. Both dynamic and static.

Related to the planning, preparation and evaluation of a component or system and related deliverables to determine that they meet the described requirements, to show that they are fit for purpose and to identify defects. You see a very large such definition. It can be simplified. I will show you further on how to do it. And there is actually a lot of things shown here within that really make testing and what you go through in the course, even when we are learning.

We cover a lot of things. There are so called stealth processes, I'll show you on the next slide. I think there are just all these processes. Of the whole life cycle, I'll tell you what they are. Dynamically means by launching code, that is, we must launch something and track the dynamics.

And statically it means without launching code, and most often it refers to some documentation that we can read, to a specification, to requirements, to what else can it refer to? To code that doesn't run, we can proofread the code. These are these static testing methods, we talked about them a little bit further down the course.

It's just like I said, these are updated videos and the rest of the lessons, they're already within the course and you'll be able to watch them. Planning, preparing, evaluating system components. Okay, that's clear, we're going to talk to you a little bit about that as well. Performance results described. So we always have requirements. W I have a separate lesson on the twenty six requirements, probably as part of the course, and I talk about them in detail.

That is in fact the basis on which we develop it all. So it takes into account pretty much everything we need to develop. There, I don't know, the size of buttons. what function should be implemented within a given ticket, within a given task. These are all the requirements. And show that they are suitable for the stated purposes and for defect detection. So the stated goals that's usually let's say we're looking towards users

That is what the users want and what the business wants. Probably wants to because there are different business requirements and user requirements. That's exactly what testing allows us to check that we really. Claim that the data we have developed is fit for its stated purpose. Not the very purpose of testing, it is rather a consequence. First of all, we have to make sure that our product is developed qualitatively. And this is exactly what quality control and testing allows us to do.

I remind you that you can see the stick biglasari, just Google it. It is now made in such a way that you just open an online resource. Um there you can select any term, both in Russian and in English, and read what it means. In terms of here's the testing lifecycle, as you can see. This is from the Kulikov schema.

So we have a certain number of mandatory steps as S D L C. Here in the first lesson that you watched, I talked about the software development life cycle. So there is the same cycle specifically for testing, for a separate phase. That is we first analyze the requirements. And the general planning that is what concerns specifically how we are going to test according to the same. The requirements that we have, that is what concerns.

test environment we will use, what types of testing we will apply and so on. All this can be included here in principle. Clarification of acceptance criteria. It concerns specifically when we have already developed our product conditionally. What will be the criteria for us to say that yes, okay. it works, that is our acceptance testing again. Further on in the course you will learn what it is more. That is it is basically speaking in a enjoyable manner. Users or some group of individuals

Confirm that everything is working well for us. Testing strategy most often includes types of testing. Also further down the course there will be a separate lesson related to this. It is not included in the basic course, but you can find videos on the channel dedicated to testing strategy and test plan. It describes how we are going to test, that is, the types of testing that we are going to apply. That is we can also define them during planning.

And in the strategy they can be specified according to the fact that we have already started to work there and move to later stages of development and testing in general. Further, when we have already defined the plans and the strategy, we start working out test cases, that is, in fact, our tests. Again there will be test documentation and there you will learn what test cases are. This is basically our action plan.

how we are going to test this or that task. There's steps, meaning conventionally click on such and such a button, go to such and such a page. Test that it works well. There are results expected most often, actually rarely occur in test cases, but sometimes they do.

So in the expected results we write what we want to get specifically as part of the launch of this test case. We develop such cases or some other types of test documentation like checklists. They're more simplified and there's just a set of checks that we want to implement. Don't worry, we'll talk about this further on in the course, in a more accessible way. I'm just you know, that's the way I remember it now.

We have a lot of lessons on our channel, more than one hundred videos, and within the basic course there are only twenty seven lessons that you can watch. In general you will have a testing base and then it all depends on you whether you want to develop in this direction or not, whether you want to buy some paid courses or not, but the base that you need.

In principle, within the framework of the course you can master and then you can look at the market, what it offers us, because now of course is not so easy to get a job. Okay, let's get back to our sheep. And this is where the execution of the test cases, the execution of All of our tests. This is a separate stage.

As part of the launch of the test cases, as part of the testing itself, of course, we will find defects that is deviations from our expected result. Remember, I told you a little bit there that uh in test cases, this is what we want to get.

And what we get in practice is our actual result. And here it can be different, which does not meet the stated requirements, then it is There is a defect that is either a bug, maybe you you have also heard such a name, and we can also enter them separately as part of such documentation as a defect report, we enter them

into our system where it is all stored. After we have done the testing, usually it is near the end of some iteration. Iteration is basically a period of time. Of the time when we develop something, and they are constantly repeating these iterations as part of the development and work on our project.

Within an iteration, we usually analyze the results of testing at the end, that is, whether everything went well, whether we achieved all the criteria that we had there, for example, the acceptance criteria. There are also criteria for entering and exiting testing. You will learn about all this a little further on in the course. And then we can create some kind of report.

A report on the results of testing is most often called this. That is we say that here is our product, it conditionally meets some criteria. And we can say that hey, we can either give this product a five, there is a separate category, write down what risks there are, how many

Bucks we have found, how many cases we have written, analyze our work, collect metrics, and provide such a report, for example, to the customer or to the team so that they understand. In general, which is good for us, and so in general.

This whole process it loops and repeats itself. Some processes of course may not be repeated within an iteration. For example, there is general planning of requirements. Sometimes conditionally, uh we have planned something once and used this documentation further on in the project. It is always better to analyse the requirements, that is, we don't always have some new ones coming in and we have to discuss them too, that everything goes well.

Some definition of done, definition of ready. This can also be taken into account in the acceptance criteria, that is the criteria of readiness, the criteria of completion. Again, everything will be further along in the course, don't be frightened. That is, we have some criteria on the basis of which we can say that everything is good. They can also change from iteration to iteration, for example.

And so on, that is, we always write cases, we always find defects too. We also try to make reports once per iteration, if on a project. You have it, but there are not always reports, and in general we can say that they are not always. Appropriate, that is, you need to approach consciously to the choice of this or that test documentation on the project.

Whether it is necessary to implement it or not. They're at the initial stages, the final stages. A lot depends on the complexity of the project. That is, these are quite complex processes. Of course it may be difficult for a beginner, which you all are now, to understand all this.

But within the framework of your work, within the framework of further training, development, I think you're going to have a more conscious understanding of how this all works in the next lessons that we have in the course. Now a simplified term

As I promised the definition is from Kulikov. That is everything that you remember there was a big Comrad that We have collected here Frankenstein, it fits into a simpler definition, that is, it is the process of analysing a software tool and the accompanying documentation in order to detect defects.

and improving the quality of the product. It's very clear. It's basically the same thing here, so you can use a term like this. That is, you memorize a few definitions that you have heard somewhere, because at a job interview they sometimes ask for a few. Let's say variations on the theme. So don't be afraid, memorize, and always refer to some resource. A lot of people know Kulikov, so if you reference his manuals they will say okay.

Many people also know I C T B and if you refer, exactly to an international standard because it is an international standard. Consider it an international certification. Then also the probability that they will say that everything is wrong and that you are talking nonsense. It will be this probability will decrease. So please memorize the sources, it's important.

You don't have to memorize everything by heart, you can tell it in your own words, but in general. If there are any conflicts of interest between you and the interviewer, then it's better to link to some resource. To prove once again that everything works well.

But there are interviewers who are quite specific, who believe that they are right about everything, and of course it will be difficult to change their minds. The problem with people who have experience they are used to working according to one methodology.

according to one process that exists within the company. And they cannot look to the right and left, they see only forward. Within the framework of the project on which they are working, you have to fight with these two and a good interviewer he should Listen to you and accept even on a point of view if you can prove it. Here is another good example of I found this somewhere on the internet.

Software testing is a way to evaluate software quality and reduce the risk of software failure. It is also similar in principle, isn't it? This is what we looked at earlier. We will always evaluate some quality and reduce the risk that our software won't work at all. Another good point like that. And in general, definition is the verification that the results of a software product meet given criteria.

Or we can say that checking the conformity of the actual result to the expected result is the same thing. So you can remember this term too. Memorize a few, use them in your work. As for test goals, they are taken from Syllabus too, you can memorize a few. It's quite uh rare to be asked. At a job interview what testing goals there are, but still, if you know at least a few from this list, it will be better than knowing nothing.

So we evaluate our work products. We have requirements, user stories, design and code. That is in fact I have already told you what it is. It is at the beginning of the project for example. or at different iterations forms specifically what we want to see in the framework of our implemented functionality or product. User stories are one of the types of requirements. That is, they essentially consist of the fact that I

as such a user want to get such and such a function from the system in order to feel happy. These are user stories and many companies are now working with them, or they are also called user stories in English. Code design that is it is already more related to some architectural and development tasks. That is we can evaluate them too of course. Uh code, for example, in white box methods, when we have this code, we can see it and work with it.

Design perhaps if you have some architectural possibilities. And also all this can be evaluated. Whether all the requirements are met. That is, here we look at whether the result actually coincides with the expected result. Within the framework of our testing. Here we can also check whether the test object works as expected by users and stakeholders. Clearly, everything follows from the previous points too.

Creating confidence in the quality level of the test object. That is, we as testers declare that everything works well, or everything works badly, or everything works normally. And it is clear that our customer or a current user We'll understand that this product has been tested and we give him some confidence. Preventing the detection of failures and defects, it is clear that we are always working on preventive, that is preventive work.

With our product, with our processes, so that those defects don't happen. And understandably there are corrective actions when we have conditionally already developed our product and yet something went wrong. And we have defix.

We have to detect them, localize them, and then the developer's task is to fix it, providing stakeholders with sufficient information to enable them to make informed decisions. Of course, we create our reports as part of testing, send them to our team, to the customer, to the manager. And he also realizes according to this report that everything works well, reducing the risk level of non moving software quality.

Again, we as a tester and a separate testing team can reduce this level of risk because we test this working product and say that it works well or does not work well. And we can see some defects in time and tell you about them about them, the same the same reflex to draw up. Compliance with contractual, legal, regulatory requirements or standards, or verification of compliance of the test object. Well, in addition to the requirements that the company makes, or the customer specifically, to the

Software that we develop, it is clear that there are also some contracts, legal norms, the same international standards, which also stipulate how it should work. So we should also pay attention to that as part of testing. and check that our test objects are in line with them. These are all test objectives taken from Silo.

Uh twenty eighteen version is the most recent one. You can read it as I said, it is in Russian, in English, as you prefer so read it. For those who do not have very good English, it may not be very clear what is written in the standard, so more precisely in the preparation program for certification, so you can read in Russian.

There is also such a term as debugging, and sometimes testing and debugging are confused. See what it is. Debugging you may still have heard is the same thing. It's a development activity, so you see right away it's development we have here, not just testing, to find analysis. And fixes for such defects.

Subsequent confirmatory testing verifies whether the corrected defects are fixed or not. So you see, here we are, not only finding defects as part of testing, for example, we can do that. And we can say that testing is part of debugging, but we still analyze them. In principle, testing also allows us to do that. and and fix them. But of course we cannot fix defects like this. That's why they say about development. That is, it can be some automatic methods.

Of searching for these defects and fixing them, or it can be the same manual testing. Or uh the developer himself who does code review or something else that is uh he can find bugs too. And so this whole process of finding, analyzing, and fixing all together is debugging. So do not confuse testing and debugging, they are slightly different things. We can say that testing is a part of debugging, but we cannot say that testing is one hundred percent debugging.

because we cannot fix the defects themselves within the framework of testing. And it is clear that we in this. Confirmatory testing or retest it is also called maybe you two, more precisely impossible. It is accurate to hear and further on in the course when we see that we have introduced a defect

it and we check it that it was really fixed, a fix was made, a correction. This is a retest. That is, the retest confirms that everything works well for us. Next. Look, we have this hierarchy of testing, quality control and quality assurance. In fact, they are all interconnected. And some of them are conditionally included in testing.

Testing, for example, is part of quality control as well. But you cannot say that testing and quality control are related to quality assurance. They are slightly different things. I will show you on the diagram below.

Earlier in my course I said that quality assurance comes first, it absorbs quality control, and quality control absorbs testing. Quality assurance ends up including generally all activities that can be related to testing. That's not really true, and that's what the HTTP standard tells us.

It's more about management already. Quality we're going to talk about that as well. See what the glossary tells us again that quality assurance is a set of activities designed to assess the quality of a component or system. Look at once. We work specifically with the product idea.

We control the quality of this particular product. We do not work with processes. We have another project for processes. Is not a project but a process, remember this too, and testing also works specifically with the product. It does not work with processes.

I also wanted to point out that in our geolocations quality control, testing, and quality assurance are sometimes separated from each other. So whatever you see the following. Vacancies, they write key engineer, but in fact they want to hire a tester. But There are testers, there are QC specialists, and there are QA specialist. And they all do different things. Yes, most likely you.

Start as a tester, you work with the testing process, then you grow up to a middle, you get involved in quality control, and then you can get involved in quality assurance and control processes and participate in their improvements. It also happens sometimes they make such a comparative characterization that June is a tester, the middle is A QC specialist who is a senior lead is a QA engineer. But it's not. Quite right. You just need to understand that we have this division.

and sometimes even testers can work there for five years as a tester and not grow up to Q and A. Or they're Middle senior specialists can work there only as quality control of a particular product, but not grow up to QA specialists and to deal with processes inside the company.

It's all normal, it happens like that, but in our geolocation for some reason they separate people. And then, unfortunately, when you come to work, they hang absolutely all the activities on you without looking to who is who at all. Although in fact, every single person should be responsible for their function. Going back to quality control, that is, you see here we already have quality assessment of a components or a system.

That is testing. If I explain it to you on my fingers, we have some written documentation, we have test cases, we just run them, we get some reports on defects, and this process is repeated. We work with the finished product. Test documentation and perform routine operations. Quality control is a little bit higher. That is here uh you are not just joining in this routine work, so that you are given some product and you check it. But you are also involved in analyzing in general.

The quality that this product has formed within the framework of collecting some metrics, within the framework of forming reports on defects, you are involved in the work on. Writing some kind of test strategy because newcomers most often do not do it. And testers too, they can somehow influence what we get at the stages of strategy and planning because they will generally test it later. But here is the difference. Quality control. It solves such high level tasks and of course including

is involved in testing. That is, he tests the finished product according to test documentation, test cases, checklists, and receives defect reports as a result. He does this too, so quality assurance includes testing. And quality assurance, look at the difference here. So this activity is about providing assurance that the quality requirements will be met.

See, it doesn't say we're talking about any product here, we're talking about having some quality requirements. In other definitions, if you read somewhere it says here that these activities are aimed at ensuring improving process. Ensuring quality within the company. That is, we are already working on the processes. That is, we are not just testing something there, the finished product, but we are analyzing what we have going on. How the testing department works, how the development department.

As requirements are collected, we offer some preventive warning activities to improve these processes so that we don't have defects in the future. So maybe we are there. What we do is we come up with some new test documentation. that will be effective for this product, for this project, for this team. We look at the development there and realize that, aha, we have a delay in rolling out a new product because the developers there spend a lot of time on code review.

Code review is an activity that is aimed at reading someone else's code and saying that yes, okay, it works, and you can continue to run it somewhere in the process. And this activity delays testing there, so we have to somehow change the situation, speed up the code review, and make everyone happy. And testers and developers tested everything in time.

So you see these are activities that are already aimed at making sure that we really have everything working like clockwork within the company and within the team. Here QA engineers deal specifically with this task more. So don't confuse all these three activities testing, QC and what us have left, quality assurance, those are slightly different things. Yes, there is QC and testing they are related, but quality assurance is something else altogether.

Quality assurance. Quality assurance is focused on process, QC is focused on Products just like testing. This is all from the TKB glossary as well. And in general I advise you to refer to Salaboss, because there it is more concretely written down, that you can tell there conventionally about these processes.

Here's more from Elevos, by the way. See here we have a distinction QCK which is quality control. Includes various activities, including testing activities that support the achievement of the appropriate level of quality, and quality assurance focuses on following the appropriate processes to provide assurance. that appropriate levels of quality will be achieved. So you see we have slightly different things here. We are responsible here conditionally in maintaining our quality level.

And testing work is included here. Quality assurance says that we have to achieve the appropriate quality levels. We don't just maintain them and work on the processes that we have within the company. That's the difference too. It's worth remembering. And, as I said, we also have a fourth category that combines all these things.

This is quality management, quality management. It is the coordinated management and control of an organization with respect to quality, which includes setting quality policy and quality objectives, quality planning. Quality control, quality assurance, and quality improvement. You see, it says here that quality management, well, yes, in principle it should sound normal, it includes quality control and quality assurance.

That is, we include all these processes, including testing, because testing is a part of quality control. That is already such a comprehensive comprehensive, let's say, requirements, requirements of the process, a set of actions, as it is written here, which are aimed at the fact that we have already

Establish some quality policy according to which the company works, quality objectives which say that we must achieve some kind of quality goals, that our product should be super mega class, that we should not have any critical defects. That we should automate one hundred progression tests and smock tests. We talk about them uh in the course. All of that.

is included in quality and it is such a superstructure. That is why they are also quality managers. You can also meet them in companies. They are more uh focused on quality assurance, but they also put their hand in. Speaking in a enjoyable manner In the work of quality control and testing

And here is a scheme so that it would be more or less clear. We have quality management, which combines quality assurance separately, quality control and includes quality control testing. Here, it would be a more correct scheme in comparison with what they say.

And I once said that quality assurance includes QC and includes testing. So it turns out to be a kind of a Matryoshka doll, but it is not really a Matryoshka doll, it is like this. The dichotomy comes out of our quality management. Anyway, there's a lot of things that we've covered within those terms and definitions.

And I also wanted to tell you today about validation and verification, because that was also part of the third lesson, which is not available right now. So these are also separate processes. And you can see these processes in the standard international ones. There is ISO nine thousand one, for example, in some hundred percent it is written about all of this, about verification and validation. Look at the difference between the two. Read the definition carefully.

According to the glossary, verification is proved by objective research that certain requirements have been met. That is, we confirm that some requirements that we wrote there, that our product should work in this way, have been met. This is the main thing that verification

We will understand it further with examples, it will be clearer. And validation is a proof by objective research results that the requirements for the expected specific use of the application have been met. See the difference? There were just requirements, they were met, everything is okay. But here we are also checking some specific use of the application from the user side.

That is, it is not enough for us that all the requirements are met, which were written down on paper conditionally. We still have to prove it. That these requirements meet the user's expectations, that he will receive the system and will be able to perform his functions, and that he will be satisfied with everything. So we will discuss this further with you in a moment, remember. Validation is focused on the requirement, validation is focused on the user's expectation.

You can also pay attention to this, they often talk about it, that is verification is more because this is a requirement that was formed by a customer and we helped him to do it as a team. Their analysts have written these requirements. We have them in line with the right customers, what the customer wants to see. And we are talking about the fact that when we test for example and carry out this verification process, it says that we are doing the product correctly.

That is, conditionally we say that we meet all the standards, all the requirements that our customer conditionally imposes on us. and that we together with our team have defined for a particular product. And validation already says that and no the needs of the customer, okay, they are there, we know about them, but we have a user. We want to sell something to him. And these needs must also somehow meet the needs of the customer. So the user's needs are covered by validation.

And here we already answer to the product, whether we are making the right product. That is, we say that this product really meets the expectations of a particular user, that he will be happy to use it. Work with it and there won't be any problems, even though we have developed everything there in a kind of correct way. Sometimes it happens that something does not suit the user. I will also tell you further on with examples.

So you see verification we have some kind of bicycle conditionally. There is a Requirement, not a test requirement, but a technical specification where the required color, size, details, materials, all this is described within the requirements for this bicycle. We designed it, yes it is, it works, it rides.

its seat is made of leather interior, there are cool spokes, there is something else, the frame is made of stainless steel and so on. We adjusted everything according to what was in the requirements. But look what a problem. It turns out that this bicycle was designed for children and little ones. Up to three years old, who can still hold a two wheeled bicycle normally, And they need a three wheel bicycle, that is not a two wheel bicycle, but a three wheel bicycle.

And here we are already talking about the fact that we have not taken this point into account. And we do not meet the needs of our specific user, specifically this girl who is three years old. So okay. We have developed according to the requirements that we have, everything works well. But it turns out that our target audience is not only other people who are older, their children, for example, of teenage age.

But it turns out that this bicycle will also be bought by a little girl, or rather by her parents. And here we didn't take that into account. This is the validation right here. Verification meets the requirement, validation meets the needs of the user. As for some application, let's go to Understandable to the tester as well, we have some form a form for registering on Yahoo.

So I took this form, copied it, and here we have all sorts of different fields. We here can compare what we have on our final layout, what we see on the front end, what we see on the back end, what we see in the browser with what we had in the design.

There are all sorts of layouts that the designers draw and they also spell out how the same places should look like. We can also look at the requirements where it says that yes we have to have fields there for name, for email, for password, for your year of birth. There has to be some buttons. We can read that too. We can look at that form. Yeah, everything's cool. Everything meets the requirement. You see? Testing a component of the system to see if it meets the requirements. Okay?

The finished version matches the layout, okay we're testing that we have the water fields, that's okay too. As if everything works, we can enter some positive values here, that is those that go. Are correct, valid, correct. These values we can enter here, click, continue, everything will work. And then it happens that we have some fields that are mandatory, fields that accept.

Only numbers, letters, fields that they're I don't know. What else can be what else can be there? Some capture appears, appears. Conditionally restrictions on uploading a picture up to a certain size, not in this form but in general so that you understand. That is, we are already validating after entering some different characters in the water field.

We have a positive case, we have entered everything, everything works well, but there are some specific cases. Our user wanted to enter, I don't know, some kind of a script, some malicious code into our system, and the system should work in such a way. There can be all kinds of cases. Checking that the user really needs this functionality is the second point. That is, besides the fact that we have checked some eight typical cases if the user has set or not set some.

But has done something differently than we intended, and this is also validation because in principle the user's needs they are here now as if they were in plain sight. But we also check that it is really necessary. For example, we also develop some new functionality for what? For some system. Real estate rental. We developed a super mega functionality that gives us a discount after we check in fifteen different apartments there, rent and so on, and gives us a discount there five.

And we realize that geez, what's this user feature for? That is, imagine fifteen needs to rent some apartments in different cities. Maybe there is such an additional condition. While a person will get to this discount five, he will basically forget and will not even look at the fact that he has this discount. This is just a validation. If we had conditionally conducted everything correctly, evaluated and

Realize that. The user in principle does not need such a function, or it is needed, but in a different form, to reduce to five some rentals and perhaps the discount to reduce to two if it is so miserable. To give that money, then yes, that's when everything would be fine and the user would use it.

That is we can carry out validation already. After we have launched our product to see how this function works and whether it really meets the user's expectations, or we can think about how this function will work and whether it is really necessary at all, in advance, speaking in a enjoyable manner.

This is validation. That is remember, verification, what is specified in the requirements, what the customer needs and what. We are talking about whether we are doing the product correctly. And validation says Okay, we did the product right, we looked in the requirements, but the product itself came out wrong because we have conditionally what happened. Conditionally our tricycle didn't work out for a three-year-old girl. Our discounts don't work for users. Here's the validation we failed.

That's something to remember about verification validation. That is, today we have considered a lot of concepts that occur in testing. And to give you a little bit of an idea of what you will be working with, most often beginners work as. In the field of testing, testers work with ready documentation, perhaps they write something there too, all kinds of test cases, checklists.

Defect reports, yes, they create all that. Further on they grow in experience, they have more. Highly loaded tasks and quality control becomes involved. Further, as a specialist who understands how everything works, you understand how you can advise within the process, within the company. Whether everything works well and whether something can be improved.

And already some college activities, adjurants appear and further you can grow up to a manager and conditionally manage everything that happens there, manage, come up with quality policies, quality objectives. to implement them and so on. And we're already talking about management of some sort and quality management.

and quality management. And as for verification and validation, we also work with verification and validation in our projects most of the time because we also have forms that work incorrectly. It is not exactly our task to evaluate how A specific user wants to see our software. It is more the task of analysts, product analysts, that is people who are engaged in. For those customers who collect the requirements in the work plan and form them.

that's more their job to analyze the market and understand how it works. But we can also look in, we can do some analytics, and we can also realize that Everything is wrong everything is wrong. I hope this lesson was useful to you. It is updated and the rest of the lessons that will appear within this course you can find on udemi.core. Or in the junior package. They will not appear here because the information that is on YouTube is basically up to date. I mean, there are some flaws there.

But the base is always the same everywhere. So there is no point in a complete rewrite of the course. If there is something critical there, I think that it needs to be done Specifically for YouTube, I will do it. So watch this course, there are only twenty seven lessons, and further on the channel there are other videos that complement what you learn in the base, and I recommend you to watch them too.

Because a good tester should know a lot of things from different areas, including not only testing but also project management and creating test documentation, non test documentation, general documentation, some strategies to Understand planning and including processes, that is all on the channel. I have tried for these two and a half years, uh or how long we have been doing this.

Yes, two and a half years, soon it will be three, to include a large number of different videos on different topics, I think. You're all going to find it useful. Anyway, subscribe to this channel. Don't forget about my other communities that you can find links to in the description of this video. And I'll see you guys very soon. Bye guys. Hello YouTube.

Today we are starting a big and very interesting topic related to the classification of testing. There are a huge number of variations of this system, so don't be surprised if you find differences in different sources. Let's start with the typification of testing by levels at which it is conducted. There are three in total. The first one is component, module, or unit testing. In different sources it may be called differently.

The second level is integration testing, and the third is system testing. From the names of these types of testing one can assume what is being tested at each of these levels. At the component level, individual modules are tested. For example, if we are talking about an online store, then this would be testing the shopping cart or testing the payment of an order.

At the integration level, the interaction of these modules is checked and at the system level the full check of the application is carried out. Usually unit testing is done by the software code developer. As unit testing allows testing individual components of the program's source code. In the example of an online store, such modules could include the authorization page, product search, moving it to the shopping cart, payment of the order.

As for integration testing, it involves testing a part of the system consisting of two or more modules, for example, how we can make a payment from the shopping cart page using a payment system. There are two types of integration testing. Let's talk about each of them. Firstly, it is the testing of component integration. That is, how individual modules of one application interact with each other, and system integration testing.

Which means testing the interaction between all component systems, or the interaction of different systems with each other, or testing the interfaces through which the system interacts. It is about the interfaces that I want to talk about in more detail. There are three types of interfaces. The first of them is the application programming interface or API.

It is a set of methods that can be used to access the functionality of another program. For example, an API is used to implement a certain payment system for a particular resource. again take our online store. For this, the developer establishes integration with this system through this interface and he does not need to develop his own payment system. There are a huge number of such APIs.

The most famous of them is the API for interaction with social networks, like Facebook or VContact. We will talk more about APIs in the module on web application testing. The second interface is the CLI or command line interface, where computer instructions are given by entering text strings from the keyboard. Simply put, it's the usual command line in the Windows system for example.

And the third interface is the GUI, graphical user interface. In it, program functions are represented by graphical elements of the screen. For example, this is what we see in a browser window when we open a page on the internet. So we've talked about component and integration testing. Let's now talk about system testing. System testing is performed on a full integrated system to verify the system's compliance with the original requirements.

For example, if we're talking about an online store, then Here we will look at how all the modules that were developed for the store work together. Whether it is possible to go through the entire business flow of this application, that is Whether we can register, find a product, put it in the cart, pay for our order. Track this product on its way. That is, we are testing the entire application as a whole.

And of course, speaking of testing levels, it is also worth mentioning acceptance testing. I will include it in this classification as well. What is acceptance testing? It is a type of testing conducted at the stage of delivering the finished product or its ready part. To the customer The purpose of acceptance testing is to determine the readiness of the product, and this is achieved by passing test scenarios.

Cases that are built on the basis of the specification and requirements for our product. Essentially it is the final stage of product testing before its release. Usually only the main functions are tested which do not require thorough check. There are several types of acceptance testing that also need to be known. There are several types of acceptance testing. Let's talk about them in more detail. Firstly, it is user acceptance testing. or UAT. User acceptance test.

Get used to calling all types of testing in English, as you will encounter English abbreviations or definitions in the future. User acceptance testing is conducted by users of the end product. For example, When we know that our product is ready for release, then we can gather a certain group of end users who test it to see if this product really meets their expectations.

Give us some conclusion. We will fix some critical bugs and we'll be able to release our product calmly. The next type of testing is operational. Usually this testing is performed either by users or by an administrator in an environment that simulates the real conditions of the work environment. At this stage, backup testing or emergency system recovery as well as its security are carried out. Another type of acceptance testing is contract compliance testing.

This testing involves checking for compliance with the spec or some other document regulatory act. For example, there is a standard in the country that defines how our product should comply with this regulatory legal act. That is, it defines its some basic key feature. Uh we must necessarily develop the product in full compliance with this regulatory act.

Or one of the most famous documents which was adopted not so long ago is the GDPR, which defines the requirements for the protection of user data, sensitive data. And if we do not take these requirements into account when developing the product Then we can receive huge fines in the future. And two more types of acceptance testing are alpha testing and beta testing. Alpha testing represents operational testing conducted on the side of developers.

And beta testing, unlike alpha, is conducted entirely on the external side and without the participation of developers. Usually beta testing is conducted by a small group of users to get feedback from them before the product enters the market. This is a known practice for computer games. I think that those of you who are avid gamers know about such testing. That is, the customer selects a certain key group of users and releases a beta version of the product for them.

And based on their feedback that is feedback critical bugs will be fixed, or we will just understand that our product meets their expectations and it can already be released. Also today, I would like to pay a little attention to the issue of classifying testing by the positivity of test scenarios. It is logical to assume that there will be two types of testing positive and negative testing.

what is implied by each of them. Positive testing is such testing where scenarios are applied that correspond to the normal expected behavior of the system. With its help We can determine that the system does what it was created for. For example, if we take a calculator or Then when adding two plus two we will get four. This will be a positive test. Negative testing is called testing in which scenarios are applied that correspond to the extraordinary behavior of the system.

For example, these can be exceptional situations or incorrect data. In the example of our calculator this can be division by zero, so we know in advance that dividing by zero is not possible, that is, we should get some kind of error message. Many novice testers are mistaken in thinking that negative testing should be done first, that is, try to break the system.

This is far from the case. Positive tests are performed first, especially in a time-limited mode. And the time for testing is always limited. Just imagine how the customer will feel if you focus all your efforts on performing negative tests, but do not check the main functionalities and their work with the stated requirements. And hand over such a product to the customer, imagine his reaction when he simply cannot log into the system using valid data. While you intern, only checked.

Nine thousand nine hundred and ninety nine characters in the login line. Today we learned about the main levels of testing and their significance for the entire quality assurance process and touched a little on the topic of positivity of scenarios. In the next lesson, we will continue studying the classification of testing. I think there will be several more lessons like this because To fit everything within.

Ten fifteen minutes is simply impossible. And as always, I hope you found this video interesting and that you really learned something new for yourself about testing. If you still have any questions, then do not hesitate to write them in the comments. I will try to add my feedback. And don't forget to like and subscribe to this channel. So I will know that the work was not in vain. Welcome to our hut. Bye.

Hello YouTube, glad to see you continue learning about testing classification. Today's lecture will start with the types of tests by the importance of the functions being tested. There are three of them, these are smoke testing, critical path testing, and extended testing. Type number one is smoke testing. In English language resources you can also find such names as intake test, build verification test. In general, it will all depend on the source from which you will

Draw your knowledge about these types of testing. Smoke testing is conducted at the initial stage. For example, after a new bill. A build is an intermediate version of our product. And primarily smoke testing is aimed at checking the readiness of the developed product for extended testing and determining the overall state of the product's quality.

Usually it's a short cycle of tests, or even just one test, which confirms or denies the fact that the application starts or performs its basic functions. Taking our beloved online store as an example. Smoke testing is one test case when we log into the system, search for the necessary item, add it to the cart, make a payment, confirm it, and receive our order.

So all these steps can confidently be included in one test case and if it passes, that is, the expected actual result is the same and we receive our product. When the smoke testing is considered successful, there are only two possible outcomes for a smoke test. We can say either. Yes or no. If we say no that is our test fails, then further testing is not conducted.

We send a bug to the developer and completely stop the testing process. It is worth noting that smoke tests should be quick and lightweight so that they can be run very often. A fun fact how did such a name as smoke testing come about? There are at least two versions that I know of. One of them is the version about stove makers. That is, when stovemakers finish building a particular stove,

They would light a fire in it. And if smoke came out of some holes which were supposed to be sealed. Then people understood that some construction or design process of the stove was violated. And the second version is related to circuit designers, that is, when they started some machine or supercomputer. If the board started smoking after some high load. Therefore, this type of testing got such a name as smoke testing. The second type of tests by importance is critical path testing.

What is it? This is the main type of testing during which significant elements and functions of the application are checked for correct operation during standard usage. That is A typical user in typical everyday life performs their typical tasks, and it is exactly these typical tasks that we check. Most often in practice, this type of testing checks the bulk of the product's requirements. For example, this includes font selection, the ability to type text, insert images, and so on and so forth.

Critical path testing can be both positive and negative. If you forgot what positive and negative tests are, a link will now appear above which you can follow and refresh this knowledge in your memory. And the classification ends with the extended test or extended test. This testing implies checking the non standard use of the software product. For example, if we enter special characters in the login field.

Or illogically click on buttons, work on many tabs simultaneously, that is maximally load our system or perform some. Invented negative tests. This is what I wanted to tell you about the tests by importance. Now let's talk about. The types of tests by the goal of testing and we will start with new feature tests. or testing new functionality. Essentially this is checking the quality of new functionality put to the test.

And usually the new feature test is tested with a full test. That is, it goes through all stages, starting with smoke. Then critical path testing and ending. With extended tests. Testers virtually every day encounter new feature tests, that is essentially new functionality comes to testers during some sprint. We will talk about sprints a little later, when we discuss such an agile methodology as agile.

For initial understanding, you should imagine that a sprint is a certain period of time during which the team delivers some new functionality to our customer and presents it. And it is in this print that new features, new functionalities, which will later be tested as part of the new feature test often come. And probably here it is worth noting the most important type of testing.

Which takes up the most time for testers. This is regression testing. What is regression testing? This is testing previously verified functionality to ensure that changes in the code For example, adding new functionality or fixing. A defect did not affect the operation of the old functionality. Regression testing can be conducted at the level of smoke, critical path and extended. I want to go into more detail on this type of testing because often

In interviews you may be asked about some of the pitfalls associated with this type of testing. And in principle, in order for you to have some understanding of why this type of testing is so important in our work. Is this type of testing necessarily conducted in every new build if it comes to automation? As you remember, a build is an intermediate version of our product. This type of testing can include checking fixed bugs.

And their degree of impact on the entire product or on some specific functionality. And you need to understand that regression testing usually does not cover all applications. But only those areas that in one way or another come into contact with changes in the build. For example, if we talk about the page. User authorization in the system, then if suddenly some change was made related to password reset, usually these two functionalities login into the system and password reset or

Its recovery are interrelated. Therefore it is mandatory in the case of such changes to check the interrelated functionalities. Also, regression testing is as recommended to be conducted several times. And since there can be a lot of functionalities in the application, regression testing is very often automated in order to save time for testers, and generally time for testing. It should be noted that the final regression tests in this large cycle, consisting of three to five regressions,

are usually determined after setting some priorities. And the priorities in turn are determined by the largest number of errors found in the system. Often in an interview again they may ask how to select tests for regression. There is a very simple algorithm that I will tell you about. First of all, in regression, you always need to include tests that cover testing of security or some critical important functions for the business.

It is necessary to include in the regression those areas that change most often during development. Also, from one of the principles of testing, another principle of test selection for regression follows, that it is necessary to include tests of functions with a high probability of error.

By following the link above, you can familiarize yourself with the basic principles of testing and write in the comments which of the principles this statement relates to. And let's talk about another type of testing, such as retest. This is checking the result of work on a defect, checking the correctness of defect correction. That is, when a developer sends you an already fixed bug. Then you conduct a retest, that is, you make sure that the developer really fits.

The defect and the functionality actually works as it was intended in the requirements. Also, retest is sometimes called defect and functionality. Validation. This is the lesson we got on the classification of tests by importance as well as by the goal of testing. I hope that this class was interesting to you. If it really was, then support this video with a like your subscription if you have not yet subscribed to this channel.

Possibly a comment or a question if you have one after watching this video material. And I in turn want to say thank you very much for your support and kindly ask you to shack. Bye!

Hello YouTube! Today we are going to be finishing up our topic on learning about test classification. It's going to be quite lengthy, so make sure to plug in and listen carefully. I really hope it will be useful for you in the future. Let's start perhaps with such a typification as testing by the degree of automation that I think it's no secret to you that there are two types of testing in terms of automation. They are

Manual testing which we are studying in this course and automated testing. In manual testing, testers manually execute tests without using any automation tools. Automated testing uses special software to control test execution and compare expected and actual results. It automates repetitive tasks to maximize test coverage.

The primary targets for automation are regression testing, which consumes a significant amount of time and involves the repetitive execution of tests we have already performed. And smock testing which is conducted initially. If you need a refresher on this, please refer to the previous lesson, where I discuss this type of testing in detail. There is a common opinion that automated testing will completely replace manual testing.

However, this is not entirely true, as not all functionalities can be thoroughly tested solely by written, automated tests or scripts, that's why manual developers will always remain relevant. And there will always be work available for them. Nowadays it has become quite popular to have hybrid teams, which means having both manual and automated testers working together. For example, sometimes manual testers write some test scripts.

and give them to automatizers who later write a consistent program code, a script, and perform these tests. In other words, we get a kind of symbiosis between manual testers and automatizers. The second issue I would like to address in this class is the systematization of code knowledge testing. There are three distinct types of code knowledge testing that we need to consider. These types are known as black box testing, white box testing, and grey box testing.

Black box testing or black box testing. We don't know how the system under tests is organized. You may also find names for this testing such as specification-based testing or behavioral testing. What does it mean? It is a testing technique based on working exclusively with the external interfaces of the system under test. That is, we don't know the program code at all. An example would be when a tester tests a website without knowing the specifics of its implementation.

Using only the fields, water, and buttons provided by the developers, the source of the expected result will be a specification. That is, we are only testing the GUI, the graphical user interface. Unlike black box testing, white box testing or white box testing. is the following. We know all the details of the implementation of the tested program. That is, it is such a method of software testing that assumes that the internal structure

its design and implementation are known to the tester. An example would be when a tester Who is usually either an automator or possibly a programmer, examines the implementation of the input field code on a web page. determines all the intended, both correct and incorrect, user inputs, and compares the actual result of the execution of the Program with the expected one. In this case, the expected result is determined exactly by the way the program code should work.

And the last type of testing by code knowledge is gray box testing or gray box testing. Here we already know only some peculiarities of the implementation of the systems being tested. This is such a method of software testing, which implies a combination of the two previous ones. That is, we know the internal structure of the program only. partially. For example, we know The internal structure and algorithm of software operation in order to write the most effective test cases.

But the testing itself is conducted using the black box technique, which means taking the position of our end user. This brings us to the most fascinating part of our lesson today, functional and non-functional testing. So what is it? Functional testing is one of the types of testing aimed at verifying. That the functional requirements of the software match its actual characteristics. The key point here is functional requirements. Essentially, we are testing what our system actually does.

The primary objective of functional testing is to ensure that our product under development includes all the functionalities that the customer needs. This type of testing is conducted at all levels, and as I mentioned earlier, it verifies what the system does. Unlike functional testing, the purpose of which is to check whether the real product function corresponds to the functional requirements, as you have probably guessed.

The purpose of non-functional testing is to check whether the application properties correspond to its non-functional requirements. That is, in this type of testing, we are testing how our system works. In essence it is testing of properties that are not related to the functionality of the system.

These properties are determined by the functional requirements. Such a property can include, for example, reliability, which refers to the system's reaction to unforeseen situations. In this case, testing methods such as failure and recovery testing will apply to this particular property. In English, it will be referred to as failover and recovery testing. This means it is an examination of a program system's ability to recover from errors and failures,

The second property to consider is performance, which means the system's functionality under various loads. In reality, performance testing encompasses a vast array of skills and tools. Therefore, there are specialized testers who focus solely on this type of testing. That is, if you are interested in it, of course you can go to specialized courses, study, read special literature, and uh use already performance testing techniques in your practice. What is it?

Performance testing includes various tests. Aimed at assessing an application's performance, stability, resource usage, and other quality attributes under different scenarios and loads. Additionally, performance testing itself can be categorized into several specific types.

In load testing we check the performance under normal conditions. That is, if it is stated that a thousand users should be present on the site at the same time, we create such special conditions, for example. In the GMeter program, When we load our system with a number of users, which will probably be a little less than this thousand.

and ensure that everything is truly okay. During stress testing, we evaluate the performance of our system under extremely heavy loads. For instance, this could be when there are thousands of users accessing the site simultaneously Or perhaps even more. Stability testing involves examining our application to see how it performs under extended periods of operation.

I believe there's no need for an explanation here. Volume testing is distinguished by the fact that we evaluate our system under conditions with increased volumes of data being processed.

That is, for instance, when the same thousands of users simultaneously send an any number of megabytes of information. Moving on to the next non-functional property, we can refer to convenience, which is essentially the study of the usability of the application from the user's perspective. This aspect can be evaluated through usability testing, meaning conducting usability tests.

The usability check of the application involves evaluating the conformity of the application's design with its functionality as specified by the customer. Additionally, we investigate the graphic elements used and the color designs in terms of how they are perceived by our users. We also assess the ease of navigation and the links present on the site. Analysis of the textual content of the site.

There is also such a characteristic as learnability. For example, if our user for the first time went to a resource, how quickly he can figure out how to use it. For example, on some previous experiment when he used Similar application from our competitor. So if we don't take all of these aspects into account. the user will most likely move on to our competitor if they suddenly find it inconvenient to use our product. This type of testing is very common nowadays and it holds significant value

Furthermore, there are distinct groups of testers, specialists who concentrate on usability testing. There are also specialized courses that enable you to learn these techniques thoroughly.

Another important property is security, specifically the security of user data. These are also quite extensive and crucial areas of testing.

There are once again specialised testers who focus specifically on security testing. These are distinct areas. For instance, in this context we can examine how accessible the system is to an unauthorized user or how simple it is for an authorized individual to gain access to the data. Security testing involves various methods and strategies to ensure that the system is protected against potential threats and vulnerabilities.

It's crucial to understand the different aspects of security testing to safeguard the integrity and confidentiality of the data. Here, we thoroughly test how the security of our software product is realized. Another important property we examine is portability.

which means the ability to transfer our application to different platforms. In this context we can utilize various types of testing, such as installation testing and configuration testing, Regarding installation testing, we verify the success of the application installation, its customization, updating and uninstallation processes.

When it comes to configuration testing, we examine the performance of a program system under various program configurations. Additionally, cross-platform and cross-browser testing fall under this category of testing. I think it is not necessary to explain in great detail here what it is. I think it is clear to everyone.

Cross-platform means that we test our product on different types and versions of OS. For example, if we are talking about a cell phone, it can be Android or iOS. And also in cross-browser testing we use our Application on different browsers, be it Chrome, Mozilla, or Opera. We should also talk about localization testing and internalization testing. Very often you can find such abbreviations as L10N, I eighteen N, that is

Do not be frightened if you see them. Perhaps there will be some testing somewhere at the interviews or you will be asked how you can abbreviate these names. Just memorize it. These are basically abbreviations for their English names. As for localization testing, it's the process of adapting our software products to the language and culture of the client. For example, if we are entering some other market. For example, uh an English-speaking market.

Then, we have to verify whether our product is completely translated into this language. Or perhaps there are some financial designations used there, for example, the pound. We need to check that as well. We can also incorporate control of format, date and time, legal peculiarities of the state we are entering, user keyboard layout, control of symbols and colors, and other aspects that might be related to this or that locale. on which we will present our product.

Unlike localization, internationalization testing also covers how well our product can be adapted to specific locales. For instance, when developing a product, We need to consider the potential for Unicode encoding. This is a standard that supports nearly all languages globally, and it's crucial for ensuring broad compatibility. Or we must include in the application the possibility of supporting elements that cannot be localized in the usual manner.

For instance, it could be vertical text in Asian countries or reading from right to left in Arab countries. That is, even if we do not currently use our application in Asian countries, for example. We still need to envision that in the future this application can enter these markets as well. So we have to test internalization as well.

There is also such a gradation as script execution testing. Sometimes in interviews they ask, for example, what is ad hoc testing? And not everyone can answer this question. Let's understand a little bit what it is. Here we can distinguish two types of testing. These are exploratory testing and Ad hoc testing. Ad hoc testing is testing without using any specifications, plans and develop test cases.

It is your pure improvisation, that is, for example, you have received an application for the first time, and on some empirical intuitive level you understand. How to work with it? Exploratory testing as opposed to ad hoc is a more formal version of testing. It doesn't require writing test cases, but at the same time it implies that each subsequent test is chosen based on the result of the previous test. Or if you know how your application works, that is, it is not the first time you see it.

Then you can also follow some kind of plan without necessarily documenting it. That means you know the expected result in a module and you test it, but you don't document it formally. The last one is scenario testing, which is our classic testing. By pre-written and already documented test scenarios. There's also such a classification as by running code. If you remember the lesson about verification and validation.

We talked to you that verification is a static check and validation is a dynamic check. This applies to this classification as well. That is there is static testing and dynamic testing. In static testing. It is not assumed that the program code will be executed during testing then. We don't start. Static testing starts at the early stages of the software life cycle and is a corresponding part of the verification process.

This can include testing of any form of documentation, such as code, deduction, inspection of design documentation, functional specifications, and our requirements. Dynamic testing involves launching program code to analyze its behavior while running. For non-functional testing, there's also GUA testing. Thank you. Thank you.

That is, it is checking whether the application complies with the requirements of the graphical interface, how professional it looks, whether it is made in the same style, that is. Whether the buttons we have on the mock-up are in the same place, that is In the template provided by the designer. That is, we check all this when testing the GUI. And uh is also such an interesting area as accessibility testing.

Or in English it sounds accessibility testing. That is, here we test the compliance of software with generally recognized accessibility standards. It must be accessible for use by people with disabilities. There is a separate document that regulates how our application should be accessible for such people. Again, this is a separate area of testing, so I will not dwell on it in detail.

But it's a very interesting one. It's worth noting that a lot of people have the misconception that people with disabilities must have some kind of health problem that prevents them from using our software. In fact, this is not quite the case. Such people, for example, can include those who, for example, are driving in a car and concentrating on traffic.

That is looking at the road, but at the same time he is using some kind of gadget. That is, he is limited in his abilities, he cannot. See that? Happens on the screen of her smartphone, but can for example here. Or if a woman has a child, for example, she holds it in one arm and uses again our gadget, a smartphone, she has to use only one arm. This limits her movements.

We must consider that possibility too. It's not always people with disabilities who face health issues. This final session on classification and testing is extensive. Initially I thought of splitting it into several sessions, but I realized we had already covered this topic extensively. So I hope you found this interesting. If you have any questions at all, be sure to ask them in the comments below. Also, don't forget to subscribe to this channel and put your likes.

Your support is very important to me. And that's all for now. Welcome to our tent. Goodbye.

Hello YouTube. In today's session we are going to continue our study of testing and discuss various software development models, except perhaps agile methodologies. This topic is quite extensive. So, we will devote a separate lesson to it. And the first model we will talk about is the classic model of software development. Uh it is called the waterfall model or cascade model in English. It is known as the waterfall model.

In this model, each stage of development in the appropriate stage of the software lifecycle continues the previous one. On the left you can see a diagram of the waterfall model. It is already familiar to you. We discussed it in the very first lesson. What would you like to note? from the peculiarities of this model.

As you can see in order to move to a new stage we must completely finish the current one. That is, if we are talking about the requirements gathering stage. We cannot move to the analysis stage until we finish gathering the requirements. The same applies to the design phase, coding development, testing and support of our system. The cascade model is quite simple and straightforward, however it is somewhat outdated and not as practical as it once was.

Given that we are currently in an era of dynamically changing and evolving requirements, this type of structured process can turn the advantages the system used to offer into some significant disadvantages. Let's talk about such pros and cons of waterfall model. As for the pros of the cascade model. The pros include full documentation of each step, meaning that we will always have clear requirements available to us.

Also, we can always plan our timelines and costs clearly. And for the customer our processes will be quite transparent because they will know at what time this or that stage is launched. How much time will be spent on its realization and can calmly track it?

As for the disadvantages of the waterfall model, they include the following. First, the complete scope of requirements for the system must be approved before the project begins. If we need to make changes to the requirements later, we cannot go back. to the first stage. And we will have to redo all of our work. Additionally, the disadvantages also include the increase in costs and time if it becomes necessary to change the requirements. As I've already said,

In this case, we will have to go back to the very first stage and start working again. We have written down all the pros and cons. Now let's talk about when this model of software development is used at all. First of all, in projects with well defined requirements.

for which there is no provision to change them during the development process. The very first example that comes to my mind is some government agencies or some banking structures. This is typically where this particular development model all is employed. It is also utilized for projects that are migrating from one platform to another. That means the requirements stay the same and only a specific system environment changes.

Or when the development company is not responsible for performing testing, for instance, if The company is only responsible for developing the programme code. and testing will be conducted by the customer or another party. To the next development model we can refer to the Vmodel or Vmodel of Software Development. It is a modified version of the classical cascade model. Here,

As you can see on the scheme, the current process is controlled at each stage to ensure it is possible to move to the next level. In this model, testing begins at the stage of requirements writing, and each subsequent stage has its own level of test coverage. Here, the development process is represented by a descending sequence in the left part of our conditional letter VI and the testing stage on its right edge.

The correspondence between the stages of development and testing is shown by horizontal lines. The pros and cons of V models are as follows. First, we have strict stages. This is us discussing the pros. Secondly, the planning, testing, and verification of the system itself are done at early stages. Let's write early testing, which aligns with the principle of testing I discussed in one of our earlier lessons. And we

Also have a stage called intermediate testing. This means that unlike the Cascade model where intermediate testing was not possible and was strictly after the development stage of our software. Here we can conduct testing at every level. Regarding the disadvantages, we still face the inflexibility of our model here. The program itself is written and created during the code writing stage, that is, as we can observe from our scheme.

It occurs in the middle of the development process. We do not have the possibility to make any dynamic changes. This is because all the stages follow each other in sequence anyway. When do we use this type of development model? Typically it is used in projects where there are certain time and financial constraints. And for tasks that require a broader approach compared to the previous cascade model.

model test coverage. This is what our final mind map looks like. I hope you have no questions about this particular software development model. And now let's move on to the next one. Before this you and I discussed sequential software development models. However, not all life cycle models. follow a sequential approach. There are also iterative or incremental models which use a very different methodology.

Uh here, instead of one long sequence of actions, the entire product life cycle is uh segmented into several distinct minicycles. It is important to note that each of these cycles comprises the same stages as in other software development models. These mini cycles are referred to as iterations. During each iteration.

a specific component of the system is developed. Afterward, this component is integrated into the previously developed functionality. And so that entire process is collectively known as incremental. I believe each of you is familiar with a model such as Plan, Do, Check and Act. Each stage of development corresponds to one of these sectors.

For instance, planning would be the phase where we gather requirements. The do sector involves analyzing, drawing something, creating designs and writing program code. Testing falls under the check sector. An act represents the review phase, which includes evaluation, revising current requirements.

and proposing additions to them. And in eventually a point is reached where all the requirements will be embodied in our product and the release happens. Now, let's talk about the pros and cons of this model. First of all, The pluses include the fact that we have the early creation of working software. Since our iterations are usually short in time, we can deliver some of the functionality and our product in a small amount of time and very quickly.

This means that we can see results early on, which helps in making adjustments and improvements based on feedback. Additionally, this approach allows for better risk management, as issues can be identified and addressed sooner rather than later. Overall, the ability to produce working software early in the process is a significant advantage of this model.

It is also an advantage that such systems are generally very flexible, meaning they are prepared for changes in requirements at any stage of development. As I mentioned earlier, these iterations take a for a relatively short amount of time. If we refer to such a framework, in agile methodology like agile, it typically spans from two weeks to four weeks.

And it is this iterative model that has given rise to agile methodologies. So it's always easier to conduct testing and perform risk analysis for just a small part of our product lifecycle. And if we're talking about the cons, each phase is an independent unit of some kind, and the individual iterations do not overlap each other.

And unlike more classical models, for example, if we even consider the same cascade model, not always are all the requirements known by the beginning of the design phase. This can also complicate the work and implementation of our overall system architecture. When should we use an iterative model? Usually it is well suited for some large projects when

We do not know all the requirements, but we know at least some key requirements. And when the requirements, we know exactly what will change during the development process. And as I have already said, it is the iterative, iterative model. That became the ancestor of agile approaches to software development. We will talk to you about agile approaches in one of the next lessons. I guess that's all I wanted to tell you in this lesson.

I hope that it was useful to you as usual, and that you now have a little more. understanding and understanding of all the models that there are in software development. And when you come to work in a company where one of these models is used You will not be confused and will be able to quickly figure out how to work in the realities of this particular model.

The question about software development models is often enough asked at a job interview. So be sure to note for yourself the pros and cons of each of these methodologies. and be sure to remember where they can be applied. And that's all for now. Subscribe to this channel. As usual the new video won't be long in coming. We'll see you very soon. Welcome to our tent. Bye.

Hello YouTube. Today's lesson will be dedicated to such important test artifacts as test cases and checklists. After all, it is their correct creation that will first and foremost determine the efficiency of your testing, as well as the ability of other team members, whether it's a tester or even a developer. To smoothly understand how to conduct a test and its proper launch. There are two main types of test documentation in order to run a proper and efficient test.

This is a checklist and test case. Let's begin with a simpler type of test documentation, which is a checklist. When we talk about a checklist, first and foremost it is a specific list of checks. It shows what we plan to test and consequently the result and status of these checks. This list itself includes what we intend to do, what we must not forget, and what we will check directly.

So this is a kind of high-level set of ideas for our tests. Now let's take a look with you at the highlights of a good checklist. First, it includes the version of our build. the specific environment on which the testing was conducted, the exact date of our test, and the tester who performed this testing Additionally in the checklist there can be the type of

Tests that we used for each specific test, the detailed title of the tests themselves, and the result of our testing, that is to say, whether this check passed or not. And also to simplify our work. We have taken some separate modules of our application, the main modules, and for them all the checks are already described.

As you can see the name of the checklist reflects the name of the application. Our test application was a calculator, that is we used this checklist for it. Also the checklist scan. Contain a list of unique identifiers for each check, so that you can also safely find them in our system and give them. a reference in some other artifacts that we will use. In Testing.

There may also be a reference to a bug we have discovered, if again we already have this checklist in use in some backtracking system. And uh we can debug based on the result of some check, if in fact the result is different from the expected one. Also in the description to this video. I will give links to Those materials that help me to understand this issue. That is, there will be some sample checklists available that you can

Also use for your preparation, you can get your hands on these checklists and then utilize them to perform the test tasks or even in your main job. Let's go through it together and finalize what the checklist is all about. As I have already mentioned, it is a checklist. This list shows what needs to be tested and must necessarily include the results of our checks.

Let's talk to you now about another kind of artifact in another kind of test documentation, the test cases. This type of test documentation differs from checklist in the following ways. First of all, here we will already have steps. That is it is a kind of step by step scenario. Here we will already have low level checks, that is they will be more detailed.

And unlike the checklists in which we set what we would test, here we already describe how we will test. Again, here will be the result of our test cases. Also the test case is bound to have a header. There might be a priority or the order of execution of our test case. And a number of other attributes that I will tell you about a little bit later. The most important thing that you have to internalize when putting together a test case that

Here we have some trinity of basic attributes. These are our action to be performed, which is the step by step scenario, the expected result, and the actual result. In the future. Our test cases can be grouped into sets of test cases, which are known as test suites. Let's also note that there is a type of documentation called a test suite. Sometimes a test suite is referred to as a collection of test cases where the outcome of executing Preconditions necessary to start executing the next one.

In other words, these cases follow each other in sequence. And now, let's take a look at how TSU is generally compiled and what it might look like. Specifically for this purpose we will create a separate document where we will further introduce our test cases Let's name each column according to the attributes that should be present in a good test case. The first one should be the identifier, which will be unique for each of our test cases.

There can also be an attribute such as priority, or this column could represent the type of test that is being conducted. for this test case. Additionally, you can reference the requirement that our test case is related to, meaning the requirement we are checking, including the module title, is also a good idea. Uh next uh describe the title. This should reflect the main essence of our test case. Then, describe the steps to reproduce it. Finally include the expected result.

Usually it is spelled out for each step. However, this is not always necessary, and sometimes the expected result is only spelled out for the last step. But if we are talking about this document, about test cases for training future employees, for example, if you come to some company where there will be well documented test cases,

That is, there will be well documented steps to reproduce this test case. And also the expected result for each step will be described. It will be easier for you to learn. To work in this system. Learn about it. That is Test cases are very often used to train employees in order for them to form an idea of the program. This contributes to uh rapid assimilation of information and the introduction of specialists to the project.

And also we should have an actual result if we are talking about the fact that we have already prescribed the expected result. So now you and I have created a template for completing the test case within Excel. Small companies can use, for example, Google Sheets to manage their test cases and share them with other team members.

Or if we're talking about companies that can afford some paid resources for tracking test cases and executing them, then you can buy, for example, Test Trail and work with it. Or there is also a system called Testlink. Jira, the backtracking system that we're going to talk to you about a little bit later, also has a plugin called Zephyr that allows to store test cases and run them.

So it all depends on the financial capacity that the company has. You can also for yourself sign up or for a test case. There is a real version for thirty days. And also try to start. put test cases there, run them, see how it works, this system, feel it out. So it's all up to you. In this class we are not going to work with you with test rails. Everything is quite simple.

intuitive there. But in order for you to understand how to fill out a test case in general and what you should specify in it, let's try to create one such test case. Everything is quite simple. If we are talking about an identifier, there will be a unique number. Let's assign it the number one. Here we either spell out the execution priority. For example,

This will be the first order of magnitude. We run this test first. Alternatively, we can write the type of test we are using. For instance, this would be a smoke test. Since we don't have Any specific requirements, we can come up with some on our own. Again, let's consider Recon, the new user registration module. When discussing the title, let's specify, for example, new user registration using a cell phone.

Yes, it's important to note that you should have this pattern of creating test cases firmly established in your mind. First, we create simple test cases, and then we move on to more complex ones. When it comes to simple test cases, we start with positive scenarios. If you and I recall the lesson dedicated to positive and negative tests,

I explained the main differences between them and what you should prioritize. To summarize, I will remind you that we always begin with positive scenarios first, because initially we need to verify that our system works as per our requirement, as that was planned. And it will be interesting for our customer to know first that indeeds the system works out those scenarios, positive scenarios, and can quietly already be launched.

For our users and used by them. At the top you will now see a link to the sessions devoted to negative and positive tests, where I talked in more detail about their differences and how to run them. Make sure to thoroughly review it to refresh your memory on this information. Now let's discuss a block like steps. For instance, begin by starting the site. Next, enter your cell phone number in the designated field and wait for an SMS with a code.

Once you receive it, enter the code into the field that appears and then click the registration button. These are the assumed steps for this test case. Let's correct it by not starting the site but opening the site. Additionally, there should be a link to this site included here. And now for each step we need to write down our expected result. First, open the site. Let's assume that the site is currently loading, then enter the cell phone number into the designated field.

The phone number should be displayed in the mobile field. Next, the code will be sent to to the provided phone number. This code will then be displayed in a new field. After that, a successful registration message should appear. Finally, when we perform our test case directly together, we will compare the expected result with our actual result. And in the case of any inconsistency we might have a

Defect. Let's go ahead and add such a column here as well. In this column we will simply insert the number of our defects so that in the future we can easily track where it is and what test case it is related to. This is what a happy test test case looks like within Excel. As I mentioned earlier, there are separate systems where you can track all of this, enter our test cases, and run them directly within that system. So I believe you will not have any problems with that.

Quite often, employers send test assignments in which they ask you to write, detailed test cases for a certain module, or perhaps to test specific functionality. Therefore it is essential to have a thorough understanding of how to create test cases, get a good handle on it, and then use this template to successfully pass such test assignments. Also at the uh the interviews themselves very often show some functionality, for example, a screenshot of the screen of some application.

Where you are also asked to write some test. Cases already within the framework of your technical interview. Technical interview. Um I would also like to mention the fact that, as you may have already noticed, impersonal verbs are used here. That is, we never write verbs such as open, I will open. So we always put ourselves in the shoes of some unknown user who will perform this task. Therefore everything here should be maximized and impersonal.

So that a person having read your steps and expected result can carry out this test case without being tied to any specific personality. Just looking a little ahead, the same model is used when creating reports and defects, where we use any impersonal verb when describing this or that action. And to conclude our lesson, I would like to tell you more about the criteria for choosing one or another test documentation for a project. First, it depends on the complexity of our project in general.

If we are talking about some simple project, it is quite enough to use a checklist. But if our project becomes more complex, there are a lot of requirements that are quite difficult to implement. And there are a lot of aspects that we have to check. And we need some more detailed checks then. Then, of course, it is better to use test cases. The second aspect is the duration of our project.

If we are talking about some small projects in terms of duration, then it is more logical to use checklists. If our project is long, then we should use test cases. Also related to the complexity of the project is its size. That is, the bigger the project, the more people are involved in it. If there is a possibility that our team will be joined by new specialists who will need to be trained, then again, here is where. Better to use test cases, and again, if

We talk about the team itself. If it changes frequently there is such an aspect as stability again, test cases are used. If our requirements Are not subject to very strong changes then. It is also better to use test cases. Is quite difficult to maintain. That is, if we change our requirements very often, we need to constantly make changes in the test case.

The checklist is easier to work with. As you've seen, it's a simple document, so it just covers some general things about our required testing, and it's very easy to make changes to it. And we should not forget that in many ways, The choice of this or that test documentation may depend on the wishes of our customer.

For example, even if our project is simple and fast, but a customer wants to be more involved in the process so that the process is transparent to him, he may choose such test documentation. Like test cases. And in such a case, we will not be able to refuse him, and we will use exactly them in our work. That's all for today. I hope that this lesson has helped you to understand such types of test documentation.

As checklists and test cases, and you will be able to use them without any problems when performing test tasks for your future employers. Or to successfully pass the interview and further use these. Techniques in order to effectively and successfully create test documentation already on your current projects.

In the next lesson, we will discuss the two most popular test design techniques. These techniques are frequently mentioned during interviews, both when you are being asked questions and when you are asking them. After this lesson, you will be able to apply these test design techniques to create optimal test cases. This will allow you to test your application in the shortest possible time, but with maximum efficiency for both you and your customer.

We would really appreciate it if you could subscribe to our channel and share your thoughts on this video. We look forward to seeing you in our next class. Welcome to our shalash. Goodbye for now.

Hello YouTube. In this lesson, we are going to discuss the two most famous and popular test design techniques that I frequently use in my work. These techniques are also the ones most often asked about in job interviews and test assignments. In fact there are many more test design techniques out there. And you can read more about all of them in the book. Entitled A Practitioner's Guide to Software Test Design by Lee Copeland. I will leave the title of the book in the description below.

Let's understand what test design is. It is a stage in the testing process of our software where test cases. The ones I mentioned in the last lesson are designed and created according to quality criteria defined earlier and test objectives. In simple words, this means coming up with our tests, that is designing them. Test design has two main goals. The first thing is that we need to come up with tests that can detect the most serious bugs in our product.

The second goal is to minimize the number of such tests. Since we have already figured out what test design is, let's talk about these two popular techniques that testers use in their work almost every day. First, it is equivalent partitioning, also known as equivalence class testing. And the second type is boundary value analysis. Now let's begin, of course, with equivalent partitioning. First, let's understand together what an equivalence class is.

It refers to input data that is processed by our application in the same manner, or whose processing results in the same outcome. In order to fully grasp what an equivalence class entails, let's start by parsing the following example right away. We have a task at hand. Let's imagine that there is a company.

Where the decision to hire an applicant depends on their age, the conditions for our example will be as follows. If the age of our applicant ranges from 0 to 13, we will not hire such an employee. If the the age is between fourteen and seventeen, then there will be a part time position available. If from 18, let's say to 55 is full-time, and from 56 to 99 we don't hire such employees.

And as you and I can see, we have already formed four equivalence classes. As I said, this is a certain range of values which is processed by our system. in the same way, or the processing of the range of which comes to the same result. That is, for example, for the age from zero to tweteen, The result is that we do not hire such employees. This can already be taken as one equivalence class.

As you can see, we already have four classes, so these are some positive classes, but also, if we recall, about Positive and negative tests, there are also positive and negative equivalence classes. If we are talking about the age of employees that we are not hiring, Also, you and I will be able to go beyond zero. That is to take for example such a range as from minus infinity to zero.

Such values can also be taken. And if we're talking about employees that we don't hire, you and I can also take. from one hundred to plus infinity. This is also an amphivalent class. Plus, we are likely to use these particular numbers in some sort of input field. And in the input field we can enter, for example, letters or sing symbols. And we will also have

Equivalence classes, negative equivalence classes, so we can take all these things into account in our testing. And let's move on to the basic rules of this test design technique. There are two of them, one of which we have already performed together. The first is the definition of an equivalence class, and the second rule is to conduct at least one test for each class.

That means we must take at least one value from the equivalence class in order to confirm that the system handles all values in this class in the same way. Returning to our basic positive classes, we take one value from each class. The most common advice is to take values from the middle of a given class. For example, if we say from 0 to 13,

then the middle of this class will be either six or seven. So this is the value we will test. This is what we do for every class, including our negative equivalence classes that I talked about a little bit earlier. That's what we're doing for the equivalence partitioning technique. That is, you and I can already see how we have simplified our work and further improved the efficiency and time for our tests. Thinking back to the lesson on the basic principles of testing.

one of the principles clearly states that exhaustive testing is simply impossible. And it is this particular technique, test design, that allows us to efficiently use just one value and avoid doing, for example, like in this case, 4TN teen tests. For a given equivalence class. The second test design technique, which is closely related to equivalence partitioning, also known as equivalence class testing, is boundary value analysis.

Going back to our particular classes of equivalence, the positive ones, here we see the boundaries of these classes, that is zero, thirteen, fourteen, seventeen, eighteen, fifty-five, fifty-six, ninety-nine. Plus there are also these boundaries for of our negative classes. But now let us dwell with you in more detail on the positive ones. What does this analysis of boundary values mean?

The first rule here is the same. It is the definition of an equivalence class. Not a class, but a class. The second is to determine the boundaries of these ranges. We have already talked about that too. And the third is to perform three tests for the boundaries. On the boundary itself, on the value right above that boundary, and on the value just below that boundary.

Let's return to our example now and observe how this operates in practice. Look, we have established boundaries for each class. Let's consider the range from 18 to 55 as an example. What do our rules indicate? They state that we take these boundary values, 18 and 55, along with two additional values on this boundary. That is one value less and one value more. In this scenario it will be seventeen, eighteen itself, as the boundary, and nineteen.

and also the value of fifty four, which is right at the border of fifty five and fifty six. If we were discussing how our system can manage decimal fractions, Then the value of Would be as near to our boundary as possible. So there would be a value here, for instance, 54.9, 55.1. If we were only using one decimal place, so this is something that you have to remember and make sure to use these values.

As you might have noticed, when we employ the boundary value analysis technique, we also verify and test equivalence classes. So we have equivalent partitioning involved as well. That is, we take values that are also part of the equivalence class. For example, That is, it is included in this class, from eighteen to fifty-five,

And it is quite possible not to conduct additional testing already by this test design technique. So we kill two birds with one stone. But as I said at the beginning of our lesson, I would advise you to test the values in the middle of this range. As this will improve the quality of your test and make it more likely you won't miss any values processed incorrectly by our system. These two techniques are often asked about in job interviews.

I'm not afraid to repeat this for you to remember what to focus on when preparing for an interview. Yes, you can also read. The book I mentioned at the beginning of the class and learn about pair testing, the creation of those. We have a number of spreadsheets that allow us to do this using a tool like PICT. That's probably all I wanted to tell you in this class. Please internalize this information very well.

practice with other examples, read Lee Copeland's book. It also contains good examples on all test design techniques. Then you will be able to say with peace of mind that you have understood the test design techniques. And you'll be ready. for your interview. We will see you at the next session, which will be devoted to the design of bug reports, also known as bug reports.

In this class we will also understand the defect lifecycle and learn how to work with you in a bug tracking system like Jira. So stay on this channel, subscribe and put likes. Your feedback is very important to me. And in my turn I say goodbye to you. Please come back to our tent.

Bye. Hello YouTube. In today's tenth lesson, we are concluding the first block of this course called Tester from Scratch. This blog was dedicated to covering the main theoretical points related to getting immersed in the testing profession. In this session, we will be discussing with you an important test artifact known as a bug report.

or as it is sometimes referred to, a bug report. You will be creating and reacting to fixes, specifically fixes of this test artifact, which you will encounter most frequently in your work. Also, we will look at how to start a bug in practice in such a popular bug tracking system as Jira. And at the end of this session, we'll talk about the life cycle of defects.

What is a defect? Or a bug? It is a discrepancy between the actual result of program execution and the expected result. Defects are detected at software testing stage. When you and I, testers, compared the obtained results of the program or its component Lily Design with some expected result. As soon as we find a bug, we can see the actual result that we get after we have completed all the steps. As soon as we discover a bug, we have to document it.

The document that allows us to do this is a bug report. That is, this document contains a full description of our bug and includes information both about the bug itself which we will talk about in more detail later. And about the conditions of the bug's occurrence first, it is a short description of our problem. If we are talking about such a bug tracking system as Jira,

Then usually in the description they also prescribe steps to reproduce. That is, steps to reproduce this bug, which will lead to the fact that a person who reads this report We'll go through all these steps and we'll see our result actually, which was obtained after he has performed all the steps. We'll talk to you more about that when we go directly to Jira itself.

There is also such an attribute as project. That is, it is the name of our project. For example, if we are working on an application called, for example, an online store. Then the name of this project is specified here in this field so that later we can easily trace to which project our bug report belongs.

There can also be such an attribute as the component in in which the bug was directly detected. There can also be the version of our build, that is the version of the build on which the defect was found, and it is reproducible. There is also such a field as severity. In English it is called severity. That is in fact it is the criticality of our bug. That's the

is the degree of influence of this bug on our application. In a bug tracking system severity is usually denoted by a tester, and in principle this person usually does it on the project itself. Also, There is an attribute known as priority or in English it is priority. Priority indicates the order of fixing this bug. Usually it is determined by the PM, which stands for Product Manager, and they decide which bug gets fixed first.

Once again we will discuss more about severity and priority, that is severity priority a bit further on. and I we explain what the evaluations of these attributes are. There is also an attribute called status. That is, it is the status of our buck in its life cycle. As I said, we will deal with the life cycle in the final part of our lesson. There can also be an author field, that is the person who found our bug.

It can be the tester. Most often it is the tester. But it can also be another project or team member who found some bug in the system. And there is such a field as assignment or in English it will be assigned to. And let's now talk in more detail about attributes such as severity and priority. As I said, defects can be categorized in terms of severity and priority in different ways.

Let's talk about this categorization. On different projects, in different companies, severity and priority classification may differ from one another. However, I will give you the most common one which will help you to correlate the degrees of impact that you have, for example, on a project. With what I'm about to tell you.

First of all, this is a blocker. That is, it's a type of bug that makes our program inoperable. If we detect such a defect, further work with the program or its functions becomes simply impossible. The next type is critical. Critical defects cause our key functionality to fail. It can also be a significant deviation from the business logic of our application, or an incorrect implementation of our required function perhaps, Loss of user data.

Unlike Blogger, our application does not become completely non-functional. Other functions can still work fine. That's why there is a gradation called critical. The next types are major and minor, also known as major and minor bugs. Let's discuss them in more detail. Major bugs are some serious errors that indicate deviations. From the business logic or disrupt the program's work, but they are not critical.

impact on our application. Perhaps there's some workaround, or it may also be called workaround, where we can In principle, if we use this function it will work in some other way. But still, again, talking about the degree of impact, the severity of it for our product. It's quite large, but The next item is a minor.

or minor bug. It is some minor defect that does not break the functionality of our application, but which is a mismatch of the expected result. For example, this could be a bug in our design. These are trivial some trivial bugs. By the very name I think it is already clear to you that this is a bug that has no impact on the functionality or operation of our program. but which can be detected visually. For example, it can be some typo in the text that is

it is not a serious error, but still there is a deviation between the expected and actual result. Once again when talking about various bug tracking systems, And deciding on the project, it is important to determine what attributes should characterize the severity. For instance, there might not be a class like blockers, or there might not be. trivial bucks at all. There could only be categories such as critical, major, and minor.

Once more, there is usually detailed process documentation on projects that describes which bugs should be assigned to each of these categories. If you do not have such information on the project, I have given you the basic information on the theory related to this classification in this lesson. Now let's move on. To such an attribute as priority, as I said, it's a kind of prioritization. of fixing our defects, that is the order of fixes on the project.

And usually priority is put up by the PM on the project. But if there is no PM, it could very well be either the elite testers or the tester himself who is working on that bug. Perhaps even analysts who are familiar with how your system is supposed to work and which functionalities are essential for our user currently and which should be delivered to the customer first and foremost. Then that can also be demonstrated by the analyst.

When discussing the categorization of defects solely in terms of priority, there are three most common categories. These are high, medium, and low. By the name it is already somewhat clear to you which defects will be addressed first. Course it's high, that is this bug should be fixed as soon as possible because it critically affects the functionality of our program. If we are talking about medium This bug should also be fixed in the

but it does not have any critical impact on the application's performance. If we are talking about low defects, the error must also be fixed, but it does not have a critical impact on the program, and the fixing may be postponed for some longer period of time depending on the Against other higher priority defects. For example, if we have medium or high we will naturally fix bucks with high priority first and then box with medium priority. low priority bugs we will test at the very end.

speaking about whether severity and priority coincide, that is, for instance, If a tester decides that this functionality is extremely critical for our application and sets severity to, for example, Critical or Blocker, but At the same time, PM understands that it can be postponed for a longer period of time and it's actually not so critical for our application.

then it can set at a different priority, for example, medium instead of high. Often in interviews they ask for an example of bugs with high severity and low priority for example. If we talk about such bugs, then for example, if we have some functionality that is quite rare for our user, if we realize that it doesn't work we can put believe. For example, a blocker or a critic.

But at the same time, RPM realizes that this functionality is not in high demand, or it is not critical to the operation of our system, and we can do without it for the moment. It then decides that the priority will be low. This is the most common example where we have high severity and low priority.

If we talk about the other side of the coin when we have a high priority and low severity for example, Google site often gives us the same example, its main, when you open the page and you see a typo, for example. it is written Google not with two letters O, but with one. This brand is quite recognizable, and such typos can affect the

reputation of this brand very much. But at the same time the seriousness of this error is minimal. That is, it is some kind of typo, it is a trivial mistake. But the priority of how it affects the reputation will be high here.

This could also be a great example for an interview. You can look for more details on the internet to find the answer to this question with examples. I think that if you give at least two minus three examples to This question it will significantly raise your chance of successfully passing the interview. It is worth noting that in some systems, such as Priority,

Can be replaced instead of high, medium, low by the numbers one, two, three, four. Here the logic is the same. That is, if we have the digit one, we will fix this defect in the first place. If the digit four, we will fix it in the first. In the last place. Again this can also apply to severity. There can be numbers there too, and they tell us exactly the same thing. What is the severity? What is the criticality of our defect for the operation of our system?

Let's now go back to the attributes that can still be in our buck report. It is always necessary to specify the environment where this defect was detected. In English, it will be environment. Speaking of environment, we mean for example the operating system, the bit capacity of this system, possibly a service pack. The browser in which this defect was detected again its version.

that is we describe in detail here, in which environment or defect was detected. It can also be specified in environment, for example, if we have several environments on the project. For example, there is an environment for developers. There is an environment of stable version, or it is also called stage, and There is an environment of production when our end user is already working in it. Let's label these three types of environments and I'll tell you.

Uh a little bit more about them. I mean look, like I said, each of these environments has a certain range of people working on them. Usually developers work on dev environment. That is, they pour some features there. Maybe also testers are involved in testing some separate features on dev environment and can also introduce defects. And if we find defects like this. On that environment we spell out deaf in that field. The second kind of environment is

Staging. On the staging we usually have some stable version of our application. Testers work on it most often. And it is on the staging that they bring this application to a certain pre-release state. And uh if there are uh no uh defects there, then such an application is usually moved from this environment to the prod stage and we already have our end users working on prod.

Many courses don't mention Three environments and novice testers often have questions at their first meetings, wondering what this is. I believe that after this uh brief overview of these environments you will understand better and not be surprised by the presence of multiple environments in your future workplace. Going back. To the description, to the description field, as I said, reproduction steps can be prescribed here.

And most often they are indeed prescribed there, if there is no separate field. For example, in that bacteria system. That I work with at my job. It's called Azure DevOps. There's a separate field for steps to reproduce. Let me put an abbreviated title here. So you can find an acronym like this. It's T R this

stands for steps to reproduce, our actual result is also noted. In English it will be actual result. You can skip the word actual and just write result, because the next We spell out his expected result or in English is expected result and if you basically write expected result then it is logical to assume that. The first result you write down will be actual. So the word actual can be omitted in the design of our bug report.

That is once again the actual result, is the result we arrive at after we have performed all the steps of reproduction. And the expected result, the expected result is the result that should be in accordance with our requirements. is what we really should get. Yes. It is also worth noting that in the expected result you should write according to what you have come to such a conclusion that this is the result that should be, of the playback steps.

It can be a reference to some requirement or uh a reference to a mock-up of the design of our page, for example, on the internet. So it is absolutely necessary to reference something.

Just saying that there should be such a result without backing it up with some sort of evidence base is not a good idea. And probably the last of the main things is attachments. Some kind of attaches. Usually there can be a Photo, a screenshot of your screen, where it will be clearly visible where your defect is being reproduced.

Or it could be a video showing the steps that you follow to reproduce your defect in detail. If we are talking about a screenshot, it is necessary to indicate by some elements. Uh that it be, for example. Red frames. arrows or some inscription that will characterize that this is the place where the defect occurs. so that the developer, just by looking at this screenshot, could immediately understand what really happens according to the results of the steps. Play back.

Since most often a developer may not even read your playback steps, he knows how the system works, and by looking only at a screenshot he can quickly fix a bug detected by. Especially if we are talking about some UI bugs, bugs related to design, to some typing. That is to say, here we should definitely label it all somehow. On our screenshot.

If we are talking about video, make sure that you have the sound turned off, which would record for example. The environment in your office or the environment from your computer. Unless we are talking about some defects related to audio files, this situation is also not very good. I personally know very well of examples where reading testers do not disable it and you can, for instance,

On the video playback of this bug, hear the music they are listening to, or a conversation happening in an office cubicle or in an open space. This does not characterize you very well from the testers' side, so be sure to pay close attention to it. And the videos don't have to be very long. Believe me, a developer will not want to watch a video, for example, even one minute, as you reproduce your bug.

So you can omit some steps of reproduction, if you think they are not so important, and record some last part. A small one. Just where it will be clearly visible how your bug is reproduced. You can also put blocks of some of your bugs in or some archives if we are talking about downloading information into these attachments. about responses and requests in web applications. We'll be talking about this uh with you in the second part of our course.

That is, you can put all of this in there as well, so that, for example, a developer who opens the attached file in the form of logs with errors that are reproduced can also read them and quickly react to the found problem. Basically this is all I wanted to tell you about the main attributes of a bug report. There are of course still additional ones. It all depends on the company. I think if you do

some investigating about what other attributes there are, you'll find a lot of information online. I'll leave that up to you, but some basic things I've told you. Especially pay attention to the blog related to seriousness with Verity Prioritization because this is quite often asked in job interviews. And also don't forget that. You need to know all these things in order to successfully pass the interview. And in the future.

Make quality bug reports that will not cause questions from both PMS and developers. The second part of our lesson will be devoted to the direct practice of working in such a bug tracking system, Jira. What is a bug tracking system in general? Basically, it is a system that allows us To enter all our bug reports in it, and it also allows us to work in general with those reports more efficiently.

with our project. That is all user stories are added here, some requirements that we have to realize in the future. Here, as I have already mentioned before. is working with bugs. As you can see we have several logical blocks here, i.e. backlog and sprint. In fact, this tab itself is called backlog.

Now, what is backlog? When we will discuss agile uh methodology like agile and scrum framework, it will be covered in one of the upcoming lessons in other blocks of our course. Then we will be We'll talk in more detail of course about each of these. Entities of events in Scrum, but for your general understanding. The backlog is a set of tasks we need to complete during our product development on a project.

This is where everything is stored, from requirements by our business analysts or sales managers, to the bugs we log into the system. There's also a sprint here. A sprint is an iteration. Remember the lesson on the iterative development model? I mentioned that uh an iteration is a set period where we implement certain functionalities. And everything we complete adds to our increment, which is already a part of our finished product. So that's the sprint or iteration.

and in this iteration we fulfil some stories, or rather these are the requirements that we need to accomplish. Additionally, herein The sprint, we include bugs that our developers must address. This is typically decided in a ceremony such as a planning session, a rally where the entire team gathers together and determines what we are going to. Implement in a given sprint. Once again, we will cover all of this in more detail with you in the upcoming lessons.

Now we are more interested in the design of bug reports in this system. I would also like to note that you can try working in jury on your own. and absolutely free of charge. There is a special version of this software. So that users can learn it, it is enough to go to the official site of Atlassian Company, which is directly engaged in the development of this Tula as Jira, and there you can click on the try to free button and then You'll be able to sign up and work.

in Jira just like I'm doing now. I mean I've created a free account for myself now too. The only thing is that there are limits on the number of users who can work in it. If I'm not mistaken it's ten people. But for some training purposes, it's quite enough. Let's go ahead and create our first bug with you, a bug report. To do this you see there is a create button here, we click on it and uh window opens to create our bug. Uh as I said, has an attribute like project.

I have it already created its test project. That's what I've named a test. See we don't have any other projects. Issue type is the name of our entity that we're going to use. In this case it's bug. Uh we also have story here, for example. These are our requirements. And Epic is some set of our requirements that are combined together. the big functionality that we need to deliver to our user. Story, this is a more specific requirement. Usually it's spelled out in the user story format.

We'll discuss the user story format later in the next lessons. And task these are tasks a team member performs when planning their work for an iteration. We are interested in an entity called a bug. Summary is the name of our bug. Let's keep it for now. So uh I have some notes by the name that you should use when. Creating the title of your bug report. In the description field as I said we describe the steps of reproduction.

our actual result and the expected result. Also sometimes there is a block. Like preconditions, where we describe some preconditions. For example, that in order to reproduce our defect, a user with such and such data has already been created in the system. in order not to overload our steps of reproduction and in principle the developer will already know what he needs to do to the environment serves as a means to reproduce our defect in the future.

The reporter is essentially the author of our defect and in this case it is me. Fixed versions, although we are not writing here, I will explain what it is next. Priority, as I mentioned, this indicates the priority of our execution. Police severity. I don't see anything here. As you can see all of this is customizable. This means that for your specific needs and for your project, you can select and use only certain fields from all the available ones.

But as you can see there is no check field here, but uh we have already talked about check so we will use such an attribute as priority. Labels or in other systems it may be called tags. These are labels that allow us to search for our bugs in the future, that is, to categorize and combine them somehow. Environment, as I have already said, is the environment. Attachment is Here we upload some screenshots or video files, linked issues and the issue itself.

Here we can link our requirements, for example, which are related to our Bak Asani. This is the person who will. Fix our bug in the future. Usually. Connection on large projects is assigned by product manager, but if the project is small, it may well be a tester. He can also assign a person. Epic Link is the link.

To our Epic and sprint, this is where we link. To the iteration where we need to fix our bug. Now let's try to start a bug report of some sort. For example, let's take the login page of our application. And for example some button has moved there. Uh as for the correct name of our bug, there is such a rule. You must be sure to answer the three questions in the title Where, what, and When?

Where this could be the name of your module where you discovered your bug. What this directly happens when you discover your bug, meaning what your defect led to, and when. Under what conditions it happens. For example, if we're talking about the login page, we can write it like this. The login page is our module where our defect happens. What happens? For instance, the sign-in button is displaced after clicking on the page.

So you see, it's important to clearly define these aspects to understand the nature of the bug and its impact. RC. Here we have taken into account just the answers to these three questions. First of all, where? Our module is the login page. What happened? The sign in button is being shifted and under what conditions, after clicking on the page Here uh we have taken all these aspects into account when uh forming our header. Please remember it and use it in the future. As for description.

Let's start with the steps from of the piece. Also, as I said, here will be attribute.result is our actual result and expected result. This is the expected result. In order to make our defect understandable to the developer and in principle those people who later work with it it is best to format it that is to apply some styles to its design. In Jira you can do this in two ways. First, you can like in Word, simply select your text and click on that particular style. Or fun.

As you can see, two asterisks appear immediately, which basically show the fact that TR will be bold. If we click such a button with you, you and I can see a preview. And indeed, our str is highlighted in bold. That is we can immediately use asterisk to determine where we want our str to be bolded. Now, as for the playback steps themselves. Here we spell out all the things that will lead to further reproduction of our defect. Let's write the following.

First, we write here that we open open the login page. If we were working on a real project, we might already have a link to it and we could insert it here to simplify the work and immediately we could go. To this page. Next we right um navigate to the sign in button and the last step is we click on this page. In principle, these steps of reproduction are quite sufficient for the developer to reproduce our bug in the future.

And once again, in order for us to correctly format this text, we have two possible methods. One, we can choose to list exactly using number list or alternatively. We can place grids in front of each playback step. Once more we separate these out so that it is clearly visible. into distinct blocks. And if you and I click on the definitive view, you and I will be able to see that yes indeed we do have these steps clearly labeled with numbers. actual result, we will have the same as the header.

In general, it is recommended to invent another name for the header, but I usually use this method as it simplifies the work and in principle everything is clear here. There is no need to invent a bicycle. And expected result is what we really should have seen after clicking on some empty space on the page. Let's have our expected result be as follows. The sign in button is located on the page as per the mockups. If we had mockups in a system like Figma, we could copy the link and paste.

It here. Clicking this link would take the developer directly to the mock-up showing the system's behavior and the sign-in buttons location. If we click once again on the preview, we will see exactly what our bug looks like. In principle I'm quite happy with how it appears. And I don't think there will be any questions about how to reproduce it. The defect is quite simple so

We have not invented something complicated here. Speaking of playback steps, try not to come up with a huge number of them. You can combine them with each other. I recommend using seven to ten steps at most. It's better of course to have even fewer. But at the same time try to write them in such a way that it is clear.

What is going on and if the steps cannot logically be combined with each other, it is better not to combine them so that later there will be no misunderstanding on the part of the developer. or a person who sees your system for the first time at all, for example. If we are talking about some novice testers who will learn to create bugs on the basis of of what you once did in this system, or You will quit, for example, and a person will further work with your bucks that

Were created but not fixed at the time you left the company. Try to do it all in such a way that all people who will interact with the bug report in the future can safely read it and reproduce the whole thing. So look, polyfix versions are usually filled in after the bug has been fixed. Make sure to document everything clearly so future team members understand the context and can resolve issues efficiently.

The developer already does that now as you can see You can select that version of FX priority, as I told you, this defect is a UI defect. And it doesn't carry any critical load, so you can prioritize it here, probably low or even lowest. But as I told you, usually it's the PM on the project who sets the priority. Severity unfortunately is not available here. But again verify it would also be low here, for example it would be trivial.

on labels. This is where you can contribute some labels of your own or if they're already in the system they'll be shown to you in the drop down menu. Again, this is to simplify the job of finding your defects. By environment, here you can write the version of your system. For instance, mine is Windows 10. I think everyone knows exactly how to see the version of your system. You need to go to this computer and then click on properties.

And here we have you see it says Windows 10 Corporate LTC. That's all we have to copy and paste into our bug report. and also specify the business of our system. I'm not going to do that now, but I think you can see how it should work. And speaking of the browser, for example, on which this was detected, we have this Google Chrome. In the browser, you just open the Google Chrome Browser Help section and copy the version number.

Since we don't have any dev stage or prod environments, we don't specify any of those things here either. Speaking of In the screen. Let me show you how it can be done with an example far from our buck. But you will basically be able to understand in general how it should work. Yes, there are. Paid and free screenshot tools that allow you to do all this, take a screenshot, edit it. Probably among the free ones the most common is Sharex, which I use and it is quite convenient.

In the work, one of the paid ones is Snagit, it is quite often used in IT companies. Here you and I can select directly the area that interests us. Now we make a screenshot and edit the image. For example, we have here. It should have been written not attachment but For example, attachment. That is, I denote where we have directly. Observe the defect with a red rectangle. Additionally, I can use an arrow to further emphasize.

And write text with some description. For example, the attachment should be called attachment. Okay, so that's basically how good our screenshot looks and When the developer just looks at it, he'll immediately realize where the error is. We save the image. Uh and then just drag and drop it. It's gonna load now. It's loaded. has appeared here for some reason. That is then you can open this floor and see how this button is displayed on the UI. Furthermore, by interrelationships here.

We can describe what type of entity this bug relates to. That is, whether it relates to this entity, whether it blocks its work. Whether this functionality is blocked by another functionality, whether this is a clone of some functionality, perhaps it is some duplicate of another bug. That is we can specify all these things here. Usually we specify two we have several of them in the system now.

Let's take bug report creation. A signee will be automatically assigned but again, as I said, it is usually assigned by the PM on the project. Or on smaller projects, it is typically assigned by the tester. Epic link. If we had an epic we could bind that as well. And the sprint where the bug needs to be fixed, we also designate that right here. Additionally, you can click create another put.

Bug will be created and you will have a window that allows you not to fill in any other fields. Using pre-filled fields to create several bugs simultaneously. If you just click create, then this window will close completely and you will have to re-enter all the data from the beginning. So basically we can check it together now. If we click create, you can see that our bug has been successfully created. It now has an identifier, a project name, and an entity number in our system.

Moreover, here we have already saved some attributes, which means we can avoid filling them in the future and instead use the pre-filled ones. We've also had an update here. We've got this bug on in the sprint. Here we have table by status meaning what we have in the works, what we have in progress, what's already done. This also allows our PM product manager to keep track of the team's performance, how they are executing everything on time.

and you and I can directly open our bug, edit it in case we have some. Changes me. At the bottom, we see a reflection of all changes made to our bug. Look, our bug has been updated and created, so everything we change here will also be reflected in history. There might be comments written by you or other team members on this bug. You can customize and manage it your way here. You can also perform a search, a normal search or An advanced search.

We won't go into more detail about the date with you now. We'll probably have some additional lesson related. To advanced search in Jira. But as I can see this lesson has already gotten very long, so let's move on to the last concluding part of this lesson. The last part of our lesson will focus on the life cycle of a defect. Let's imagine that you have found some bug. It appeared in your life, in the life of your project.

And like any life form, it has a life cycle. So let's talk about it in more detail. When we talked about the attributes of a bug report, we talked about its status. These are the statuses that we are going to talk about in the block dedicated to life cycle. See, as soon as our Bug report is created in the system. Its status is new. That is, it is new. The tester found the bug. The bug was successfully entered into the bug tracking system.

In some bug tracking systems, this status might be referred to as proposed. Following that, our bug transitions to the open status, which can also be termed assigned or active. This occurs when our bug has been sent. to the developer either by our product manager or by you, especially if we are dealing with a small project, a small team, or a small company. Depending on the decision made by our product manager, our bug might also be postponed.

That is, fixing this bug does not hold any value at this particular stage of development, or for some other reason, it will be addressed later on, perhaps in other iterations or in other sprints. Again, this decision is up to our product manager. If our desk check has still been taken into work, it is assigned the assigned status. Then when the development team fixes this bug, it moves to resolve status and is assigned back to the tester.

But at the same time this bug can be rejected. That is again it can be in the resolved status and there can be the following so-called decisions, resolutions on this bug. That is, as I have already said, it can be fixed. If this bug already exists in the system, we, for some, Reason missed this fact and started it. a status such as not a status but a resolution such as duplicate or or won't fix that is this bug will not be fixed at all.

Perhaps this bug was introduced by mistake. It can also be such as for me, that is, it works for this developer. Also this attribute may be called fat or function as designed. If indeed everything works according to our specification and our requirements, It may also not be written because this picture I took from the internet, it may be written incomplete or to be reformulated. That is, when this bug is not very clear to ours.

To the developer it asks that the tester rewrite it so that in the future our developer understands in general what it is and what it is eaten with. There may even be such an attribute as fixed indirectly. meaning when our bug is fixed by some bug fix or other bug, and indeed this functionality worked. Can also be such an attribute. If we still have

it marked as fixed, i.e., truly fixed it, then this bug goes to our tester. The tester confirms the bug is fixed and it moves to verified status. If the bug is indeed fixed, For example, it doesn't occur on dev, stage, or prod. We close it, changing its status to closed. If the bug reappears, we can reopen it from both verified and closed stages, moving it to reopen status. Then it goes back to In status. It goes, perhaps, to the product manager

Who decides which developer should handle it or directly to the developer who originally worked on it? So that's just the way it typically works. And again we have the reopen status if after the result of verification by the tester. This bug has not been fixed by the developers. Then we have the reopen status too, and the cycle repeats itself. After reopening the status resolves again.

If everything is fixed or there are other reasons we can close this bug. After the status is resolved, it goes to our tester. This process can repeat many times until the bug is completely fixed and everyone is satisfied. You can study the scheme in more detail if you press pause now. And in principle it will be enough for you to have a good understanding of the defect life cycle. As you can see this lesson turned out to be rather long. But it is very important for your further work.

since you will create bug reports, I think, most often on your projects. And it is to understand them that is a must have for all novice testers. And for all testers in general, since this is the basic entity that everyone works with, starting from you, testers, and ending with by the same developers, business analysts, or product managers. So all of these project participants can connect to bug reports and maybe even start them.

Therefore, it is a very useful skill to know how to write high quality bug reports, understand what the defect life cycle is, and apply all this knowledge in your practice. That's it from me. As always, I hope this lesson has been useful to you. In the next lesson, we will be starting a new block of our course. This block will be dedicated to testing web-oriented applications, so please stay tuned to this channel. As always, I am looking forward to your comments and perhaps questions.

as I believe this topic is quite challenging to digest. And and you really need to invest a significant amount of time to fully understand both barktracking and correctly creating bug reports. So we will definitely be in touch. And in turn I will now say goodbye to you. Farewell. Also, welcome to our tent. We are glad to have you here.

Hello YouTube. Today we start diving into a very interesting and extensive topic, testing web-oriented applications. The standard start of any web application testing course is to break down the concept and model of client-server architecture. So let's talk a bit about it. Looking ahead, I'll say that today we'll cover only some basic things related to this model, but uh everything that concerns more detailed analysis will be covered in the next lessons. So what is a client server architecture?

It is an architecture in which the network load is distributed between service providers called servers and service customers called clients. In fact, the client and the server are software of some sort. Usually these programs are located on different computing machines and communicate with each other through network protocols. But also a client and a server can be located on the same machine. The most common protocol is HTTP. We will talk about it a little later.

In the next lessons, for now you should just remember that it is and that client server architecture is built mainly on interaction through this type of protocol. If you and I now look at this diagram as you can see We have here is a client, is server and is database server.

Basically, this is the standard scheme of the client and server. Sometimes there is no database in this scheme. Then we are just talking about having a client and a server that communicate with each other. The client sends H T P request or it is also called HTTP request to the server. The server processes it and sends back to the client HTTP response. That is a response from the server.

If we are talking about an additional element, such as a database, then everything is simple. The client sends a request to server. The uh server sends the request to the database. The database sends a response to The server and then the server is already interacting with our client. sending a response for the information it requested again to the client. Since one server program can perform queries from several client programs, as you can see we have three of them here, maybe many more.

this server program is usually placed on a dedicated computing machine. Usually with some other server programs, so the performance of this machine would have to be very high. Let's talk about the disadvantages and advantages of this model in a nutshell. To the pluses of course, we can refer to the fact that there is no duplication of the server program, COVID program.

Since all the calculations are performed on the server, the requirements to the computers on which the client is installed are reduced. As I said before, usually server programs are on more computationally intensive machines than client programs. Also on the plus side is the fact that all data is stored on the server, which is usually well protected better than most clients.

And it is easier to organize authority control on the server to allow access to data only to clients with appropriate access rights. This is usually handled by a separately dedicated person. A system administrator, perhaps, or DevOps. The disadvantages of this type of architecture is that if we have, for example, a server DAC.

Then the whole computing network is down will also not work. As I said, to support this system requires a separate specialist, a system administrator. And usually server hardware is very expensive. also talking about clients and servers, it is worth talking about the so called three tier architecture. That is, if we have only a client and a server and a link, then this architecture is two level. But When we have a database.

For example, if we are talking about some kind of social network, when a client sends information to the servers with a request of what he is looking for, for example, and this information is contained in the database. Then the server needs to address it to get this information. So we have an additional database and its server. And then we have these three links, that is the information from the database goes back to the server and through the server gets back to the client.

Often at interviews they ask you to draw such a scheme of client server architecture. So remember the difference between the two tier architecture and the client server architecture. And a three tier scheme The most common example of a client is a browser. all of you and I know what it is. For example, it's Google, Chrome, or Safari or Mozilla or Opera. So we put some of our HTTP requests in there. That's basically what we type into the address bar. and that request goes to the server

That's what a client is. There are two types of clients, thin and thick. Often at job interviews, people are asked to give examples of thin and thick clients to tell us what they are. So make sure you memorize it so that you don't get confused in future. In a technical interview, see a thin client is a computer or some kind of client program.

In networks with a client-server architecture that shifts all or most of the information processing tasks to the server. As I said, an example of such a thin client is a browser. Which is used to work with uh web applications. Why is it called a thin client? Because all the basic business logic and all the computing power we have is actually located on the server computer. And the client itself is essentially some simple software that helps us send requests to the server.

Now if we are talking about say client It is an application that provides more advanced functionality. Independent of the central server. Often the server in this case is just some kind of data storage, and all the work of processing and presentation of this data is transferred to the client machine. For example, if you take such complex software as 1C accounting, I think that some of you have worked with it.

And know that in fact this application allows you to do all the accounting in a particular enterprise. That is, it contains all of the basic business logic. And we have only the data that needs to be stored in the database is sent to the server. Or when we need to retrieve them, send some query back and retrieve them from the database. And everything else, the main thing, is on this thick client in one C.

You can also refer to this thick client as all the online games, the same tanks. Again, everything is basically. on the client, that is the client, in fact, is our computer game. And already again the information about users, what is stored in the database we have on the server. So it's not such a complex computing power that can contain all the basic business logic of our application. Memorize these basic examples of thick and thin clients.

And you will have no problem explaining what they are at a job interview. Sometimes it is enough just to name these examples without any specification as to what business logic is contained in the thick client. And and thin client In principle, at first this information will be enough for us to talk about testing web applications. Next, we will understand what is.

HTTP request, HTTP request, what it consists of, what in general we can send to the server, in what form this information comes to us to the client. how we can view it using built in tools in our browsers, in our clients. We will be able to test some web services. And in general, we will learn how to test websites. As you can see, I have already named three words. With the keypad web.

Web services, web applications and websites. I think you have some questions about what they are and why they are different from each other. Let's now talk a little bit about it. Websites are usually informational in nature. That is, they consist of some kind of web pages linked together to form a single resource. Have some simple architecture based on HTML code. Again, we'll talk about HTML, CSS, and JavaScript with you a little later.

Uh but just so you understand, this is just some basic information in the form of markup on our website. And websites like this essentially serve as a platform to provide content for visitors, that is, they contain some. Text files, images, perhaps music. The websites do not provide the opportunity to interact with our program. That is, users do not have access to posting their information except for filling out.

Forms to get for example a subscription. The most prominent examples of typical websites are news sites, cooking sites and weather forecasts, unlike a website, web applications. These are such interactive computer applications that are specifically designed for the internet and allow users to enter, retrieve, and manipulate data through interaction. Such programs have a very close connection with our server. and send a lot of requests to it and such web applications may be embedded in web pages

or the web pages themselves maybe applications. If you think of some of the main ones, they include, for example, Facebook, Gmail, YouTube eBay, Twitter, Amazon, various social networks including VContact A, for example. Web applications use a username and password for authentication, and they allow their visitors to exchange, for example, instant messages. if we are talking about social networks or some blogs. Create content based

User preferences provide unlimited access to it. Also, some mini programs for entertainment can be embedded there. And another difference from websites is that many internet applications. So, what do they mean? That is, they are used to accomplish some additional tasks. So they can be some kind of internet translators, messengers.

file converters, currency converters, whatever. And the last thing I wanted to tell you about today is web services. If you and I recall one of the first lessons on testing levels, One of them was integration level. And it is the logic of the integration level that is tied to web services. I mean, what exactly is a web service? It's an application programming interface or API. that uh operates on a server and supplies data to a client. Via HTTP.

This is the protocol we discussed with you in the first part of our lesson using a standardized messaging system. Web services in turn are classified into SOAP and REST. Once again, we will discuss the SOAP protocol and the REST architectural style in more detail in a later lesson. But what you need to know is that in today's scenario, most of the services prefer to use just the architectural style of REST.

As opposed to SAP. Why? Because SAP is a protocol, so it is some standardized protocol, while REST is more flexible. That is, there are no any strict rules by which we have to cooperate with it and use it. So it is more interesting from the point of view of web development. And again, since SOAP is a standardized protocol and it uses XML. XML is basically an advanced markup language. It's very similar to HTML, if you're familiar, with markup languages.

And in terms of the amount of information that we put into soap, it's certainly much larger than in rest. And we use JSON there and the amount of information is much smaller, so we can reduce the time here for all these responses and requests to the server. Again, we will talk to you about all of this a little later. So for now, don't get too worked up. Just remember that websites are some simple web pages that are Information of some sort.

Web applications already allow the user to interact with these different web pages, enter there some data, interact with the content. And a web service is essentially an API. or some kind of pre packaged program interface that allows different web applications. For example, to interact with one another. On that lovely note, our initial session in testing web oriented applications is now coming to an end.

I hope that you have a bit of understanding in your mind about what client server architecture is, how websites, web applications and web services differ from each other. You should be able to answer these questions during your initial interviews. Um if you're asked for this information and you certainly will be. In the next lesson we will continue to study client server architecture at a deeper level.

We will thoroughly dive into this topic, so make sure to stay tuned to this channel. Please put your likes, subscribe, and leave comments with any questions you may have. I will make sure to answer each and every one of you. And that's all for now. Welcome to our tent and goodbye for now.

Hello YouTube. Today, as promised, we continue learning about testing web-oriented applications. And this lesson will be dedicated to the HTTP protocol. We will talk about what a response request consists of. We will also touch upon such topics as status codes, what versions of HTTP protocols exist or existed, and some other things that are directly related to this protocol. First of all, let's understand what a protocol is.

A protocol is a set of rules for transmitting information, that is, with the help of protocols. We regulate how our information is transmitted on the Internet. If we talk about the HTTP protocol, its full name is Hypertext Transfer Protocol. So what does an application layer protocol mean? There are several network models. There's the OSI model and the TCP IP model. TCP IP is the most modern model widely used in internet networks today.

The OSI model is already updated and within the framework of this lesson we will not dwell on each of these models. But I will tell you what you need to know in order for you to understand what protocols there are, what levels there are in these models, and to which of them the HTTP protocol belongs. Now you and I can see the two models that I mentioned above. These are TCPIP model and OSI model.

In the OSA model, there are seven layers. In TCP IP only four. In more detail I will tell you about TCP IP model. The very first level is the level of network interfaces. That is, in this case, some physical impulses are transmitted. That is, for example, fiber optics can be referred to here.

When we move to the next level, this is the network level. Then here there is already a transfer of physical signals in the form of bits or bytes. Here, for example, we can distinguish such a protocol as AP. When we discuss the transport level we already see some transport interactions within our network. At this level we have two types of protocols, TCP and UDP.

It's important to note that these two protocols are quite different from each other. Often during job interviews, candidates are asked about these differences. Speaking of the TCP protocol, it is known as a reliable transport protocol. This means that when transferring files, there is a guarantee that the information will successfully reach our client. If within the transfer of information happens that the information does not pass, that is, there is no certain conviction and guarantee that.

Client received this information. Then there is a resend of information. This is what concerns the TCP protocol. If we talk about UDP, then here we do not need to be convinced that our information has reached the client. That is, it is a continuous flow, the information is transmitted. And there are no mechanisms that would say that it is guaranteed that our information has reached the client either, to the server.

This is the main difference between these two protocols. I will not tell about these protocols any technical things with. This course, this answer will be enough at the interview for your interviewer to realize that you know the difference between these protocols. If we are talking about UDP protocols, then in practice they are used for example in online games, where it is not necessary to make sure that the information is transferred.

from the client to the server. If we are talking about TCP protocol, this protocol can be used in mail services. So here we have to make sure that indeed our client has received some mail. And the next level is application level, or the same application level in Russian. This is a specific level for our application, that is how various interactions take place in our application. This is the very last level. And as I said, the HTTP protocol refers specifically to application layer protocols.

If you are interested, you can pause this video and see what other protocols can be attributed to these layers. Often in job interviews, you may be asked what other protocols besides HTTP can be classified as. Application layer protocols. That is, these other remaining protocols are included here. Also at interviews sometimes they may ask about the SI model

also about the name of the levels, what kinds of protocols are there, are used on each of them. So if you are interested in this topic, please feel free to leave your comments. I will definitely pay more attention to these two models. We'll talk about the differences in the protocol. What pitfalls there are in them and perhaps what else you might be asked in an interview about each of these mods. Now let's talk more about what the HTTP protocol requests and responses consist of in general.

It is uh obligatory to highlight the main part because in English it is called payload, that is in fact it is what we have to convey. The main part is also called the payload. Also, in a request or response there can be so called headers or headers. This is service information. Then it already describes how our main part of the payload should be transmitted. If we talk about the HTTP protocol and remember its full name, which is the hypertext transfer protocol, you might have a doubt.

That we must necessarily pass. Hypertext, which means some text files in the payload in the main part. However, this is not the case. In fact, you can pass more than just texts in the main part. You can pass pictures, you can pass some code. So all of this can also be encrypted in our main part. And most often, the answers come in HTML format. This is a special markup language, which we will also discuss a little bit later in the next lessons.

Let's now take a look at uh Examples of Each T T P requests and HTTP responses, what they consist of in general. what the main parts of them are, and what you should pay attention to in your preparation for the interview. I hope we all remember the difference between a request and a response. A request is sent by a client to a server And the server in turn responds to the request and gives its HTTP response, that is response. So here we have two examples of our HTTP request and

HTTP response what does? Uh HTTP request look like? First of all we have a method. A little bit further on I will tell you what methods are. So just remember that the first thing in the response is the method. Next is the version of our protocol. Again, we will talk about protocol versions. in the last part of our lesson. And the host machine, that is where our application resides in general, which is our server.

Also, we have headers in the requester. As I have already said, this is some service information that characterizes our main part. It may or may not exist. That is, these headers are an optional part. and uh they can be different in each. separate requests. Also, the first line off may contain a URL that is what resource we are accessing.

If we're talking about HTTP request, then here we also have information about the protocol version, also contains the status code, i.e. The status code tells us whether it's successful or not, that is, whether the server responds to us or not. And each status code has a numerical designation and textual information. So as you can see, this is the status code itself and the status message. A little further on I will tell you more about.

Status codes, what they are and what you should pay attention to when testing responses and requests to the server. Further, we have the date when the response from the server was sent at all. Information about server. And also again some headers that characterize our main load. Also here we usually put an empty string and if our response contains some payload. Then further goes the information exactly with this payload.

For example, a document in HTML format. This is how HTTP requests and HTTP responses look like. Now let's talk in more detail about the components of each of these entities. First, let's talk about methods. There are a few basic methods that are used when generating requests. These are get and post, the most basic two. There are also put, delete, connect options, batch methods, that is, uh they are not always used anymore and are not the main ones.

If we are talking about the get method, here it is now by the way, we have it on our example. This method precisely characterizes the exact requests for information from our server. In other words, our client simply sends some information and requests it from the server. If we are talking about the post method, in this case we send a payload to the server. That is, we have this main part, the payload, for example, in the body of our request.

This payload can be some picture, text or other data and we send it to the server. The put method also works in a similar way, that is, it also sends some information to the server, and it is usually used to create an object on the server. And there is such a method as delete that is to Delete data again from our server or database server. Another method is connect. In addition to the HTTP protocol, there is such a protocol as HTTPS.

The difference in these two protocols is that HTTPS is encrypted. So our information gets to the server in some encrypted form. That's why most often Now use HTTPS protocols because they are more reliable, the information is encrypted, some attackers can't get it so easily, so be sure to pay attention to this if for example you use some resource. And in order to trust it it is better that it was written using HTTPS protocol.

If you pause this video, you will see detailed information about these methods that I have discussed, including their names and a general overview of each method. Additionally, we will discuss these methods in more detail in future lessons. Likely, even when we cover API testing. Understanding these methods, what's encrypted within them, and their main components is crucial.

What differences there are, what you should pay attention to when testing the API. After all, this will be in this block. For now it is enough for you to know just their name and what they are. Coming back. To the response, that is the response from the server, I mentioned such aspects as status code and status message. As I said, these status codes characterize. The success of our request to the server and whether it can actually give us a response or whether there are some obstacles to it.

As you can see, the status code is encrypted numerically, and there are five main groups. These are hundreds. Two hundredths, three hundredths, four hundredths, and five hundredths. Each of these types has its own name, that is, hundreds are informational messages, two hundredths are informational messages, three hundredths are messages from both directions. Four hundredths are client side errors and five hundredths are server side errors.

We are not going to dwell on hundred errors because in fact they are just some informational messages which in fact carry. Semantic load. As testers, we are primarily interested in zero to status. Code and zero four and zero five because they tell us that we have some critical errors. The main code we are interested in in 02 is 200 status code, which says that everything was successful both on the client side and on the server side.

that is the server has processed. Our request from the client gave the answer. In really We had some kind of success. The 300 status code, as I mentioned, indicates that the server returned the information to us in the response, but it was found elsewhere. Here we will be particularly interested in such.

a code as 301 which means that the client accessed a certain page but this page has been moved and is now located at a new address. The server managed to handle this case and return the new address in the header. Then bad errors that is, we should always pay attention to it because these are potential threats.

We may not always have information about the new address of our resource, that is, it can just disappear at some point, and then a three oh one error can turn into a more serious error for example. into a 404 error, we will talk about it a little later. So pay attention to the 301 error. Also the status quo 304 is not listed here. It's is important to Code not modified. As you know I hope We have information about our sites stored in the cache.

that is, locally on our computer, so that in the future, when the client accessed the server, There was no loading of additional resources. That is, this information is stored in the cachet. Information about our site, for example, some pictures from it, and takes information already from the local machine. And exactly three oh four code not modified says that.

That information in this site is stored in cachet and in such case when requesting to the server it can return this error and take some payload from our local computer. However, it may not take this load. And reload us some server data. This is very good for performance if we really have a working cachet, so pay attention to it too. And here we come to the most interesting status quotes which are 0.4 and 05. As I said, 0.4 are errors on the client.

If we are talking about the main ones you should pay attention to, it is the zero four error itself. Which says that the request could not be processed by the server, it was made incorrectly, and in case of such an error you should be sure to copy all the information about this request to our bug report. If you have forgotten how bug reports are created, now there will be a link at the top and you can go to this lesson. That is, if we see 400 bug, I will tell you further where we can see it.

Then we must attach our entire request to the bug report so that the developer, having received information about this report, about this defect, can easily understand what is the main cause of this bug. Also such an important status code as four oh one is not specified here. That is, it characterizes the fact that we have entered some incorrect login and password And then our system swears. This status code is differently called unauthorized. If we are talking about its textual name.

Code four oh three status code tells us that even though we have entered the correct username or password Our system has imposed some restrictions on us, that is, there are limitations. Perhaps we do not have enough rights to enter this or that resource.

Again, you should pay attention to this if, for example, you have different roles in your system, for example, just a user, a moderator, an administrator, And you should definitely check the fact that when we enter the password and login, for example, a user, he cannot make any significant changes in the work of our site.

So we pay attention to that as well. And of course the most common and well known error is four oh four when our client accesses a resource that is no longer on the server. And of course server errors they are the most critical. That is, the most basic of them is five hundred. If we see this error, then we must necessarily have a bug showstopper, critical, blocker. That is, we mean such severity necessarily. That is, in this case, something happened on the server,

Some fatal error that prevents it from responding to your request, so this is very serious for our software. That's about status codes in a nutshell. I would like to point out that you should definitely know all five of these types, know a few examples of each of them, at least the most common ones, which I have told you today as part of this lesson because at job interviews you are often asked to give these examples and tell what they represent.

In fact there are a lot of status codes and it is unrealistic to memorize them all. This is um reference information. That is if you find a status quote that you don't know. That is not one of the main ones. You just Google it and see what it is. Also, some companies have their own custom status codes, meaning developers can assign them to some certain specific functionality and responses. So again, when you come to some project, a new company. And you see code that is unknown to you.

You can. First of all, find it out in the documentation if you have it on your project, or go directly to the developer and find out what it is. That's the status of the code. And the last thing I wanted to talk about today is the HTTP protocol versions. As I said, this information is in both the requester and the responder. The very first version of the HTTP protocol is zero to nine, then this not even Why is that? Because this version was invented spontaneously and

It simply could not be assigned a certain number. Then there was already a version of HTTP10. That is when there were already some standardized things. Me and there was information about, if I'm not mistaken, three methods, get post and put, and then was the HTTP one one version, which is actually now most often found on some resources. After HTTP one there was HTTP two zero. In fact, this protocol was originally called C D BPI. That is, if we are talking about version 2.0.

It was invented by Google in order to raise the performance of this protocol, because already at the stage of modern technology this protocol HTTP 1.1 was becoming obsolete, but later, all other companies picked it up. And realize that some improvements were needed in version of the previous one one and this protocol was taken, standardized, and now it is called HTTP two two zero. The HTTP two zero protocol has undeniable advantages over HTTP 1.1.

So if your company has to choose between these two versions of protocols, of course it is better to use two zero. What are these undeniable advantages? Unlike one, one, two, zero uses. binary format that is zeros and ones. The one to one version uses a text format.

As you realize, using zeros and ones greatly reduces the amount of information that needs to be transmitted to the server and the server. Transmits it back to the client. The text format Has its disadvantages here because it takes a lot more space and it takes longer to transmit. So it has a very good impact on performance. The second plus is that HTTP 20 row is faster. That is there is a reduction of information there again due to the same binary format.

And because of the fact that there is compression of our header headers. If we take the HTTP protocol version 1T1 and study the various requests and responses that are written using this protocol, then you may notice that there is a lot of header double posting. This is not the case in HTTP tooth zero. The main reason for this is that HTTP two zero is multiplexed. So what does that mean if version one one each of our request?

whether it's sending HTML code, sending CSS, sending JavaScript, they go over a separate TCP connection. If we remember This is a transport protocol, so every request is a separate TCP connection. If we talk about Protocol version two as zero. Then all these requests pass through one single TCP connection. That is, there is no distinction as to what information they send to the server. they always go over the same T C P

In version 1.1, as I said, there will be as many of these TCP connections as there are requests and types of information that we send to and receive from the server. Again, if we're talking about multiplex Then in the one one version, all of these requests come one after another. For example, first we get some text information, HTML, then we get some style information, CSS, then we get JavaScript information, some dynamic update of our page.

And so these are all these connections going through one after another. In two pot zero, there's no such thing. That is we have one connection and the information is transmitted simultaneously, both from the request side and from the response side from the server. That is they all these actions happen in parallel. You don't have to wait for the end of a certain type of request.

Everything happens at once. These are perhaps the main differences between these two versions of protocols. And now I remember what I wanted to tell you more today. This is how we can visually see how our requests and responses come, where we can see the information about the protocol version and the status of the code.

So let's go with you now to the browser and I'll show you how to do this. I've opened the Onliner site in advance. If you live in Belarus, I think everyone knows what kind of resource this is. If not, you can open any. Sites that you are interested in and perform the same operations. In order for us to work with requests and answers, we need to open the so-called dev tools, that is,

Developer tools already inside our browser. These tools are available in all known browsers and they usually open after clicking F12. Next, we navigate to the network tab and refresh our page. As you can see, our initial requests have already passed and we have received some responses from our server. And here we can already discover some initial information. That is, we can see the method that is used and we can see the status quo. In other words, everything has successfully passed here.

And the version of our protocol. If you don't have any of these columns, you just right-click and customize them as you need based on what you're interested in. When we open any of these requests, Then here you can already see detailed information about what we sent to the server and what we received from it. This includes information about our requested URL, the method that was used, and details about our status code. We have everything here. The header information is included in our response.

You can see all of it right here. If we notice any errors like the status code four oh four or a five hundred error then we definitely have a bug. The bug is typically logged as we've already done in Jira or Azure DevOps or another tracking system or even in Excel. Ideally, you should copy the information about our requester and take a screenshot. Make sure that it's the DevTools information to get in the screenshot.

And on top of that, you can save all this information in a special archive, which your developer will be able to open on his computer and view all the information about responses, requests. And what happened when you sent this or that request to the server. Further on in our lessons, we will work with DevTools. In more detail, I will tell you about the basic element.

blocks that are in this tool. They work similarly in all browsers. There's some additional functionality somewhere, but we'll probably most often refer to Google Chrome and uh the dev tools that are In this browser. Also, this tool has a great written documentation that you can also read. Familiarize yourself with it. I will leave a link to this documentation in the description of this video.

That's all I wanted to tell you about the HTTP protocol today. I hope that this information has made your heads a little clearer about how this protocol works in general. and how we send requests. The responses that we receive from the server, what we should pay attention to when testing, and in the future at interviews or in real work

you will have no questions and you can easily understand what? The bottlenecks are in the answers. Or sending requests to the server Additionally, I would like to remind you that I have a telegram channel where I regularly post information on what you should focus on when preparing for an interview for a novice tester position. There are already multiple articles available with useful links and answers to the most frequently asked questions.

Moreover, I will be sharing links to literature that I personally read when I decided to pursue a career in it and to become a test. And of course, links to my videos on this channel and perhaps things I don't have time to cover in these classes. That's all for me. Please subscribe to this channel. Welcome to our shalash. Bye.

Hello YouTube. In today's lesson, let's continue studying web application testing and talk about the basic concepts that will make it easier for you to understand the subject area and give you the necessary theoretical background to continue our work together. Don't be frightened, we will spend the next few lessons in the practical mode, but for now let's bear with the theory for a while. Let's start with a simple one.

Let's imagine that we open a browser. What's the first thing we do? Most likely we type a URL into the address bar, or Uniform Resource Locator. This is a unique address of a website on the web. which defines its location on the internet. There are also two other concepts, Yuran and Yuri. Yuran is an unchangeable sequence of characters that defines only the name of some resource. This name defines only the name of the resource itself. But it does not tell you how to connect to it.

There is also a concept known as Urai, which stands for our unique identifier. This is a broader notion encompassing multiple ways to identify our resource. It includes both URL and Earn, and it can incorporate them either separately or together. Therefore, we can consider N. Identifier as our locator or an identifier as a name or even an identifier as both our URL and URN combined.

Now, let's examine some examples to give you a clearer understanding of how these three types of entities differ from one another. So look. Here, what? In our address bar stands for identifier, what stands for locator, and what stands for name. As you can see our locator defines the way that we're going to access it and the address bar itself, which is directly the address of the location on the network.

If we are talking about the name, then we are not interested in how we are going to access the file. We are primarily interested only in the name of the file. So we are not interested in the name of the protocol and the address itself in this case. And as I said, an identifier includes both the locator and the name.

But can also include them separately. Since we are talking about addresses, then of course if we are talking about the internet, it is necessary to pay attention to the IP address. What is it? It is a unique network address of a node in a computer network built on the IP protocol. And IP address is either a thirty two bit by IPv4 or a one twenty eight bit. The IPv6 version is a binary number.

Here we have four binary numbers, each of which can include eight bits. There are four such clusters in total, so 32 bits or four bytes, but using the binary number system to write. IP addresses is not very convenient. They get cumbersome, so most often IP address you see in the form of decimal. Numbers, that is, they are simply translated into them.

And each such decimal number cannot be greater than two hundred and fifty five. Sometimes at interviews you may be asked how to translate IP addresses from. decimal to binary and vice versa. Let's review together how this can be done easily and simply. Let's convert a number from decimal to binary. For example, let's take nineteen. How can this be done without using any calculators or the same converters to other systems? To do this we take the number itself, for instance. It will be nineteen.

And divide it by two. Here, the usual rules of arithmetic apply. That means if we cannot divide this number without a remainder, we take the closest possible number that is divisible by two. We write it down, and this remainder will be one. Then we divide the number we have as a result of the division, which in this case is nine by two again. This situation is repeated once more, meaning we again write down the closest possible number and the remainder is one.

So we keep doing this until we have such a situation that we cannot continue our division by two. That is in this case we have one last. When we divide it by two, we get a number not integer zero, five. We write it as zero. And here again we write the remainder. This zero we do not take into account the last one, but we take into account only that we can easily divide it by two. And further we write down this number, starting from the most recent obtained. Uh and to the very first

This number we will get in. Binary system. I hope it is clear to you how to do it. In any case, I will post these pictures in Telegram. So that You can easily look at them and refresh your memory and somehow structure the data that you have received in the framework of this lesson. If we talk about the reverse situation when we need to convert from binary to decimal, then we take our number in binary and starting from the last one, number it. That is zero, one, two, three, four.

We have a total of five digits. Amen. In a given number. And then we start multiplying our digits in this number by two to the degree that will be given at the top, that is the ordinal number of this number. After that, we plus all the values that we got and we get our number in.

decimal form. That is, there is nothing complicated about it. You just need to practice on some numbers, on examples, in order to build up your hand. And in case you do get asked this, I've never actually been asked this in interviews, but In my course that I took at the IT Academy, we looked at examples like this and in principle it's never unnecessary. To study these translations.

Of course, there are online converters and even the built in. Windows calculator has the ability to convert numbers from decimal to binary and vice versa. So uh you can use that too, but there's always the possibility that you'll be Can still ask in interviews how this can be done simply on a piece of paper. The next aspect that I would like to touch on within an IP address is the subnet mask. When an IP address is assigned to an interface

Such as a network adapter on a computer or router. Then, in addition to the address of that device itself, the IP address, it is also assigned a subnet mask. Computer subnet mask is needed to define the boundaries. Of the subnet itself, so that everyone can determine who is in the same subnet network with him and who's outside of. A subnet mask is essentially a 32-bit tool, but unlike an IP address, zeros and ones cannot alternate.

There are always a few ones first, followed by a few zeros. For example, if you and I look at the subnet mask, in English it is called a subnet mask. You can see that we have only ones first and then zeros. That means we cannot have such a thing as in IP address where there is alternation. In a subnet mask the structure is much stricter and more predictable. I think that after considering the IP address, it became clear to you that such a record in the form of

Binary system of calculations is not very convenient. So they use a simplified version, right? Just the number of units that we have in the mask under the network. That is Here we have them 25, so after IP address can put a slash and write the number 25. I think that those of you who have ever set up a browser or network connection on a Windows system. You have paid attention to IP addresses? And how they are written there. Subnet mask that is sometimes you can meet such an entry with a slash.

And the number of these very units that we have in the subnet mask. But also you may have met another entry when we do not write this subnet mask with a slash, but in general, the boundary of our subnetwork is written in this form. Then, here is already taken into account both the subnetwork mask and the IP address itself. How do you define the subnetwork boundary in general? That is, we take our

IP address takes the mask under the network and each digit that is contained in these addresses, it is multiplied by each other. And as a result, we get this. Record, which is also further translated into a distief system of calculus for convenience.

That is, if we pay attention, we have twenty five units in the network mask. We multiplied all of them. That is, this address is completely the same as in the IP address. And where we had Zeros and units which are multiplied to zeros, meaning they are all written as zeros. Also when they talk about Yeah IP address there is a static and a dynamic IP address.

If we talk about dynamic IP address, it is automatically assigned when the device connects to the network and is used for limited period of time, usually until the end of the connection session. This does not happen with a static one, that is we always have the same IP address. Also, in the topic of all these addresses, it is also worth mentioning MAC address.

This is the physical address of our device. It is written to when the network card is manufactured, that is, if you are suddenly asked in interviews how many or MAC addresses there are in a system, you should always say that it is the same number as the number of network cards we have installed in the equipment that belongs to this system. I mean if we have a a network card in our printer.

It would also have a MAC address and be counted in that total number. That is, it is not always true to say that if we have, for example, uh a network card in the computer that is responsible. For our connection via Wi-Fi, it is one. We always count all the devices that are connected to the computer and that. have a MAC address meaning that uh they can go online. Now we know what an IP address is, that is it is. Unique number of each device on the Internet.

And to get to the site of the We need to know what we IP address of the device on which this site is located. Let's imagine with you how many sites you visit every day. If they were all encrypted in this digital form, in the form of IP addresses, then imagine how many numbers, digits you would have to keep in your head. It's unreal. Therefore, for our convenience, for the convenience of working on the internet back in 80h years was created a system of domain names.

or it is still called DNS domain name system. The meaning of it is that each digital IP address is assigned a clear alphabetic name or it is also called a domain. That is, when you enter a domain name in the browser, these DNS servers convert it into an IP address. That is, each of our domain, each URL has a correspondence. IP address server and with the help of DNS this information in the letter value is converted into a numerical value.

And the server can understand what they want and what information they want to get. So we already get. information from the servers in this alphabetic form using the to DNS conversion. And the last part of our lesson will be devoted to browser cache and cookies. What is browser cachet and what is it for? When you surf the internet downloading browsing web pages, you may not even be aware of it. Your browser automatically saves certain data to your computer's hard disk.

This can include various elements of website design such as pictures, images, video files, music and much more. This process is done so that the next time you access the page, it will load more quickly. This is because some of the information is downloaded not from the server, but directly from your hard disk. Thank you. This end is our cachet. That is it is data. which are downloaded from our computer in order to simplify our work on those sites that we used to.

Visit that is to speed it up and not to load, so server. as it could be, if we every time turn to it, in search of the necessary to us Media information, for example. If we are talking about cookies, these are also temporary files that are stored on the hard disk of the user's computer. However, cookies are used to store User's personal data. What can it be? It can be authorization data or login and password.

Settings on certain sites, your preferences. That is at the moment when we visit a page, the browser sends this data to the server, thanks to which for example, allows us to get to our personal page in a social network. without having to constantly enter our login and password on the page of authorization to this network. Also, this data can be taken into account by when providing you with contextual advertising, that is, your preferences are saved in the browser.

And based on these preferences, the advertisements that will be shown to you will be the ones you're most likely to be interested in. This is an important aspect of cookies in cachet that you should be aware of. In the next lesson we will explore DevTools, which we mentioned. In our second lesson To review the main tabs within it and understand how they can assist us in testing.

I haven't decided yet. I will tell you about HTML and CSS in a couple of words, or if we won't have time, or if the lesson will be very long, I will tell you. about CSS and HTML in the next lessons. So be sure to stay with me. The subscribe button will help you. It's only going to get more interesting from here on out. In the meantime, write in the comments whether this lesson was useful for you and what else you would like to learn about testing web applications.

I remind you that you can find useful links to articles and literature in my telegram channel or in the description of to some videos. And that's all for now. Welcome to our tent. Bye.

Hello YouTube. It's been a while since we've seen each other, but that's for a reason. Uh as you know, I live in the Republic of Belarus. The last video was just recorded about the situation in our country now. In principle, it continues, it is developing. Nothing much has changed, only that law enforcers now do not use. Force. No matter how tautological it sounds, but the situation is still difficult. On top of that, during this period of time I managed to change my job.

Now I work in a product company and I'm also going through the process of onboarding. So free time is not so much now. All my thoughts are occupied with both work and events happening in my homeland. But still, to distract myself, I decided to record this video and still continue our training in testing. In this case, testing web applications. As promised today, we are going to talk about DevTools.

This is a special package for web application development. It is also used for testing and is built directly into the browser itself, whether it is Google Chrome or Mozilla. They're of course a little differently called the development package. In general, every browser has it. But today we will consider this tool within the browser Google Chrome, as it is currently the most common.

And in principle, everything you learn today you can apply to. Other tools that are built into the Other brows however. Boot two edge which is now by the way written on Chromium so there in principle it is exactly the same as in Chrome, in Mozilla, in Firefox, in Opera and in Internet Explorer. There are also similar utilities in all these browsers.

Why are we going to study this tool together? Because it is quite common in the development environment, and it helps to develop and test web applications. There is some truly excellent documentation written on Chrome DevTools. You can read it, study it, and learn all the features that. suggest using DevTools. So I highly recommend that you read that as well. I'll make sure to leave a link to that documentation in the description of this video. Now let's get down to business.

So how do we invoke Chrome DevTools? Well there are several ways to do it. The easiest method is to right click and select view code, especially if we're talking about Russian. If we say In English, then there will be an instruction. If I'm not mistaken, inspect element and you can click that too and you'll see Chrome DevTools. You can also do it by pressing. Key F twelve.

Also by default, this key brings up all such tools in other browsers. In the same way you can also invoke this utility. How can we customize this console at all? As you can see it is currently located on the right. If you click on the three dots here, you can change its location altogether. It can be at the bottom, it can be on the left, or it can be in a separate window.

For example, if you have two monitors that you're working on, you can simply move this DevTools to a separate monitor on a separate screen. and work directly on the browser itself on one monitor and in Chrome DevTools on the other. Let's go back to And here's another way to call this console. For instance, if you close it now, click on it and then click on view code. As I mentioned earlier, it will directly open the chtml file. It will open on the element that you wanted to inspect.

So when you click view code here, it opens up a line that specifically spells out how this file, how this particular element should look on the page. As I said, we will also talk about HTML and CSS. But not within the framework of this lesson. A little later in other lessons within the framework of studying and testing web-oriented applications. Here you can, when you open the console in the Elements tab, after inspecting an element, see how it is written in the layout in.

HTML file view its dimensions. There is also information about accessibility, that is, all of this will be written here. Also, you can directly here to change this file. And the change in this code, in this attribute, will be directly displayed on your page. For example, if you and I look at the code of some header. And start to change it for example, remove the word mobile, then as you can see the information on the page itself will change.

This is how you can test, for example, headlines when you enter a large number of characters, how they will. be displayed whether they will not drive in. On other elements on the page, or vice versa, if you enter one character or no character at all, how it will also be displayed, you can see how On you I will be displayed. this element on the page. So this is used in testing.

Also, if you and I go a little bit lower you will see the styles tab. Here you will already have information about CSS, about the design of all these elements, that is the sizes will be described, the fonts that are used when writing. And all of this can be check it out here. paddings, margins, that is all of this we will also discuss a little bit in detail in the next lessons. Just know that in the styles tab for example, you can see what color was applied.

Of this or that element, what finds When you test the UI, opening some mockups templates of your page, which were provided to you by designers, they will also have information about what fonts, what size, what uh elements pictures should be used, what color, what size. used and you should definitely check whether the developer really took this into account when writing the code, when

layout of this page. So you're just comparing to see if that's really the case and if it matches our template directly. Also the next tab is the console. In the console we have the JavaScript execution errors and in general in this console you can execute various scripts written in JavaScript that is SU.

See we have some errors here. There are warnings about some errors that may occur in the future. We should definitely study all this, and in case we find such bugs, we need to introduce bugs, troking system bugs. How is this done? You directly write under what conditions. This or that error is reproduced and displayed in the console. That is what you open.

What steps of reproduction and then you copy just all the information that you have. There is in the console on this bug and attach this information to the bug. The developer having received this information later can process it and find out what the main reason is. That is, we, as a manual tester, especially at the level of June, do not need to know all the peculiarities of JavaScript, how it is processed.

Why does such an error occur? This is already the developer's task. The main thing for us is to find this error. Formalize it, write a bug report and see if the developers have really fixed it. This or that error, we should definitely report all errors too. Checkout Critic or Blogger depending on what you have checkout on the project. If again we have some varnings which in future can also lead to errors, they are highlighted in yellow here.

They should also be reported because they can lead to some serious errors in the future. Therefore, in the same way as described above, we formalize these errors in our backtracking systems or in other systems used in your project. Typically these errors are written by the developers themselves. meaning they do not use the default ones. However, if the developers are lazy, they might resort to using the default errors provided by our browser.

Regarding this tab, we can also select what we want to see in general. For example, if we remove error information, it disappears and we only see some warnings in the Aning. If we add it, we can see it. That is all this can also be customizable. That is at your leisure, you can click through everything that is written here and see what it can lead to. The next tab is sources.

Here we have information about the servers that our client accesses, that is, is information that is directly on the server of the online itself. But also for example some pictures or or I don't know information about exchange rates maybe. Media files are taken from other servers so we can also see where they come from. All of this information is contained here. In fact I probably have not used this tab once in my work, but it is quite possible that your project will use as well.

The most important tab that is generally used during testing is the network tab. Here we have information about communication between our server and client. This is an important tab because here we can see the requests that the client sends and the responses that the server returns. All of this can be explored here.

You and I are in our first class on testing web-centric applications, the link will appear at the top now. We talked about this a little bit when we looked at the HTTP protocol, but we can definitely come back to this again. So what can we actually have in this tab? Directly in XHR, this is where we find detailed information about requests sent directly to the web server. And also about downloading the responses from those servers that directly call the scripts.

This is our main tab within network. Additionally here, there are tabs like all, meaning here we have requests of all types displayed. If we're talking about JS, this is where you'll find information about the JavaScript we're running on the page. CSS is information directly about CSS. Image this is information about the images that we have loaded. Media information about various media files, be it videos or some audio files, foundation information about

Fonts. Doc, this is the information that we enter into the address bar and send a request to the server. That is, here we display such requests. WS is WebSocket. WebSocket is a protocol that allows exchanging messages between a browser and a server in real time mode. Time. That is, here are displayed exactly these messages of our client and server. Manifest is a special.

JSON files. We will talk about JSON format in more detail when we start the topic of API. But just to give you a simple understanding of what a manifest is, As I said, these are special. JSON files. Special information about our web application for our browser. And in the other tab we have everything else that didn't get. Differentiated by these different tabs here. Going back to XHR, which is our main tab where we work in network, here we can see directly the name.

Of our request, the method that our HTTP request uses, the status code that returns the server protocol, here we will have information about the version of our protocol. As you and I remember there are versions one to one and two. If you forgot again, you can go back to to the video dedicated to the HTTP protocol, where I talked in detail about the differences in the versions of these protocols. Type okay, that would be XHR, which stands for XML H T P prequest. Initiate is the

File or site that initiated this request, meaning where the request originated. Size is the size of the request or response in bytes. There's also time here, which represents the total processing time for this request. And waterfall. This shows you a timeline of how our events have progressed in general. If we look at the status bar, we can see a detailed breakdown of how much time was spent sending the request and receiving a response from the server. That is, we can analyze all this too.

In order to understand if we have any performance problems, there is also such a checkbox as disable cash. That is, we disable cache save saving on this page. This is necessary so that when we accept some requests during testing. does not use old data that could somehow affect the further outcome of our actions. So the cache is turned off. Preserve log is a record of our log, that is the logging of the process.

Again, so that if we have some errors that appear as a result of our work, we can save this log and pass it to the developer for further analysis. There is also the possibility of simulating different conditions. That is we can set it as if we have a fast 3G internet connection or a A slow 3G connection or if we are offline at all. What will happen to our internet connection? If you are using the page, what status codes will be sent? You can customize and select all this here.

And it is not necessary, for example, to connect specifically to some dedicated network adapter that uses. For example, 3G or 4G or Wi-Fi, we can customize that here. There are also some custom settings that you can add yourself in order to simulate the work of various connections. The next tab is performance. This tab is essential for both you and me to generally keep track of the performance of our site,

For instance, observe how it is done. For example, if you and I initiate the process of recording what occurred. During the operation of our site, we can click record, refresh our page, and then click stop. Let's wait a moment while the processing of what was happening takes place. And here you can see information about how long certain processes took place on our site and how they could affect our performance.

Then you have a diagram like this where there are different ratios of certain processes in terms of time, how long they took. This can all be analyzed as well. If we talk about this diagram, something is not indicated. If we're talking about lowing, that's the load time of our page. Scripting is the time of running scripts on our page and some math calculations. Rendering is the time. Rendering processes that is the arrangement of layers and blocks on our page are colourless.

And paging is when we have these colorless layers and blocks are colored. That is how much time it takes. System is some system processes. Idle is the time of inactivity in general that we have had during the time of our post. What is this good for? Because we can analyze how much time was spent.

For example, if you have some standards that it should take you so many milliseconds to load, and you realize that during performance testing this time has increased very much, it means that something affected it. You have to analyze it or If you do not have enough knowledge for this analysis, you can simply save information about how you had. This process of loading the page, it's easy to do, so you just save by clicking this button.

And then you send it to the developer, for example, in a bug report of some kind. That is you indicate that your page load time is greatly exaggerated compared to, for example, some empirical data that were obtained earlier and it gets this file, it can upload it back to itself. So our file here it is. It downloads it and it also displays all the same information that you had in your browser. The moment when you started this process of recording the performance of this or that resource.

and he can see it all, analyze it, look at it, understand in general. Maybe it depends on the browser what was happening in general. What influenced. The process of loading, rendering, scripting, All this he can. View. Plus here again you can simulate some processes related to the speed of the internet or its complete shutdown or or Slowing down our CPU, that is speaking in a enjoyable manner. All this can be done here as well. Another tab is security.

Here you can see in general what protocols are applied on the page you are testing, whether they are secure. That is, as we know, there are two types of protocols. They are HTTP and HTTPS, which we mostly use on the internet. To display this or that page. If we are talking about HTTP, this protocol is insecure and is potentially insecure.

If we're talking about HTTPS, this protocol is secure and encrypted. That is, we already use an SSL certificate. And you can also view this information exactly in the security tab what protocol you are using. View the certificate itself information about whether it is valid or not. If we had HTTP protocol used here, there was information highlighted in red. It says that this protocol is potentially insecure. And in the page loads

Uh we would have that information displayed. You are sure that you want to use an insecure connection. Why is it important to open the security tab and check this? Because Often some sites use information from other sites, from other servers that may already be using the HTTP protocol that insecure. And for example, if you have some financial information on your project. passwords, addresses, appearances, then it is not safe to transmit this information via HTTP protocol.

That is, when you study this information, you will see that you do have sites that are accessed directly by the resource that you are testing. And those sites are using the HTTP protocol. You should also report this to the developer, that a potentially insecure protocol is being used on your site.

Um and we need to do something about it. Uh maybe you have some agreements, requirements, where this HTTP protocol is spelled out on your project that we can use it on other resources, but But then if that's not the case, it's better to once again ask the developers, business analysts, production designer if can really use this protocol directly on this site. and if it's not an issue. That's about the security tab. When you practice, for example,

With DevTools, I believe that you will definitely take a look at the security tab on various resources, and then you will observe when we use the HTTP protocol and what is specifically shown in this tab. Additionally Besides the main tabs that we have examined today, there are also Tabs that are directly related to extensions that are used in the browser although it is not part of the The scope of this tutorial And in principle you will not need to use these tabs for your work.

I would also like to note that on this panel in DevTools there are additional buttons That also simplify the work of the tester. For example, you can inspect an element as I've already told you. You can do this by simply right-clicking on some element and view the code. Or you can click on such an arrow. And point to the element you are interested in, and there will be information about that element, some basic information about that element.

Plus if you click on it, you will be taken directly to the line in the HTML that describes the element. It is also very convenient for, for example, mobile testing, or if you suddenly know that you will use mech for of your site. Here you can customize different resolutions for different devices. That is, you can select, for example, some pre-installed, for example, Pixel 2. It will automatically to you draw the resolution that is used in the Pixel 2 smartphone.

And you can see how this page will be displayed on the screen of this smartphone. This is very convenient if, for example, you don't have a mobile app but you need to test on some specific resolution, then you can customize it all here. And again, this is where you can. simulate different connections soon. We can also see how the page behaves if we flip the phone vertically, horizontally. So you can see that here as well.

I would also like to tell you that you can simulate the work of various sensors that can be used in mobile devices. This is also very easy to do. We click on Three of these dots right here, click mod tools and select sensors. And here we have sensor for example, we can look at GPS. That is we can customize it as if we had a device in London, in Moscow, in some other city. That is, we can customize all of this here. You can also simulate the accelerometer.

You can find that there as well. There's also an interesting option to connect our cell phone directly to our computer and use Chrome DevTools and view the of this phone screen directly in our Google Chrome browser. This topic is more related to mobile testing, so I will not be covering it in this particular lesson. However, if you are still interested in learning how this can be done and how you can connect your phone and use Chrome DevTools,

using our computer or laptop, be sure to write about it in the comments section. I'll make sure to talk about it in detail In the mobile app testing videos. And that's all for me today. We've had a very productive day diving into the details of a tool like Chrome DevTools. We covered what tabs are available and how you can effectively use them during testing. I truly hope this video has been really useful to you. If it has

Please leave your likes, write some comments and subscribe to this channel. Your support means a lot to me. We are already more than three hundred strong. I am extremely pleased that this topic interests such a wide range of viewers. Let's call you that. You and I are doing a good deed by learning. I hope this knowledge helps you become more confident in testing and land your first job. See you soon. Welcome to our tent. Bye!

Hello YouTube. Last week we had a fruitful conversation about what Chrome DevTools is, what tabs it has, and what this tool can be used for when. Testing web oriented applications. As promised this week we'll cover HTML and CSS. But I will warn you right away not in the direction that we will learn how to lay out pages. Describe the design of these pages and style in CSS files. No, we will learn in general what. HTML code consists of where you can see a description of it. Cold and uh

description of its style and design with CSS. This way you can get an idea of how to test these two elements using these two formal languages. Let's begin with HTML. What exactly is it? HTML instructs the browser on what elements should be present on the page. In other words, it is with HTML that we define various text blocks. The information within them and how they should appear on our page, essentially laying out our site. Plus, with the help of HTML, you can also set some simple styles.

describe fonts, add various elements to the page, or even add pictures. But for customization, in a significant way we use CSS, we will talk about. A little later. When we discuss HTML in English, its full name is Hypertext Markup Language. That is, it is a Hypertext Markup language. Let's design a separate node which we will call HTML. Right away, I want to point out that HTML is not a development language, a programming language. So don't fall for it when you are asked.

For example, what programming languages do you know? You don't need to say HTML. That is, programming languages are Java, JS, Python, and other programming languages known to everyone. Please do not call HTML. HTML is a subspecies of XML. XML is extended markup language, so it's an extended markup language, and it's used for API testing.

It is prescribed in sub-protocols, which we will discuss a little bit further on within the framework of testing, as I mentioned, APIs. That's where XML comes into play, so these languages are quite similar. We will later go over the rules of writing files in XML, because this is frequently asked in interviews. And it is crucial when testing APIs. Now let's return to HTML. Thank you.

A unit of information in HTML is a tag that is bracketed. I think that tags with you we have all seen. That is it is. such brackets which contain some tag that is the name of this tag. For example, there is such a famous tag as A. This is hyperlink. That is, we can write hyperlinks here. Tag B, for example, says that our tag should be written in bold. And such text should have a closing part with the slash.

What it looks like for example is For B that is again our curly bracket slash tag name and then we close that curly bracket so we will definitely need this kind of closing tag. such closing tax are used if there is some information between our two tax, but there are also tax that Do not need to be closed. For example, such tags include the input tag, the IMG tag. That is, as you can see, you just need to put it before the second closing bracket.

Slash What is the difference between tax with a closing element and tax without it? In that if there is some information between these tags, for example, If we are talking about tags B, which indicate that our font is bold, that is bold, then for example, there may be some text. Let's put it this way.

That is, this text will be displayed in bold on the page. As input, for example, it says that this field is water. So it is just writing that this tag says that we have a water field displayed on the page. That is to say it is a separate element. If we are talking about IMG, then here we need to add some attribute with a link to our picture. Now, what is an attribute?

It is used to specify information, as I mentioned, such as the location of our picture. If we talk about attributes going back to our hyperlink, the A tag, that is for instance the HRF attribute, we can And if we write here the name of some site, for example, yandex.aro, here will be the name of the site itself, for example, yandex, and closing our tag. then we have then on the page that we lay out it will display this Yandex.

In the form of a hyperlink, that is, it will be in blue font underlined, and when you click on this hyperlink, which we have as me.ru, we will go to this site. So this href will serve as an attribute. The attribute clarifies tag info. There's also an attribute like CRS which links to our picture's location, either on our server or the internet. It's similar to HRAF, we write image SRC equals picture location. Amen. For example, disk C folder image and file name. For example, 1png and

Then on our site is put the image, which is located at this location. And it is also important to know about what structure in general has an HTML document. What text we use the main in order to write this structure? Usually the the very first tag is the document type definition and then we have the main Tag of HTML, which must necessarily contain a closing element. And between them there are two tags head and body. Head this is

Some service information that our user does not see. That is, this is the information that is used for the browser and search engine. Next, you and I are going to open up DevTools on some of the sites and see how to look at this at all. And also Body. This is where our document content is already placed, what our user sees. So this is what we have displayed on the site itself.

And already inside these two main tags, closing elements, there are other tags which characterize either service information or information for the user. If we talk for user information, then here we can. Call the same tags A, which leads to some sites, contains cipherlinks in itself. B if we want to write our text in bold, input this is the location of some element, in this case element.

To enter information and some pictures, for example, with links to these pictures on our local machine or on the internet. That is, all these tags are further used. And it is necessary to remember that there are closing elements in them. Some tags do not require these closing elements. That is all of this can be additionally learned. In various sources, for example, on the same YouTube.

I will definitely leave a link for you in the description too. Those resources, those channels that I myself used when I was studying HTML and CSS. There is quite detail. About how you can make your first page. What you need to do for this, some basic tags are described. That is, if you are interested in this topic and you want to try to make your own simple site, you can easily use this link.

And learn to understand in general what an HTML document is, what it consists of, and how to live with it. In principle the information I'm going to tell you now is enough for beginner testers. That is, you need to dig somewhere deep, most of the time even. You will not resort to studying the structure. HTML document when changing stacks. That is, of course, it all depends on the specifics of your companies. Work, but in general.

I will tell you that it is the HTML document. HTML markup is very rarely used for front-end testing purposes. Basically, you will have some mock ups by which you will look at the sizes of certain elements that is to inspect with the help Are dev tools these elements to look at their sizes, to look at the fonts that are used there, to look at some distances from one element to another. That is it is all described.

In all tools for the development and design and mock-ups, that is, you should not have any problems with. And if you have any questions about HTML, please feel free to write in the comments and I will do my best to answer them. If you still cannot find this information on the internet, remember that for a tester it's extremely important to be able to Google what you don't understand. Therefore if you have any questions,

You should not immediately run to a knowledgeable person. Instead, first Google it, read thoroughly, and try to understand everything yourself. And if you don't understand it, only then you need to contact your mentor, for example, at work or To me if you're watching this video here and you're just learning And as I said, let's use the example of our favorite and famous onliner site, which we have already used in our previous lessons, to see how it looks like in a browser in DevTool.

So as I said there is dog type dot html that is written in HTML language. There are HTML tags that both open and close, and there are also head and body tags. Additionally, within these head and body tags, you can open them up and examine the other tags present there. As I mentioned earlier at the beginning, we have in the head section information that is not for users, but rather for our browser.

And it includes various tags. This section contains encoding information as well as information about the scripts that are being utilized on the page. Furthermore, there are the various links that we have on the page, which we do not need, as end users. It is more for the operation of the site itself. We have all this stuff laid out here.

And if we are talking about a BAA, this already contains information about what we have on the page. As you can see, we have mostly everything in scripts here because Online it is written in JavaScript and that JavaScript already draws all the elements on this page, so you cannot see some. Tags that we talked about earlier because they are not used here. Here, that is at leisure, we study, watch videos, learn to recognize these tags, remember their basic properties.

And if you are asked for an interview, you can see it's a very good idea Do not get lost, tell everything we know about HTML, and I'd like to tell you a little bit more about CSS. CSS stands for Cascading Style Sheets. Let's type it out right away so that you can keep in your head what it sounds like. That is a formal language for describing the appearance of a document that is written in HTML. In simple words, is how the elements on our page should look like.

In general, CSS can be set in three different places. That is, we can specify our test listing features of certain elements and set them in three different places. First, can be set inside D HTML itself. inside the style tag. I mean it all looks pretty straightforward. This will be again our known tag structure. That is inside this tag will be written for example the size of the font, its color, the location of this element on the page. That is, all this can be specified.

inside our HTML code using style tags. The second way is inside the attribute. That is, for example, we already have familiar tag image IMG and with the help of tag style, or rather not a tag, but an attribute. Sorry, we can also specify information, for example, about the background. Here we use not our style tag but the

uh attribute inside some tag, for example, image. And the third way is when we set some style features inside a separate document, for example, style CSS then is an extension of this document CSS. And we inside our HTML make a link to this document with the help of Tag link that is link relationship at we will have style sheet and href is a link to where we have our file style dot css. That is

These three ways we can also utilize. Where can we find information about what we have encrypted? In CSS? Once again we have the elements tab in Chrome DevTool. And this is where the styles section is located. This is where all the relevant information is contained as well. For instance, if we inspect an element that we have on the page. Here we can see details about the width, about the height, about its position, what background images we're using and the dimensions of those background images.

Images fonts that is all of this here you can look at. The position is also drawn here, that is If we have on the mock up for example, it is written that the borders should be three inches, six pixels. Then we can see it all here. Compare whether it is really so So this is basically what CSS is used for. The styles tab, the computed tab, that is we have all this information written here too. We can open it, look at.

somehow more detailed in general, what we have written here. You can see all of this here. What else is it useful to know, for example, HTML for? In order to use information about locators, that is about the location of our elements on the page in the future when automating. We can look at that here too. Unfortunately, I am not involved in automation, so I will not be able to give you a more detailed tour.

on this topic but I know for sure that if you are going to do this in the future to develop in automation this knowledge of HTML will help you in the future further. For example, you will know this locator and already in the code in your script which must be run to perform a particular test, you will prescribe a specific locator.

On the basis of which when performing the test will be exactly clear where you need to click, for example, in order to log into the system, on what button this is what locators are used for, to put it simply. And returning to the beginning of our lesson, as I said, we did not set ourselves the goal of learning how to lay out a page and bind to it. CSS file also using some attributes and tags inside it.

But just learned in general what HTML consists of: tags, attributes, the structure of the HTML document itself, and where the information about. Styles of various elements from CSS is pulled from how we can bind it to our HTML document or create a separate document with extension style.css, bind it to the HTML document, or create a separate document with the extension style.css. It with an HTML document and later utilize it

Describe the styling features of our page. For a beginner tester, these fundamental concepts will be sufficient. If it's your work, You are going to be engaged in testing web applications in the future. And a lot of attention will be paid to HTML and CSS. I believe you will be informed about it and will be guided on where to find more information. Perhaps. Mentor will share his knowledge, make knowledge transfer for you. So do not be afraid, study, read, watch type all information.

And that's it for me. I'm glad there are more of us every week. That is, every time I record a new video and post it on YouTube, I look at the number of my subscribers and I am truly happy that this topic is interesting to so many people and I always enjoy your feedback. So Make sure to put your likes and uh if you are here for the first time, please subscribe to this channel.

Also, write in the comments whether this video was useful for you and what else you would like to learn about web application testing. There are not so many tutorials on this topic left, so your feedback is really valuable. Perhaps you have some unique requests. These requests might find their way onto my channel as well. Welcome to our shalash. Bye!

Hi YouTube, I'm really glad to see you all in another session on testing web applications. This session is incredibly important to us. So make sure you join in because today we're going to dive deep into learning how you can actually test various web forms. This is essentially what beginner functional testers do for the most part. Make sure to stay until the very end of this video.

Because there's some really interesting information waiting for you there that will definitely help you get more excited about this. Before we talk about the forms themselves, of which there are a huge number. Now you can see on the screen that there are not 10 pieces, but about 20, if not more. And each of these forms has its own peculiarities in testing. Somewhere they overlap. But to understand, for example,

how to uh test text fields or some text areas, you must first understand the issue of validation on pages. There are two types of validation on web forms, on web pages. These are known as Client-side validation and server side validation. So what does that mean? When we talk about client-side validation, this type of validation happens before the moment we send.

a request to the server. So for example, we have a text field where we can enter a first and last name. This field has a limit on the number of characters we can enter. For instance, we can enter up to 15 characters. Into this field. If we enter, for example, 16 characters, the system frowns and gives a validation message. A pop-up window shows us that. The maximum number of characters you can enter in this field is 15. This is

Client side validation meaning even before a request reaches the server, the client processes it and tells us there's an error. This is written in the code itself when developing the front end. And this validation is not considered the best, so there are always Server side validation, because on the client side we can change our layout as we have already seen on the HTML example. We can enter some data, we can change the same validation messages that are displayed on the front end.

and adjust the number of characters. So the server always has its own validation that also checks that for example in field Name, we have entered no more than 15 characters, and indeed such information can be processed by the server. If we have entered 16 characters in this field, this request gets to the server and the server returns its own error. For example, a status code indicating that we have entered more characters than allowed. and thus this request cannot be processed by the server.

That's why there should always be validation on the client side, as well as validation on the server side. And we should always ensure that the client handles this validation if it is specified in our requirements and also verify that the server does too. That is it cannot be that on the client, for example. We show a revolutionary error message that we have a greater number of characters than planned, that is instead of

fifteen sixteen, but the server safely eats this information, processes it and does not realize that it is an error. That is it will already be a critical bug because such errors on the server can be For example, related to security.

Field is not particularly secular, that is, it is first name and surname, but it can be for example a password or information about your card. And if for example Such information gets to the server, incorrect information, and it processes it correctly, as if this information really meets all our requirements and validations, then various risks can arise. Now let's go directly to the forms themselves which we can apply on the site when developing the design. When we wrote our code.

And how can we validate these forms? What are the mandatory checks that we have to do? The first field, which I've already talked a little bit about, is just our text field where we enter some text. What should we be checking here? As you can see, these two fields are mandatory, so it is logical to assume that. One of the checks will be related to the fact that we leave some of the fields empty.

Or we leave two fields empty and for example we try to register in the system. The system should show us some error information that these fields are mandatory and must be filled. That is, we check each of these fields and the two fields together. Also, we are likely to have a character limit here, as I said earlier, in the example.

Client and server validation and here we have to enter so the number of characters that will exceed that allowable limit either. Be equal to that limit and necessarily a value that will be one less. Allowable limit. If you have forgotten why these are the values we should be testing, make sure you go to my lesson on test design techniques where I talked about what test design techniques we can apply. And so one of them, namely boundary value testing, is what we apply here.

The same goes for the number of minimum characters that we can enter in this field. Again, we test the value from the minimum minus one, the value on the boundary itself, and the value of the minimum value plus one. If, for example, it says here that we can only enter Latin characters, then we should check other characters as well, such as Cyrillic. How will the system react to this input? Will it show some validation message that only Latin characters can be entered in this field?

The same applies to various numbers, some special characters. We can also enter just spaces because spaces themselves are counted as one single character. That is When we say we can only enter 15 characters into this field, we're not flushing. The spaces themselves, they will count as full characters. You should also verify when entering one space at the beginning, one space at the end how the system will react.

Also, try entering spaces in the middle of our input. Additionally, speaking of security, we must definitely check the input of various tags. As I mentioned in our last lesson, tags are very easy to distinguish from plain text. That is it will necessarily be parentheses in the form of a greater than and less than sign. That is an opening and closing tag. Why is it important to check tags? Tags are used not only in layout but also

In various scripting languages, for example, in JS. And an attacker can take advantage of this and enter some WordPress script that, for example, will get your information when, enters it directly into this field. So we make sure to check this fact. We also check the tags, for example bold, as we remember it's a bold font. And again.

Whether or not our system is triggered, that is, whether or not it will tempt this tag and for example, whether or not it will be able to display the values that we've entered in bold. Again, this would indicate that the system understands these. tags and doesn't treat them as just text. So these are again potential problems that we have. Related to security, to securitization, and also in these fields must be checked necessarily. Here is our data from the clipboard. That is just CTRL C, CTRLV.

Whether our system can process it and whether we can insert this text here. So you have to look at that too. In principle the same rules apply to some text areas. That is, for example, a text field is limited to the number of characters fifteen. A text area is a certain Large area where we can enter a large text. Usually these areas can also be stretched.

Which means in that case there will be this kind of triangle in the corner here. We can also check whether this area can be stretched, how much it stretches, how the text adapts to the size of this field. That is, we can check all this here as well. Uh so the checks here are the same. The next point is our Prefixes in links. Usually these are the names of HTTP, FTP, HTTPS protocols.

What are we checking here? We check the fact that when we leave this field empty, that is, we do not enter any prefix or we enter it. And various types of protocols. So for example we know that our site runs on HTTPS. So we enter HTTPS here. If we enter here, for example, FTP and they link to our site and enter this site, then In theory, the system should show us some kind of validation message and not find this site, because another protocol is already applied here.

I mean you can see all of that here too directly. We can check the Inca itself that is here we also have. We enter. With our WW without it. We enter the maximum number of characters that can be entered in this field, if it is limited. Again, we remember our border checks, minus 1, plus 1 and on the border itself.

Enter some Russian characters for example. If our system can eat them and process them, then okay. If not, again there should be some kind of error or the resource that we're loading should show. Some kind of message or a status quo that this page was not found, please check what you entered in this field. That is, everything will depend on how much you have. Client validation, client site validation.

whether there are any validation messages. Usually all of this is specified in the requirements. That is, you open the requirements and judging by them. Decide what you have. Should appear, is it a bug if for example you don't have any validation message? And again, don't forget that you can always make some improvements. For example, if you Don't have the fact that when you enter Russian characters.

the system, for example, doesn't swear, doesn't give a validation message, but is good practice, best practice, to uh have that validation message appear and warn you that you're entering Russian characters in that field. Then you can come up with such an improvement, put it in the system, and maybe in the future it will be reviewed. And the same business analysts will write requirements that that Yes, indeed, this validation message should appear. That is

We as quality assurance engineers, even if you are not one but just a tester, we always keep in mind that we are working on improving our quality. And it's not only that we find some bugs, but in general. Improve the quality of our finished product bring some concepts that can significantly impact enhancing the usability of the product itself. Enabling our users to learn more,

learn better and fully grasp how to work with this system. We can explore various other resources where similar mechanisms are implemented, the same features, and analyze how it is done there and how we can further improve our product. Because this can provide us with both improved usability for our users and increased revenue as we will stand out much better among other such similar products. We make sure to pay attention to that.

Also, I think you are all familiar with such a phenomenon as checkboxes. such elements on pages so they can look like this. That is we just have such squares in which we check, check and select the options we need. Also, these checkbox lists can look like this. That is there are some lists that can be expanded and inside. They can also choose the options we need or if

We have again these lists then typically has some sort of main element that includes sub elements and we can put a checkbox on that main element. How we check data? Web element view. Be sure to look at how the system behaves when we don't select anything. And again, if we have, for example, like here, the effects are perhaps mandatory to select. After, for example, subming our form, we should see if the system is swearing that you don't have anything selected.

In this area. Let's see how the system behaves when we select one checkbox, when we select several checkboxes, when we select all of them. Again, it's good practice that we have, for example, when we have a a very large number of different options. There should be a checkbox like check all so that we select all at once rather than sequentially checking each.

of these available options. So again, if that's not there, you can put that in the system as an improvement so that you can consider it in the future. and put it into your project. Yes, it is worth noting the fact that it is also a good practice to make not only the area inside that box clickable, but also the area around it. That is when we click somewhere near it. Also, a checkbox should be placed, so we check that as well.

The next element is a radio button, or in the IT environment it can be called. a radio button in our let's say slang so do not be frightened if you hear such a name. The unique aspect of this element is that we can only select a single parameter. Unlike checkboxes where we can choose multiple options, here we are limited to one, typically by default. Some element is already selected, which can be modified later.

It is also important to note that in radio buttons there isn't an option for no element to be selected. In other words, one element must always be chosen. Let's verify the fact that we cannot select multiple elements. in radio buttons. We check the facts that when we click next to with this element. We also have a check of the option that we select.

The next element is multiple selector. That is that is as the name makes clear, we can select multiple options from a large number of them. Here we check the fact that we can. Select. the parameter itself. One, we can select several parameters. We do not select anything as the system behaves. For example, if you have a drag and drop feature, that is when we take some element and drag.

for example, to list of selected elements. That is that it should work. Well this applies to other elements on the page as well. So that's something we can test as well. Also usually in multiple selectors we have the ability to. Both add an element with plus and remove it. That is, we check if we can do that. We add an item by clicking on the plus sign and delete it by clicking on the minus sign.

If we have any sorting, we also check the fact that we have everything sorted correctly. This also applies to other elements on the pages, that is, we also pay attention to the fact that if we have sorting, there is some filtering that is all this we must necessarily check. If if it is possible to delete all elements, delete them. If it is possible to add all elements,

then add them. Again, if you have the ability to do some kind of search, we type in the search box and see if the search actually works. You can do all of that here. Again, it also depends on what is specified in the requirement. Now I am telling you about some variant that I know of. Again, in your system it may be implemented quite differently. So paying attention, first of all, to the rivers that you have on your project.

The next element I'd like to talk about is the uh the element that allows us to upload any files. Uh it usually looks like this, I think it is also familiar to all of you. What can we check here? First of all, don't select any file to upload, see how the system behaves. Again, if this is some kind of mandatory attribute and at least Submit for example of this form, it do not show validation of some kind. The message then again it could be a bug. We also check the download of the file itself.

That is, here we have it written that the maximum size of the uploaded file is 10 megabytes. That is, it gives us a hint that this file cannot be larger. 10 megabytes. Let's check it again at the very boundary. 10 MB we check because we have two digits after. Comma ten, one and nine ninety-nine megabytes. That is, we check all of this. There are special resources that can generate the files we need if we have requirements to. format that is we can for example upload doc files, XLS and pictures

Then we check all the invalid file formats that we can think of. We check the valid file formats. As you and I remember, the first checks that we always do, they are positive. Positive checks are those that meet our initial requirements. Again, if you've forgotten what positive tests, negative tests are, I have a separate video dedicated to this point related to test classification. Now the link will appear at the top.

Go through, remember, be sure to leave your comments if something is unclear to you. If it is possible to enter, for example, information about the path to a given file, that is, we also enter it here, look, really. Whether it handles it That is we find them. And there are various other interesting things here. I mean, we can go through these challenges as well. If you know something, it is for yourself.

for your development, for your practice. You can click through all of this here, look through it, and the most interesting thing is that there is a Hall of Fame here. This is information about those people who have scored the maximum number of points for this or those other challenges. It's also a cool competitive effect that comes into play. Game Uh also leave a link in the description to that as well. That is go to it, study at

I hope that these links will be useful to you. They will all be in the description of this video. I would also like to note that there are a huge number of checklists on the web dedicated specifically to testing web forums. You can find them, download them, save them for yourself. and use them for your practice. For the future I will tell you there are such checklists for testing mobile applications.

And for testing accessible applications and for some other testing, for security testing, for performance testing. They are made to simplify your work and to make sure that you don't forget anything. Again, these checklists are not the only source of truth. That is you study them, memorize them, save them, and can make some changes in these checklists and use them.

In the future for your practice, for your work, so that you don't forget these or those checks that you should do for Web4. I hope that this video was useful to you, you learned something new for yourself. You will learn how to test these web forms in the future and you will not be confused at interviews when you, for example, will be offered to test the form. With the password and its confirmation.

How it should be done, what checks you will perform, uh, as this is often really asked at uh real job interviews. In real interviews. As always, I ask you to support this video with your likes, write your comments so. As comments promote this video in search. And more people will learn about my channel, learn, and in the future can apply for a position of a tester of some IT company. Develop and take their place in the IT sphere. And that's it for me. As usual, welcome to our sheloche. Bye.

Hi YouTube, it's been a while, which means it's time for another lesson on testing web centric applications. There have been a lot of requests related to the fact that people want to know tell us RTOM, please, about how to test APIs, how to test web services, about REST, about So we are starting this topic today and I decided that It will be more efficient to divide it into two parts. Today I'm going to give you a theoretical background.

I'm going to talk about what the protocols are, what the architectural styles are with a which in App Service communicate with each other in general. Today we will discuss this topic and in the next lesson. We will begin practicing testing APIs and sending requests. I will explain tools such as Swapui and Postman. Additionally, I will show you services where you can practice, including some test APIs and documentation. So make sure to stay tuned to this channel.

I think this information will be useful to you because API testing is quite in demand for testers nowadays and even a novice tester, a genie. needs to know the basic aspects and the basis of how to test web services. I have already said such a phrase or word as web services a few times, so let's talk to you about what it is. Web Services or Web Services is a program that organizes the interaction between websites.

That is, information from one portal is transferred to another. This is in simple terms. If you wrap it up a bit more cleverly, it is such a web oriented technology. Which allows programs to communicate with each other using standard formats such as XML and JSON and through special protocols. Now here I will immediately correct myself. Protocols like SAP and the uh architectural style rest. How they differ I will explain a little further.

So for example, you have a certain airline which has a large number of flights and well consequently a lot of tickets, the information. Through a web service is sent to a travel aggregator site, which is from our airline. With the API we can connect and build in some functionality that will directly With this action, when a user goes to this aggregator, they will be able to directly purchase some airline tickets on the same site without needing to go to the company's site.

Or another example of web services is a weather tracking system. Which contains some information about weather conditions in a particular city or country. This information is also used by third-party applications or some other sites. So we just embed this form where we have the weather information. It can also be projected, for example, on currency rates. That is you have often seen that websites have embedded some kind of Forms where you can make online conversions from one currency to another.

or for example, authorization with the help of some social networks like Google VContacte or Facebook. That is when you, for example, navigate to some site and it says that you can register using Your accounts in other social networks it also functions through an API. I talked about the different interfaces, including EPIs, uh a little bit earlier in the very first lessons on the types and categorization of testing. That is I told you what interfaces exist in general.

Now the link to this lesson will appear at the top so you can go there either to refresh your knowledge or to learn something new for yourself. If you are on this channel for the first time and you have never heard about different interfaces, And then we're going to go smoothly to what I said at the beginning, which is the SOAP protocol is used or the rest architectural style. Let's start with the SOAP protocol.

This is an acronym. The full name is Simple Object Access Protocol. So it literally translates to Simple Object Access Protocol. That is this protocol. Exchanges structured messages to in a distributed computing environment. It sounds really hard, but I'll explain it in a moment. That is, this protocol is used to exchange arbitrary messages in XML format. XML doesn't remind you of anything. You and I were talking about HTML at some point in essence.

The form of writing itself is the same in HTML and XML, but this format has its own peculiarities, which we will talk about a little later in this lesson. Also, SAP can be used with any application layer protocol, if you and I recall. A model like OSI, there was an application layer. Again, now the link to the video on this model will appear at the top. And such protocols are SMTP, FTP, HTTP, HTTPS that is. That is, SAP can use these types of protocols. However

the interaction of this protocol. With other protocols has some peculiarities. that we will not talk about in our course and this lesson. So if you are interested you can Google this information. It is publicly available. These are, shall we say, the materials with an asterisk. First of all, you just need to know that there is a SOAP protocol and it is used in web services. And let's move right on to the next aspect that we need to look at within SOAP.

This is X C D and W S D L. What are these? As I said, in soap. XML files are used to convey any information. And it's XCD, it's XML schema definition. It describes the structure of our HTML document and the types of data that can be stored there. So you have this XCD file in your web service. And with the help of it we can define various elements data inside our XML IKs and transfer them via internet.

That's the interesting thing about CD. The next aspect that I wanted to look at is VSDL, that is, it is such a file. with such an extension and with such a format. It is written in VSTL, which stands for Web Services Description Language. And what is this file for? It describes messages, headers, and events that are specific to our web server. That is, this file describes the entire structure of our web service.

And it is absolutely mandatory for the SAP protocol. That is to say, without this particular file, we simply cannot utilize the SAP protocol at all. In further testing, this file makes the work significantly easier. This is because unlike the REST architectural style, where there is no such document that clearly structures the work of our web service, testing can be somewhat challenging.

So when you have a VSDL, it is indeed a very beneficial thing. Each VSDL document can be divided into the following logical parts. There is a small sample here. What do we even have? In SDL, first of all, has data elements its message? That is, it's the message that our web service uses. Also, there's Information about data types, its type as you can see.

And this information defines the types of XML messages that are sent and received by the service. As you can see here we have strings, so these are just plain strings. There is also a block like port type. This is a list of operations that can be performed on our messages. That is, as you can see in principle I think it will not be difficult to translate from English. That is

There are different types of operations here, get term, get term request, get term response, responses, requests. That is all of this here can be encrypted and spelled out how we will interact with the service in general. with our messages here. What you need to remember is that always if we have soap, we always have VSDL. Because sometimes in a job interview You might be asked, for example, what is the difference between soap and the same rest architectural style?

One of the key differences is the presence of VSDL and the fact that uh as I said, messages are exchanged using XML and the information about how that XML should structure the information is contained in the XSD then. There is XML schema definition. And make sure you memorize the rules that are used when writing the XML IC XML document

Again, these are very often asked in interviews, so let's break them down in more detail. As I said, if we're talking about XML, it's a language that's very similar to HTML, but Unlike HTML, it has, as you can see, a different decoding, which means it's an extended markup language. And if HTML is used for marking up the page for layouts,

Then XML already stores some of the XML is a structure of information and with the help of it this information can be transferred in the communication of our web services. The structural unit of XML is elements. Here is a scheme of such elements, what are they made of? Again, let's think back to our HTML. We covered the basic aspects of it in our last lesson.

As you can see in an element we have an opening tag, a closing tag, content that is stored between these two tags and attributes. So everything is quite similar to HTML. However, what do you need to know when writing or testing XML? And what should you pay attention to? First of all, XML has only one root element. I mean look here. We have a root element called person. That's the correct way to spell it. So here's the opening tag.

And here's the closing tag and we don't have any other root elements. Then we have an incorrect format which happens when we have the root element person as you can see. and it is duplicated again for some reason. So it really should not be like that. We should simply have an opening and closing tag for this root element. The next important aspect is that all elements should definitely have closing tags.

As you can see here we have two tags, person and family. They both have opening and closing tags, however. There is one element that does not have a closing tag. As we remember, the closing tag consists of curly braces and we have a slash before the tag itself. So it's so wrong. We shouldn't leave just one opening tag. The next aspect is that the names of our tags are case sensitive. What does that mean?

In case you don't know what case sensitive means, it refers to the fact that our tags are either uppercase or lowercase sensitive, so we should always use the same. Characters at the beginning of our tag, so as we can see here we have it right, here we don't. Because in one case we have a tag that starts with capitalized otherwise lowercase. So it's wrong. The next point is that the elements must not overlap.

What does that mean? Let's pay attention to the second element, which contains an opening and closing tag. And inside this element contains another element also with an opening and closing tag. So everything is correct here. We have opened a tag. We wrote some information into it, closed it, and inside it, since there is another element we also opened. Tag and closed it. There is no overlap.

If you and I'd pay attention to the wrong writing here. We opened a tag, then we wrote a new tag for some reason. Close this tag and uh the next moment we close the tag that is contained inside. So it's not right that way. I hope I explained it properly. If anything, pause. Just look at the way our elements are written here. The way the tags are written. I think you'll understand when you do a little resurvey. Literally just linger on this rule for one minute.

The next aspect is that all attribute values must be in quotes. As you can see here we have a name attribute with a value of John, but for some reason that value is not enclosed in quotes. So that is incorrect. Here's the second correct option where we have Attribute its value, that value is in quote.

The next attribute, its value is in quotes, so that's the correct one. The next rule is that that the greater than sign, the less than sign, the ampersand icon cannot be used in text blocks. Instead We should write them in text format, like this. That is, you can also pause. Make a screen and memorize for yourself how it should be recorded. I don't think it's worth explaining because as we understand, we use the greater than lesser icon.

Tags themselves and the system may not process them correctly. If we are talking about the impersoned icon, then as you can see, it is already used for text recording of all these elements, and quote marks are used to. To separate attribute values. That is also they may not be handled correctly by our system. One last point is that an XML declaration is always the first.

What is an XML declaration? It is a separate line that contains information about the version number of our XML, an indication of the encoding of our character. And standalone parameter that indicates whether references to external documents are forbidden. That is, remember that we have XML declarations in the first line. These are the basic rules that apply to XML. You need to memorize them because in a job interview, for example, you might be given an XML with

errors and asked to find them, so you need to be prepared for that. And the next aspect to consider when testing web services is REST. REST, as I said, is an architectural style. Just so you understand the difference between an architectural style and a protocol. An architectural style does not apply any rigid rules. It does not require any VSDL, although there is a document format called Vadel, but it is not necessarily required.

That is, if it is not present, then everything is still fine. And that is why REST is being used more and more often now, because this architectural style allows us to write information in a more convenient format. Which takes up less space and increases the performance of our system. And it is also, let's say, not rule dependent. Meaning it has fewer requirements, so it's used more often now. If we talk about the full name, it's representational state transfer.

Also, I want to highlight the term restful. What's the difference between rest and restful? Rest is just an architectural style with which We describe the structure of information transfer in web services, generally speaking, the Thank you. In general, there are some rules related to how this information should be transmitted, then RESTful is already a characteristic of our web services. That is, these are web services that fully meet the requirements of REST.

which impose this architectural style. That is, REST essentially describes the structure of our web service. And RESTful is the web service itself, which meets the requirements of REST. Also Don't get confused or scared if you are asked in a job interview about the differences between these two concepts. And unlike SAP, we use JSON in REST. JSON stands for JavaScript Object Notation.

What you need to know about JSON is that unlike XML, it doesn't have very strict rules. It is much more flexible, as I've already mentioned. JSON takes up less space and is much more convenient to work with. And let's dive into the basic elements that we have in this JSON. To start with, JSON documents are composed of objects. Now objects are essentially an unordered collection of pairs, specifically name and value pairs.

Here we can see the very first node which is associated. With JSON it is an object. An object is typically enclosed within curly brackets and it includes, as I mentioned earlier, Name value pairs, for example, name equals name, value equals Peter, name equals name, value equals Ivan. And these name value pairs are separated by a comma. And the name and the value itself are separated by a colon. That is also nothing complicated here. Just remember that there are curly brackets.

Our name and value are enclosed in a quote. Between themselves the name and value are separated by a colon and the name value pairs are separated by a comma. A name is always a string, meaning the data type for it is a string. And the value itself as we have here, for example, Peter can be either a string or In in double quotes or a number, some logical value that is true or false, an array or the value now. We will discuss arrays a little further on. And the value now.

That is just here is essentially a value of now. If we're talking about a data type like a string, it's an ordered set of zero or more Unicode characters enclosed in double quotes. That is as here is our name, which is essentially the data type string. A string is easily distinguished from any other data type.

If we're talking about prime numbers, they don't need to be enclosed in quotes. And just by the example of an index you can see the difference. If we use a number as a value, we do not write these quotes. And then our system perceives this data as numeric. Only you and I use. Quotation marks to write our number do not confuse. Number record and data type number when we use quotation marks, then automatically this data type turns into a string.

And is perceived by the system as text. If you and I use some Boolean values, then we don't need to use them in quotes as numbers. That is true. False we do not put in quotes. As soon as we enclose true or false in quotes then again it is perceived as string. And the last type of data we will discuss is arrays. So what exactly are arrays? They are essentially a set of our objects. As you and I remember, objects consist of a number of pairs, specifically name and value pairs.

Once we have several of these objects that we want to use, we then enclose them within arrays. An array is always enclosed in square brackets, and the values within that array are separated by commas. So as we can see here we have An object which consists of a name and a value and this object is enclosed in curly braces. And there's another object that also contains a name and a value, also in curly braces.

We separate them from each other with commas. And the whole thing, the array itself, we put in square brackets. This is what concerns REST. It's much simpler here. In the next lesson I will show you the Postman tool, in which you can test both. Swap requests and Rest requested. that is, we will see and feel it all And you will learn how to send some simple requests. There is nothing complicated about it.

Another thing that I would like to point out, as I mentioned in this lesson, very often in interviews people ask what is the difference between REST and swap web services? Let's list these differences. REST supports different formats. So here I've given you JSON, that's the most common, but you can also use And XML and text formats. But SOAP we can only support XML. REST only works.

over HTTP or HTTPS protocols. SAP, unlike REST, can work with a variety of protocols. Read based SAP cannot be cached unlike REST which can then be cached. Well, these are such basic aspects and as I said, rest is an architectural style. Which doesn't have such a huge number of rules that it has to obey, making it more flexible in many scenarios. SUP is a protocol that is highly restricted by the rules that apply to it. Again, remember at least the XML car.

And all the rules I have listed in JSON where there are no such critical rules. So what should be chosen on a rest or sub project? Usually when one asks this question rest against sub, it can be rephrased as simplicity against standard. N in the case of rest this simplicity. You will have speed, extensibility, and support for many formats, and also not as tied to those rules that are to Saab. In the case of Saab, you will have more security options.

And also you will have uh let's say if we are talking about testing more opportunities uh conduct this testing qualitatively because immediately in SAPI you will have VSTLs where samples of your requests will be prescribed that is you will not need to address. To the developer once again to ask him to provide you with information, some sample requests, that is you can immediately take and use them. Testing. Well on top of that. SAP is much more resource intensive than

It takes up more space and it's slower. And generally, if we're talking about development, development using SAP takes longer. That's probably all regarding the theory behind web services. Within the framework of this lesson, of course, I cannot and could not tell you everything that could be related to The testing of web services. But this knowledge pertains to SAPE, REST, the formats used there, the documents involved, which one is faster and which one is easier.

In other words, this is all you will need to successfully interview for an entry-level tester position. I will definitely leave in the description of this video links to lectures, classes that can help you, let's say, to learn about web services with an asterisk. If you're interested by all means go over there because it's more structured, people have been working with these technologies much longer than I have, so you'll probably learn a lot more from them.

Also, as I promised, in the next session we will cover with you the practical aspects of testing web services and testing API. So be sure to subscribe to this channel, leave your comments and ask questions. I'm always interested in getting some feedback from you. I also want to remind you that I have my own telegram channel where I periodically post useful articles.

There you can learn about aspects related to both employment in ETE and useful resources and links. That will help you even further. Get yourself pumped up for testing any application. Whether it is desktop, web or mobile. So thank you very much for watching. Welcome to our tent. Goodbye.

Hello YouTube. Finally, we have your long-awaited video about testing web services from a practical point of view. That is, today in class, you and I will learn about tools like Sopui, which helps us to test swap. We will also learn what Postman is. We will learn how to send some simple requests. Um additionally I will also show you different test beds where you can practice. So let's get started and dive into the fascinating world of testing web services together.

And in general I will show you how you should write test cases, how you should create them, including positive tests, negative tests, mock tests, critical path tests, and extended tests. That is, I will explain all of this in detail so that you won't have any questions in the future. The topic of API testing is quite extensive and complex. But we will try to discuss it thoroughly, and it will help you to pass the interview successfully in the future.

I will not tell you about all features that are in this software. It's a topic for a separate, much larger course, but The data and knowledge that I'll provide you with will be sufficient for you to learn these tools on your own. It will give you a solid foundation so that you won't have any silly questions.

when you come to a project where you will encounter API testing. So let's get started. First and foremost, I would like to say a few words about the principles that I will be guided by Thank you. In this lesson. There is such a wonderful uh tester or tester uh Olga uh Kisileva by her maiden name or Olga Nazina in marriage. She is a great teacher, she has her own course on API testing. This is not as an advertisement, just so you know. And she has a wonderful block in which she

Collects very useful things and articles just for beginner testers as well as for continuing testers. And these are exactly the resources that she is hosting and we will use them. That is, we will not invent a bicycle. For educational purposes, the user system has been developed, which we are going to feel a little bit and find out what it is.

I'll be sure to leave you with links to all of the articles and all of the resources that we're going to be looking at today. But let's start with the user's backward system. In principle we will need it today in class. And here is also, if you follow this link, it will be WSDL. If you and I remember the last lesson, this is our schema, where various methods for SOP requests are described. And there's also information about REST when you and I will be testing REST with JSON.

I get ahead of myself right away. You and I will not need this information, we will use the already written documentation, where examples of requests and responses are written because in this form it is not quite. It is convenient to understand in general what is wanted from us. And in a good way, on all projects you should have sample queries with RISTOM. That is, you contact the developer.

He gives you some example of a query and perhaps answers to this query and you already test with the help of this input data. If there is no such thing then of course your life becomes complicated, but in any case You should start your work with communication with the developer if there is no documentation on the project. If there is documentation available, then we will address it directly. So

You can close this tab as we won't need it today. Additionally, there are links to other resources dedicated to this topic. However, we will not touch upon them today. And that is perhaps all for now. As for this article, here is the second article that we will need. There is also a link to the test Jira, which Olga and her team initiated for training purposes, but

They shared it with the entire internet and we can also make use of it. Here we will be primarily interested in confluence. What is confluence in case you haven't heard? It is a wiki system where all the project data and documentation are collected. That is, usually projects always have such wiki like systems. If we are talking about Jira, it is Confluence. If we are talking about Azure DevOps, It is just a wiki, that is they use the markup language.

Similar to what is written on Wikipedia to collect information about the project requirements. Specs input data. There are some credentials, everything is stored there. So we can always go to Wiki system and see where the project stands. And usually within the various requirements that we already have in our buck decking systems or just project management systems, they all give links to the wiki where that information is stored.

So just so you don't get intimidated, you might have these systems on your projects where you can always look at and find out information about your project. Clicking on this link will take you to Confluence, which already contains the documentation for our user system. So there's information about SOAP and REST and the methods that this system uses. Again, information on FSDL. And rest.

Files with samples of our requests and the methods themselves. Today we will use such a method as door register. Which allows us to register to the system. We will come back to this a little later. Let's start by installing Swapui and Postman itself. Again, I will leave the links to install these resources at In the description, just follow this link.

For Sopui there is a free version that you can download. This is Sopui open source, that is this is where the code of this product is stored in source form. When you click on this link, an installer will be downloaded. You run it, nothing complicated, just click next, next, next, next, next. It installs its software and you can use it. I already have it pre installed so we don't have to waste our time.

Now it's going to load up and I'm going to tell you a little bit about this system. In order for us to get started, we need to create our project. To do this we click on the file new subproject, we write the name of our project and here we need to insert VSDL cool. Either you have it downloaded beforehand or just the URL of this. VSDL. We have this URL and we copy and paste it. Uh we don't need to enter anything else here, just click OK.

All the methods available for our system are then loaded. As I mentioned earlier, we will work with the door gister method. So we open it, click on request1, and here as we can see we already have the parameters that we need to fill in. As I said before, we have documentation. Let's go back to our confluence. Let's uh move it over here a little bit.

And it says here that we have these parameters, email name and password type string. There are three mandatory and the description of these parameters, so it's user email or user and password, what is good about? WSDLCA is that we have everything already written here on the question mark. We have to write our values valid. As you can see, we have here three of these parameters, they are mandatory, so we have

In our positive test we put all this data here and run our request. Everything went smoothly. And as you can see we have entered our data here and also here we have additional parameters that were not specified in are door register methods. These parameters are used for other purposes, for other methods. According to the specification, we don't need them now. So don't be alarmed if you see such an extensive output when you run your query.

As you can see, there is absolutely nothing complicated about this. What is particularly good about SAP and WSDL is that it is always On the project there is a specific scheme Where you simply enter your parameters, knowing whether they are mandatory or optional, and through various combinations you achieve conducting both positive and negative tests. So for instance, here we can remove some of these mandatory parameters and attempt to send such a request as well.

As you can see, we uh we encounter an uh here an incorrect email. We can also enter, for example, some invalid value here, for instance, an invalid email address. We can leave all the fields empty that require mandatory data. Additionally, we can duplicate several parameters to observe what happens in this scenario.

That is, we are already incorporating here the process of modeling our test cases, using the so-called test design techniques. Essentially, as we work with ordinary applications, we apply the same principles when working with APIs. It just depends on your imagination and the test design techniques you use. When you come to a project where swap is used, there will be basically no complications. That is, you will be given an SDL, you will go to Swap Wii, create your projects and start testing.

I advise you to download Swapui in advance and go through it. Search for some examples of other WSDLs. Click through all the methods that are in test based confluency here too. Everything's also described in detail so that you Simply loss your fear of the tool. Since at first it may seem that this application is very complicated, there is a lot of things.

There are, but in fact, for your work as a beginner tester, you will probably only need to create a project, load, into STL and work with the parameters themselves and with various combinations of them. That's what the swapwe tool is all about. Again, I will not talk in detail about each functionality of this application in this lesson, but only give a short tour of the application.

I think everything is clear about Sapui, does not need any additional clarifications. If you have any questions about installing the software, Then be sure to leave them in the comments. I answer to everyone. I think that my subscribers can confirm it by 100% that. Yes. We have a good communication going on, so feel free to ask your questions. Yes, by the way, I completely forgot to tell you, so now we have done everything under the hood.

But we also need to check whether we have this user in our system. As we can see we have this user in our system, that is, the email that we entered, the FIO, is displayed. Also here is provided. The fact that the author of SAP or REST sends this information that is You can immediately see here the dates of changes and also you and I can attempt to log in using our password 123. To do this we first enter our password and then our email.

After that we click authorize and we will successfully log in. That means we encounter no issues. So we need to ensure that we check how our web service is functioning under the hood, sending requests and on the UI, how it is displayed, and whether everything is operating correctly. And the next aspect that we must examine is rest requests alongside the Postman tool. Once more, type in Google Postman and find the official site. It will be the very first one.

Again, I will leave the link for your convenience also in the description below and download this application that is Just download the app. It is downloaded again to the computer, no problems, first the installer, then again next, next, next, next without any changes. And it installs. Additionally, Postman is available in the web version as well. Here you can, for instance, login using your Google account.

The same features available in your accessibility version will be accessible on the web too. However, there are still some limitations, so I recommend downloading Postman directly to your computer. I have already downloaded that tool as well, let's go ahead and open it up. And here we see the UI of our application. Now what is good about Postman? Well, because an entire team of testers can collaborate in it simultaneously.

Developers have the ability to share their test cases and you can also automate and write scripts in JavaScript. You can share this valuable information. With your team, create various collections of your queries, work in different workspaces and create different parameters. The tool is a very interesting multifaceted tool. It is not the most complex, I will tell you right away, so that you do not have again fear of this tool.

At first, you will just use it for testing purposes to select a method, to enter your request, parameters, and send directly this request to the server, receive a response, and study this response. Already from the point of view of testing, whether everything came successfully or not. Let's go back with you to Our conflict. At the very bottom of the method the register enters information. about JSON with an example of how to call it. So there will be this JSON formatted request.

and the response to it, what it should look like. There is not always good documentation for REST requests. So always shake your developer so that they provide you with test data, sample queries, sample responses based on which you will test. Don't be shy, communication is our everything also. There are schemas like in STL and for JSON for rest.

But uh they are not required, so usually they sin and do it and do not write such waddle. So once again, all hope is just to have a good relationship between you. and the developer and establish a process within your team to communicate the information that you need for testing. Before we get directly into testing. With Postman, let's talk literally a little bit more about the methods.

Sometime, a long time ago, at the beginning of the web application testing block, I promised you that I will tell you about methods, how they differ from each other, what it is. A method is a type of HTTP request. that tell the server to what action we Want to take with a resource. That is, you may encounter wordings such as HTTP method. And HTTP request type. These are the same thing. There are four basic Types of methods they are get, post, put, and delete. What are these methods aimed at?

The get method, in principle, by the name it is already clear that it is aimed at getting information from our server. The post method usually serves for Adding information to our resource, for example, If we want to upload some music or to enter password and login in the input fields and send them to the server or to upload some text to our server. That is for this purpose we will put a post, there is also a path.

According to the classics, put serves to replace some information, to change the her on server. The delete method, as its name suggests, is used to delete information. Various sources mention that the POST method can also change information, similar to the PUT method or even delete information. The PUT method can also add information. Ultimately, it depends on how developers choose to use these methods, as you can also create custom methods that will be Amen.

To perform any of the functions. But what else do you need to know about methods? Well, methods are responsible for what's called CRUD operations or CRUD operations. You will come across this uh crane very often in testing. And what does CRUD mean? It stands for create, read, update, delete. Usually, whenever we test something, we have to consider our test object in terms of these four actions.

As an example, there are different permissions. For instance, an ordinary user has permissions only to read A moderator can modify some data on your system. A superuser can create, read, and update data on the system. And then, for example, there's an administrator who can do all of those things simultaneously. And we should always Use various combinations of these four methods.

Operations. This is so that you will not be frightened in the future when you come across such a formulation. And here you see in brackets I have specifically written about each method, what it can do in terms of operations. That is, get is just reading, post, depending on the source in your developer, can be responsible for creating update and delete of some information. Put is creating or modifying. And delete is purely deleting.

Also, quite often during interviews, they ask about the differences between get and post methods. So you should definitely remember that. The get method is very easy to detect and identify because it always appears in the address bar. So whatever we write in the address bar, we are trying to get some information from the internet. And there we can enter various parameters that we are interested in.

Always pay attention to the address bar. GET is an address bar and unlike post method, get has no request body. That is we cannot use get to download any information. In the body of the request, as I told you before, we can have different payloads, different payloads, that is text, music. code, anything, can be contained in the body of the request. And that's what's uploaded to our server. So the post has the request body

The GET doesn't have it. GET requests, as I said, always have parameters that are contained in the address box. Get is limited by the length of the address bar. You need to keep that in mind too. And in principle you can always test this. That is if you know you have limitations.

Uh you can enter the number of characters in the get request and see how the system will behave. Whether it will generate some kind of error, whether this request will be processed at all. Get is cached on the client side too. It should be remembered that data from GET requests fall into the cachet. And since GET is, in fact, our address bar, it can always be saved as a bookmark in our browser.

So keeping these differences in mind, you can successfully answer this question when you're asked what the difference between get and post requests are, uh I've been asked. In my first interviews, it's almost every time, so pay attention to that for sure. If you need to rewind, make a note to yourself what the difference between GET and POST requests are, or simply uh find information on the internet in the form of table comparison.

They are on many resources, and also read about other methods besides these four basic ones. How do they differ? I will tell you right away that pay attention to such a method as option. I will not tell you what it is responsible for, but in principle it is also interesting. And even when they ask you, for example, what methods you know if you name more than these four, it is already a big plus to your success in the interface.

We have talked a little bit about methods, let's go back to our sheep, our postmen. And right away you can see that we have a get method. When you click here, you can see a huge number of methods that are there by default. Here are our four basic ones, which are get, post, put, and delete. And then there are the other ones that are different. Options, which I've already mentioned, be sure to read about it too. And if you're interested, you can explore the other methods that are here.

But again, I would not advise you to go into this topic very deeply, because the methods can be invented by the developers themselves and they can be custom. So they may be different for each company. Let's go back to our conflict with you. Let me say right away, since we're going to be loading some information about our user, we're going to use uh the post method. I mean, I think it's understandable.

We don't want to find some information on our resource, but to add a new user to our database, to our users bucket. What do we need to do in order to submit a request? Copy our That we need it's in the documentation. Let's select the post method as I mentioned above and also enter our request. And since we have it in JSON format, we need to upload it to In the body, that is our body that we send to the server. Select row and select JSON here.

That is so we can now safely load this JSON and send the information to the server. Since we already have such a user on the site. we can see an error message in the response. But as you can see, the system is not very well. Has been finalized. We should not have the status quo 200 okay here, but another status code that would tell us that we have some kind of error. Let's come up with a new mail of some sort. A new name and password. Let's try to send Or send it, it went through successfully.

Two hundredth status code, our user has been created, and let's log in, refresh the page. Yes, everything is fine. That is, we have our user, file, author already, rest and date of change. And we can also verify this with you provided we have authorization to access our site. Now let's go ahead and copy our password.

Everything is fine, we have successfully logged in, and this user has been created so we can work with him further. You may also notice that there is additional information here that we did not send. In our request, for example, there is the date of birth, gender, b. Meaning we did not send this information either. Here, again, this can be done through some other methods. We can also achieve this not by using our JSON which we had in the example, but by just entering the value key pairs.

To accomplish this task, we need to memorize which parameters are mandatory and what their types are. Specifically, these are three parameters. First, go to Postman and select the Params tab. Then we enter these three parameters and send the request. As you can see, we have successfully sent everything and the parameters appear directly in our request URL. We can verify this again on the resource itself. R email, file and author. Once more, using the same system, we log out and authorize again.

Let's confirm that yes indeed such a user has been created. This in summary is about Postman and how we can work with it. So you should not encounter any difficulties with other methods either. That is we simply select a method and We send our requests in the same manner. Again, combine different test cases. That is, we remove some mandatory parameters. We delete them, leave the fields empty or swap them around.

That is we are all examining how it can be. I believe that will suffice for you in the future. I think this will be adequate for you to parse. All the methods available in confluency for users block red. This will be your initial homework assignment that I am announcing in this, let's say, course. Go through all these methods, both in soap and in rest, that is, in supuyan in postmen. And let's note in the comments whether you succeeded and if you have any questions.

What else I'd like to tell you about are some very useful links and resources that can help you a lot. In mastering and testing the API. Once again back to our favorite test space that I previously mentioned. Once again, I leave the link in the description below. Here is various detailed information of bug trackers that you can practice on and recall the topic on. Filing comprehensive bug reports and defect reports, a test storage system. Again, you can poke around here, take a look.

Test link for example is free. Where to test APIs? There are free sites with test APIs where you can poke around, also regress, Artin is a very popular resource. More full fledged systems again are those that have been developed either directly by Olga and her team, or they're just were also once developed. That is users, the system that I have already shown you today, Shop and Swagger. See what I'll be twiddling our thumbs sometime later, very soon.

There's also a test design, which means there are simulators here that you can look at as well. The triangle, for example, is an interesting simulator on one of the most popular interview questions. But I won't say it's the most popular, I for example, was not asked it. We can also go and click all this and practice. There is also such an interesting resource as swapping.

This is where information about the Star Wars movie universe is stored. And you can also use the API to test and find information about the various characters that were part of this movie saga. So You can you can look at all of this here in a very interesting way. Planets, weapons, creatures. I mean, it's very interesting for those who were once fans or still are Star Wars fans. And again, on the API there's a huge number of different simulators available.

For example, the API of the VContacty social network is publicly available. That is, you can easily find its documentation on this API and also send some requests. There will uh s likely be some authorizations using tokens. I have not dabbled with this, but I know that it is definitely there. And some other resources have APIs too, so you can look at all that. I also recommend if you have the opportunity, for example, or if show some ingenuity and search on various resources such.

Course as API testing from Olga Nasina. I believe you will really like it and find it highly useful because she discusses APIs in a lot of detail there. On this resource users talk about automation with the help of API. It's very detailed and suitable for both beginners and advanced testers. So it comes highly recommended. Again, this is not an advertisement, but simply because the course is genuinely not bad at all.

And let's discuss the final unit within our class. This is about how to write test cases in general. Specifically for testing EPIs, what we should consider there. I will also show you an example of such a test case. Let's begin with the work plan. It is standard, just like it is for any testing, any feature. First, we study the requirements or write them if they do not exist.

Then, based on these requirements, we write our test cases and of course proceed to test them. Requirements are directly our documentation. Is BODL WSDL samples of our requests, sample responses that you can get from the developer? We write cases based on again this documentation that is nothing complicated. Again, we include test design techniques for this.

And we have already talked about testing a little bit earlier in this lesson with the help of sub UI or with the help of Postman. Also in Sub UI you can test. And REST requests as well as in postmenu can test. REST requests. So this is already at a more in-depth level. If you are interested, you can find the information on the internet or you can poxvoit the to the data yourself, so to speak. Requirements, input data. What parameters and attributes does the service have? This is

For example, if we have VSTL, we can look there. And again, as I've said a few times today in class, these are sample queries that we can ask developer, what are the test cases? We categorize them into our three main ones, which are smoke, critical path, and extended. I've talked about all of these, types of testing and test cases in classes before so I won't repeat myself. If you're interested, the link will now appear at the top. You can go and study, refresh that information.

As far as smoke is concerned, that's one requisite for the method. Critical path is all the valid requesters we can think of. For our method and methods, and extended is all invalid. Invalid are any queries. So what are some specific tests for web services and for our queries? As I said, we can send some empty values in the parameters to see how the system behaves. It should give errors if that value is mandatory.

If it is an optional value, then it is acceptable that there are no errors if it is specified in the requirements. We can try to send in JSON for example comments comments if you are interested in programming are such strings which are formed? Or consists in several slashes, or justified by asterisks. And they are not perceived by our system as executable code. That is, they are just some notes on what we have written in our product code.

So we can try to send such comments inside our uh JSON, for example, or in XML, and see how it behaves. System, whether it perceives them as executable code. The validity of the answers agrees with the scheme. if available, which is what we mean. Sub circuits, these are our WSDL and WADL. As I said, just open our WSDL in Sapui when creating a new project and start testing. That is, we enter in these parameters in these hour, tags the information that we will pass to the server.

and see how the server perceives it, what status codes it returns to us, for example, and the answers. Checks with required and optional attributes. Again, as I have already said, a bit above. Let's see what we have required and mandatory must be sent in the request. Again, how the system behaves. Checks with optional and invalid values. Again, we add some parameters that are not specified in the test documentation or in the examples of our requests. Let's see how the system behaves.

Or if we have, for example, specified that we have. In the parameters is a numeric type and we write letters, then the system should also swear and give us the wrong answer. The system, but the server. Different data types instead of a string of numbers while these things are comparable. Duplicate attributes of elements.

Take our element for example, passport, copy it several times, send it, see how the system behaves, the order of attributes in elements. If we have a clear order set, And we violate it, then the system should give an error. The surface should be a good one. Send us a status code indicating that the information we sent to the server hasn't been processed. We deal with long strings of numbers and invalid data. I discussed invalid.

Data in terms of JSON and XML syntax in the last session. There's a lot of information there, so we revisit the last class to study it. Thank you. If you suddenly, for example, even opened this class before you learned about the theory. In terms of testing web services, you study this information too. That's something that relates to our queries.

And what about the responses? Like I said, we look at the status code, we look at the response body and what kind of error text we're getting. Again, if it is specified in our documentation that a certain status code and a certain error text must be received. And they do not match, then this bug, we introduce this bug into the system. And as I promised, here is an example of our test case. It is created according to the same principle as our regular test cases.

This is a summary, our header name. And this is the priority, which is the order of execution of these test cases. Test type here we have regression and automation. Our steps include running a REST request, our request, and a specific URI method that allows us to run this method, the headers that we include. In our request and body, which is already written in JSON format detailing what we are sending.

To the server. The expected result is written in the form of our response then. It is body from the response. Also, such and such group with such and such ID should have been created. Make sure, like I said, we test this on the UI. This means we go to our URL and verify that the group was indeed created. So this is what our test cases look like. Nothing complicated, standard. In our steps we specify for requests the data that we send to

For so the results we write here. We already have our information about the body, what we should generally get from our server. This is how we design our test cases in our systems, which allow us to save them. The same is true for Dealing with box that is During playback steps, we attach it to the process. If something goes wrong, for example, if we receive an incorrect response from the server, we attach this JSON directly. To our bug report, And the developer will work with it.

Here is such a very long lesson we have turned out a bit more than I initially planned because I want to tell you so much about this particular topic. You are interested in learning how to work with Postman, how to work with SOAP UI on a more in-depth level, then please be sure to let me know in the comments below. I think. After I'm done recording the entire basic tester course from scratch. I'm going to start taking apart some things in much more detail, some tools.

So that you can learn them not just at the level of a beginner tester, but perhaps as a continuing tester. And I sincerely hope this information will be useful. The same applies to other tools that are frequently mentioned, In the comments of my videos, such as Git, Jenkins, or Docker, I didn't really encounter these tools very often in my work. At the first place I worked, I mostly used backtracking and I've been testing from a UI perspective so I don't have that much expertise.

on this stuff, but I'm slowly starting to get it now at my new place of work. Because at my new place of work are we using it so I think that when the last lesson on testing from scratch is really Uh I'll start recording videos for you, as you asked, about the practical aspects of Different tools, but I think I'll be able to tell you some basic things before that. So be sure to post anything that interests you. I create a content plan based on your requests and interests.

For example, if you want to learn something about API testing, I have prepared such a session for you. If you want to learn something about Git, I will definitely record a basic lesson for you as well. In this lesson I will tell you about what repositories are, what branches are, how you can clone these repositories, how they are interconnected in general. And overall what Git is used for from the perspective of development and even testing.

So subscribe to this channel, click the bell to not miss new videos. We will see you very soon. Welcome to our tent. Bye.

Hello YouTube, I'd like to start by congratulating you on the fact that we've completed learning about web application testing at the novice tester level and are now ready to move on to the next unit, testing. Databases. Why databases and not mobile application testing? It's quite simple. Because by knowing the theory of testing from the first block, web application testing from the second.

and understanding databases you will already be prepared to interview for the position of a novice tester in the field of web application testing. That is, you will no longer need the knowledge To test the mobile or if your company plans to move to them in the future, you can easily learn them already either in my classes or already inside your company with the help of your mentor.

Before we move on to today's session, I would like to draw your attention to the following. In the last lesson, I made a mistake when I told you about the post method and where we should enter. values in order to send a request to the Server. I told you that you should send them in the params tab. This is wrong, as this tab is used for. Get requests. To send data to the server via post, we must use exactly the request body.

That is we select the body tab, select the form date with the radio button and enter our already keyed value here and send our request. Is how uh request post works correctly. So uh I apologize, uh everyone can make a mistake so Pay attention to this when you will be. You can watch the previous video or go back to it if you forget something and now directly about databases, why it is necessary for a tester to know them.

Data is a very useful tool that is used not only in testing but also in development itself, even in business analysis. That is it is quite a powerful tool as data is our everything. I would like to draw your attention to the following. In front of you, you now see a familiar form for registration on the site. Such a form is very often shown during job interviews, and they ask you.

To explain how you would test it. The most significant mistake begins when you start saying that you would, for example, enter the maximum number of characters in a login field or use the same password. After carrying out all the tests that we discussed in the testing of the web forum, a link will now appear at the top. Yes that's right, but this is not the initial step you should take.

The most common case study user story requirement from your interviewer typically goes something like this. Please test that you can log into the system. How can we accomplish All data about logins, passwords, or any other information that may be contained on this form is stored in a database. That means our form, which is the client, sends a request to. The server with some data. That is, he writes there that please return me the information about whether there is such a user with such a login.

And with such a password in the system that is whether they coincide or not, whether they are in the database. And the server sends this request further to the database. If it matches the database says, Okay, the server receives this information and sends it directly to the client and we enter our site. That is necessarily our first point. is that we have to go into the database and check whether there is information

About this user using a query, which we will talk to you about in the next lessons. So remember, this is your very first step. And then after we have checked that yes indeed we can log in, that we have entered the database, that it contains the information we need, only then do we proceed directly to testing the form itself. Entering invalid values or acceptable values in a given range which are in the requirements. That is, we pay our attention to it.

Also works absolutely everything related to databases, since it is simply impossible to store all information and all data inside the same document overska or CSS, so we resort to some storage. Which contains our data. This is the database. That is the database. It's a set of information stored in an organized form. And let's see generally what there are, databases, their type.

There are three main types of database hierarchical database, network database, and relational database. Hierarchical, as is clear from the name, is as follows that is we have a single root node and from it go branching to others directly at this node. Which belongs to our root node, there are some other nodes, and so they branch further and further. So there is a certain hierarchy consisting of several levels. It's known as the ancestor descendant system. To explain.

An ancestor could be our root node for instance, and descendants would be the nodes that branch off from this root node. Therefore, for uh level three, the ancestors would be those at level two And level three would be the descendants of level two and this pattern continues onward. The next type of database is a network database. In this type, we also have a dataset.

But the key difference is that this dataset depends on other datasets as well. So they have some kind of relationship that is not just a one-to-many relationship, but here we can already have relationships like many to many. Many to one. We will talk about these interrelationships a little further on, so that you understand what a network model is. It looks in the form of a network like this. Hierarchy in the form of a tree, network in the form of a network.

And the one that is used now in all databases is relational model. When we have many two-dimensional tables that contain our data, and these tables can also be related to each other, we need to understand relational databases. And so what do you need to know about relational databases? First of all, what do they consist of

There is a so-called primary key, also known as a primary key, which is the unambiguous identifier of a given row. And it is mandatory for a relational database. Why? Because it's unique. Um and if for example we take the value Column name we will see that there can be identical names. In this case our database might sometimes work incorrectly.

When we query a particular name, it could return many identical values, providing us with numerous results for a single query. Therefore, we use identifiers that uniquely define the rows in our database. These identifiers are crucial. They are known as secondary keys or external keys. These keys are particularly useful, for instance, when we have two tables containing related data. Then how do we link these tables together? We use a secondary key.

This means we enter some identifiers for these two tables and with the help of this identifier we link our two tables. For instance, the identifier 11 will correspond to the data ivan. single Osla and male twenty five. In this way we are linking multiple tables. The secondary key is optional and appears only when we have several tables and need to maintain some patterns. Amen. the interrelationship between the two. I would also like to know that rows in such tables are called records.

And columns are called fields. The next aspect I would like to touch upon is the aspect of normalization. What is normalization? It is the process of making tables look normal. It sounds quite strange, but let's understand what normal look or normal forms are. These are the requirements for tables in relational database theory. That is, we have some rules by which our tables must be created in order for them to be adequately processed.

By our database management system, which we will talk to you about in this lesson a little bit further on. And you need to know at least two of these normal forms. There are more. There is also a third normal form. But I will not dwell on it in detail because usually it is not asked either at job interviews or in ordinary life you do not meet it. So if you're interested you can Google what that is. I'm sure you'll find the explanation on the internet without any problem.

Now, if we talk about the first normal form, it requires that each element of the table has only one value, meaning it should be atomic. As we can see here in this particular row we have Multiple values in a single field are It's incorrect. We need to split this record to make it atomic, allowing us to use each field separately. So here is this record, now correct and meeting the first normal form requirements. Remember atomicity.

The second normal form necessitates that the table is in the first normal form. That means if we don't fulfill the first normal form requirements, we can't claim that this form is also the second normal form and Thank you. If other conditions are met, and all fields must be a very good thing. Depend entirely on the primary key, not just on any part of it. So look carefully. In this table we have two keys here: department and position. And our salary depends on both of those keys. However,

The need to have a computer in the workplace depends solely on the position, meaning the department does not affect it at all. This is incorrect, so we must adjust this form to comply with the second normal form. In this case, we keep the salary in this table and it depends on the department and position and the need for a computer. is transferred to another table and it depends only on the position.

I hope that it became a little clearer to you what it is. I remind you that you should uh read about the third form on your own. Also, since there is a normalization process, there is such a process as denormalization. In queries to a fully normalized database, it is not uncommon to join up to a dozen. Even more tables and each join is a very resource intensive operation.

As a consequence, such queries require a huge amount of server resources and are executed very slowly. Therefore, the process of denormalization comes into play. There are several ways in which this can be accomplished. for example, denormalization by reducing the number of tables. That is, it is better to combine into one table several tables of small size containing rarely changed information. And the information should be closely related to each other in terms of meaning.

In this way, we reduce the number of queries to our database and to the amount of information we need. Two process. And the second common way is denormalization by introducing an additional field into one of the tables. In this case some redundancy of our data appears, so additional actions are necessary to preserve the integrity of our data. To run a denormalization process, you need to know our database very well, how it behaves.

The amount of data that's in it, how long it takes to process. So I think that you, as novice testers, don't need to get into this operation head-on. But you just need to know that not always bringing it normal forms and to requirements can. Very well affect the performance of our uh database. I think if you are brought into the dynamication process, you are led through what you will need to do and how these actions of yours will affect the database.

The next aspect that I would like to touch on today is the relationship in the database. There are three types and uh one of these types can go by different names. We're uh we're going to talk to you uh a little bit more about them now. There is the one-to-one relationship.

This means that each record in one table corresponds to only one record in another table. It's nothing complicated. A one-to-many relationship means that each record in one table corresponds to one or more records in another table.

A many to one relationship is exactly the same as one to many. It's just that this type of relationship depends on your point of view. And the last type is many to many when A. Relationship between two tables occurs when each record in one table corresponds to one or more records. in the other table. A table corresponds to zero, one, two, or more records in another table, and vice versa. That is, at your leisure, read in more detail what it can mean.

and memorize these three basic types of one to one, one to many and many to many, as it will help you better understand the relationships within your tables, within your database. And lastly the Let's talk about the database management system. It is a set of language and software that allows us to create, modify, delete our data, access and secure our data as well as all possible. Uh modifications of this data, that is everything you can think of that we can do with

or data inside this database. Very often people ask what is the difference between a database and a DBMs? And sometimes this question is confusing. So pay your attention that a database is first of all an object. And uh it is always just a set of some data. And a management system is an entity that let's say manages our data.

and to a first approximation, it's just a program, some kind of software. So a database is just our data, a DBMS is a program. When you memorize this and understand it for yourself, you will not have any questions related to How a database differs from uh DBMs. There are several kinds of basic databases, this is not all of them. That is, the most common is MySQL, which we will work with in the next lesson.

I will teach you how to install my SQL server. We will learn how to write queries, selects, which will be useful for you 100%. Joints which you probably won't need. But usually some normal companies ask for them at job interviews. There is also Microsoft Squall, Oracle, PostgresQL, MongoDB, and many other dbms app. All these systems share a common feature. They are built on Sekal, which stands for Structured Query Language. This is a programming language for structured queries.

That's what all these databases use, while there are some differences in various systems the basics remain the same. In the description I will include a link to Kulikov's book which discusses different DBMS and various. Thank you. We will learn about the differences that may occur there.

It is quite difficult to understand for people who have never encountered Dibby databases or DBMs. If you are interested, you can read more about it, but actually don't The data I will provide in the next lessons will be enough to learn how to write queries. However, you need to practice a lot because in interviews they always ask about queries, selects, sometimes even joins. You need to be able to write queries. How to write them?

I think that's all for today. That is some theory that It is necessary to know the minimum that we will need with you in the future. And in general, you may be asked all of these things in an interview. In the next lesson, we with you will install our SQL server and we will work directly.

with our queries. We will learn what types of data there are in the database, we will learn how to write selects. And possibly if we have time, joins as well. If not, we will learn how to write joins on the next. After the next class. Right away I would would like to say that. You often write to me why so much theory? I would like more practice, but guys, when you come for an interview, most often you are asked just theory.

So you will be asked a lot on testing theory, which we covered in the first block, on application testing, you will be asked about the HTTP protocol, about HTTP requests, about the different models that are out there. About databases. Yes, you will be asked, most likely. What is the other thing? DDBMs you have used and asked to write some queries.

That is, you'll probably be given a list of tasks where you will need to use a query to get some selection from a database. So you and I will certainly consider this. So don't forget about the theory. I understand that you want to practice. Perhaps it is somehow more fun, and you have the impression that is nowhere without practice. Yes, I agree.

When you come to work on a project, you are usually taught a lot of things anew because courses, even paid ones, do not always cover all those practical aspects and programs that you will need in your real work. But I try to introduce practical classes as much as possible. And I think that what I am telling you is enough to successfully pass the interview for the position of Jun, a novice tester. Everything else is only in your hands. That is, you go through some theoretical moment.

Be sure to see in practice how it can work. Check out additional videos that are available on the internet. There are a huge number of useful YouTube channels with quality presentation of information, but you just have to look for them. Learn to search, learn to Google. This skill will never hurt you, because in your real work you will very often encounter such stupors and dead ends.

And you don't always need to run immediately to a knowledgeable person or to a developer who already has a lot of work to handle or to your lead or Manager. They have a lot of work to do. Don't forget that. Always make an effort to find the information you need by yourself. Only if you have tried everything and it did not help you, and you find yourself at a dead end, then and only then should you contact an expert in this matter, someone who can assist you.

This is my message. It might seem a bit aggressive at the end, but I just want to remind you to never forget about it. Theory. We will have practice, of course, there will be more of it. I am trying to balance these lessons and not overload them with just theory. Yes, the first blocks were Quite heavy with theory, but you cannot progress without it. Thank you.

And that's it for me. Thank you so much for sticking with me and writing such a huge number of nice comments. I'm actually very pleased and warned by the feedback I received. I realize that all this work has been done for a reason. So I will of course continue to record lessons for you. It is not difficult for me, it is useful for you. Welcome to our tent. Bye.

Hello YouTube. Today we're going to continue our study of databases and directly learn about MySchool, how to set up, the server we'll be working on, and the commands that will help us interact. With the database and the tables that are in it, we won't be looking at selects and joins in this class. I decided that it will be fully devoted to the initial work, changes, deleting, adding tables, to the database and in the next two lessons we will deal with selects.

and joins. So let's not delay and get started. First we need to download CQL server. To do this we go to mySQL.com.scroll to the bottom, find the downloads tab and select MySQL Community Server. This is where we can download our SQL server for free since it is the community version. What do we need to do? Click on the go to download page banner. Thank you. This version works for both. thirty two bit systems and 64 bit systems despite saying 32 bit

And download our installer directly. Click on download. No need to register here. Click no, thank you. Start downloading. The installer is downloaded. I already have it. Run it. Wait a bit. Totally agree if we see these values. We have some updates here, so naturally we update two. This installer, which I downloaded the other day, already has some new updates in the meantime. You can see that there are new updates available. And we choose what we want to download.

For our purposes we will only need the server. However, you can also download the full version. Then you will have the eShell available, which is the UI that we can directly work with. I still think that you and I are going to go hardcore. And start this whole thing first on the command line. So we we download just the server. Click Next Select Default Folder since I already had this server created here. So it writes that there is already such a pathway

Most likely it won't be, so we don't change anything here. Click next, click yes in my case. It shows the status that yes, ready to install and start. We wait for our server, our local machine to install. It will take literally a couple of minutes. Click Next. Then we get the status that our server is ready for configuration. Click next. Here we do not change anything. We leave the defaults. Click next again. Again, we do not change anything here. Choose to use.

uh a strong strong password for encryption Since I have already created a password, it is root, a simple password that is usually used. That's how it's spelled. So you'll probably just uh a box pop up for you to enter that password. You enter it and most likely confirm it. I, on the other hand, click check to verify that my password actually matches the one that was already entered. Earlier, after that, we click next again. Here we also do not change anything.

We leave it at the default and thus starts our process. This is where the process of configuring our server begins. And that's it. That concludes the server installation process. We are now finishing up our installation. Next we need to locate our server directly within our program panel. For our work, we will need to use MySQL version eight point zero common line client Unicode. Simply run it and

The server will prompt you to enter the password you said earlier, my password is root, but yours may be different if you chose another one. And that's it. A welcome window appears. And uh we can directly work with the databases that we have on the server. But first, let's see what types of data are used in databases and in general. What we are going to work with today when we create tables and modify them. First of all, let's talk about data types.

There are certain types of data that we can enter into our spreadsheets and use them. These data in principle are standard. They are even used in programming. So if you memorize them, It will later help you in some other aspects related to your work because you will often encounter with such names of data their types First of all it is integer abbreviated as int, which is what we will use in our databases. These are integers. This is from the English decimal, decimal, fractions, decimal numbers.

So it is also clear what it is. If we have a large amount of textual information, the following data types are used, they are blob, text and memo, if we have Small amounts of textual information, then our strings are used. These are char var char from one to two hundred fifty characters. If we're talking about text, it's about 65,000 characters. The next type is our different date formats. That is, it includes our dates, days, time, and year.

Then we have a format known as flat or double, which represents floating point data. There is also an intriguing data type called Timestamp. This type stores a 4-byte integer that equals the number of seconds that have passed since midnight on January 1, 1970, Greenwich Mean Time. That is The zero time zone, the origin point of all time zones. That is, it is also a data type that allows us to judge. when we have created, for example, this or that element in our database.

And usually timestamp depends on what time zone you are in. That is it can be different for different time zones in different databases. There can also be such a data type as Boolean, that is just our value true or false, and you can separately refer to such data type as not null, that is. It is obligatory for this string, for the given, The fields must be, for example, these values either or empty or if we say about not null, they must be filled with something.

This is what I wanted to tell you about data types. In principle, you can read more about them on the internet. I will try to include in the description a link to some adequate article devoted to this aspect because there are actually many more data types. These are just some of the most common ones. And they are used far, not everywhere. Next you and I will proceed probably to the most interesting part of our today's lesson. That is, we will learn how to write some simple queries.

We will be able to view our databases, create databases, delete them, use them, and then we will create our first tables. And we will also be able to add some values to them, delete them, change them. That is, let's not talk about it for a long time and go directly to Now onto our server and working with it. As we remember, we already have a MySQL server open, CLI for it, and we can directly start doing something with it. Let's start by looking at what databases we have pre-installed here.

To do this we need to enter such a command as show databases. Nothing complicated here. The SQL language is built. In English and English is not complicated. That is, if you know some of the key verbs that are in there, then will be the keywords that are. are used in our query. It's simple here. Show databases that is to say So we will see our databases. So we already have some databases that were probably pre-installed in the system itself.

and a test that I created when I was remembering some aspects to prepare for this lesson. And then once we've already been able to see what databases we have, we can either use some existing database or we can create our own new one. Let's go ahead and create our new one. To accomplish this we Use a command such as create database and we need to provide it with a name. Let's name it students.

One important thing you need to know about syntax is that you must include a semicolon at the end of each of your queries. If you don't, QL will complain. Well not SQL exactly, but the sub D you are using will. You can even test this out. It won't just complain, it won't let you execute the command until you add a semicolon.

So for CQL it doesn't matter what row you have data on, it's still going to read this as one query, as one row. And now we have our database created with students. We can check if it's really Like this. Show databases, we'll use the command again. And yes, as we can see, we have a new database, students. We can delete this database. Let's delete just not this one, but my sum test database that I had created beforehand. That is here we write drop database and the name of our database.

it is deleted. Again, we're checking. In order for you to go back and not to reenter your query, if it is very large, for example, and if you knew for sure that you have it in one line, that is you have not moved them, You can use the up key. And find your command. We used show databases to check what databases we have. We can use it again now. And as we can see, we now no longer have a test database. It's been deleted.

And since we have decided to work with y with the student database we have to use it. That is, we must indicate that yes, we will work in this database. Otherwise, the system will swear in the future and will not understand at all what you want it to do. And which of the databases that are available in this DBMs you want to work with? So we write use and the name of our database is students. You see the database has been modified. That's it, we are now inside this database.

and to check for example if there are any values inside this database meaning some tables We can use this command show tables. This command shows all the tables that are in our database. Empty set, which means it is empty because we have not created. at any of the tables yet. Thank you. This is something that concerns the use of databases, how to enter it, how to create it, how to delete it. And now let's go directly to work with table.

For this we also have a list of our commands that we can use, our queries. Let's first create some table. To do this, we should use the create table command and then enter the name of our table that we want to create within the studio. For example, let's call it courses. And let's go to the next line so that it's more clear to us what we should do next.

Next, we open the brackets and start writing the name of our columns, the name of our fields, and the type that will be applied to that field. For example. For courses, let's come up with a column like faculty. That is our faculty. Let's not even start with But uh let's start with the ED since we have to have a primary key. Next we write the data type. In our case it will be integer, that is integers, numbers.

Then we write The number of numbers that can fit inside our field, that is, inside this value that will be in the string. For example, we can have a maximum of eleven numbers in our string in our record, and we write that it's Well, that is it should always be filled in. This string, this record, and that these are our primary keys. So we also specify right away in the system with UBD that this is the primary key.

And let's come up with the fields. Like I said, this is going to be faculty. Here we're going to use a varchar which is our string. Let it be 55 characters maximum. And let it be for example, at the moment it's zero. So this entry can be empty. What else can we think of for courses? And let's write. Let's not invent some very complicated tables. And we are going to have an integer here as well. Let's have two numbers at most.

Also, let it be zero. Our query has been processed. Now we can see what values we have in this table. For this purpose we use the most famous select statement with which any learning of SQL begins, but We'll talk about them with you a little bit further, just so you know. It's select an asterisk from and then the name of our table. Our table is called Courses, don't forget the semicolon. Yes, I know what. My mistake is. It's that we don't have any values in our table yet. So

Let's start by checking the description of this table, what fields we have there and what fields contain what types of data. To do this, we use such a query as desk and the name of our table. Yes, and now we can see what fields we have in our table, what data types these fields have. and whether they can be useful the table.

uh whether there are null values there or not. The ID field is our primary key and default values are also written here. This way we can see the table description if we need to know in which fields we can use which data. We can also delete tables just like we can delete databases, but Let's not delete our beautiful students table that we create. And there's also the same command as deleting databases there's deleting the tables themselves also.

With our commands which are quite similar. With the keyword drop, so we write drop by table and the name of our table. And the table is deleted. Let's not delete the students table anymore. And at your leisure, you can also practice creating some tables and deleting them. That is, this command is not complicated.

Now our table as you and I have already seen when we performed our select, that is in this case we asked to show all the values. From of the courses table, I mean it is also very simple. We don't have any data here yet, so let's create this data. To do this, we use a command, a query, known as insert into. We need to insert some values into our table.

The next thing we do is we write the name of our table, which is courses. Then we write values, which are our values. And what you need to pay attention to is the order of our Fields inside our table. That is, the first field is ID, the second is faculty, and the third is number. And in the same order we enter values into these fields. So the first ID we have will be one.

And yes, I wanted to point out that in faculty we use our word chart here. That is, we use letters here, it's a string format. And so we need to enclose It in quotes it's a value. Just like we did when we were learning JSON. If you have forgotten what this is, you can go to the API lesson, the practical part, now the link will appear in the description and a little bit of refresh your memory. But

For SECQL and in general for any programming languages, remember that string values, alphabetic values, are always enclosed in a quotation mark. Let's think of a bio. My favorite biology department. If you haven't passed I graduated in the number of our course, let it also be one and put a semicolon. We have our first value created, and we can also add as many values as we want to our database.

Yeah, so that I don't make too many mistakes, I've created some more. Values here. And now we can look at our table, display the values that are contained there. And as we can see the table is filled, we have five values with our unique IDs, primary keys of our five faculties, and five courses. Next, we will look at such an aspect as deleting certain values from our table. Once again, there is nothing complicated here. It uses the keyword delete from

Again, we use the name of our courses table. And if we stop here, then all the values from our table will be deleted. However, we don't want all our values to be deleted. And uh generally I would like to draw your attention to the fact that you should always carefully look at these keywords, especially delete and drop, because you can drop your some very important database that way. Usually of course rights.

For testers are restricted to some really serious databases. For example, if you're working on Pro D But a lot of people have limited rights on ProD in general, so there, most likely, unless some fools are working. With databases, then those rights are not restricted. But still, pay attention to it. Do not forget, for example, if we use the command

from our table some information if we want to delete. Then we must somehow specify this case with the help of the word where. That is where. And here we write the name of our field and the value. So for example, we want to remove information about the humanities faculty. So we write that where faculty is equal to And the G U value. Now let's go ahead and run our command to see what remains in the table. As we can observe, our GU value has been successfully deleted.

In this straightforward manner we can remove our records from the table. The next topic I would like to explore is modifying an existing. Excused upon value in our table. This can be achieved by using a command such as update. We aim to update certain values in our table, specifically the name of our table. For instance, we aim to replace the value of geo in polyfaculty. We

Want to set a value for example. Once more, let's use our favorite GU v faculty equals G O. Now we have to replace that value. Let's remove select all from courses. As we can see, the Geo value has been replaced by the GUM value. We use the keyword update. So it's not that complicated either. Finally, the last thing I wanted to cover today is when we want to add a column to our table, for example, or delete it. Thank you. Amen. Thank you.

Let's start by deleting our column. Specifically we want to remove our ID column. To achieve this, we use a keyword like Iter table, followed by the name of our table, then the keyword drop. We have already learned this word before. Next we use column, which signifies a column. And finally we specify the field we want to delete, which in this case is the ID. As We are about to observe it will be deleted and Yes, so now we don't have the ID column anymore.

And now you and I want to add back our primary key. To accomplish this we use once more AlterTable, followed by the name of our table, which is Courses, then add column, ID, integer, and the name of the field behind which we want to place our new column. Alternatively. We can use the words first or second if we are certain that this column should be positioned

First, however, let's choose to place it behind the number. Our command has been successfully executed. Now let's proceed to verify the command. Our identifier has indeed been added. Your homework is as follows. install Segal Server as I demonstrated. and create some test tables. Make sure to remove values from them, add values, modify, delete tables and delete databases.

Basically experiment with all of this, practice and remember how we do it. Since various queries are often asked in job interviews, you need to be able to write them. Thank you. The queries that we've looked at today may not be asked that often in job interviews, but here are the next ones select and join. Especially the first selects, at almost every interview you will be asked to write these queries. That is, you'll be given some kind of spreadsheet with data in it.

And based on the job for example, please show us the value from such and such a field in such and such a table. Where these values are greater than five, for example. This will be the task and you will have to analyze this all quickly and write a select.

Which would allow you to output values, because today we output values absolutely all from tables. But there you will somehow specify this case and we will talk to you about it of course in the next lesson. That is the next lesson. Let's get ready again.

Download SQL server for yourself, learn it. Today I wanted to show you a way to practice and even before the next class, learn how to write some selections using different Conditions go to lettery schools dot com select SQL and you'll find a huge number of different queries. What's good about this site? You get general information about the types of queries, and you can directly Thank you.

To attempt writing these queries, that is there are numerous test databases here that you can effortlessly work in. And learn SQL on your own. Additionally, as you can observe at the top, there are identical simulators for mail email, CSS, JavaScript, Python, PHP, and all these things. So you can certainly read All of that, click around if you wish to learn something additional. You always ask me about where to practice, and this resource is fantastic for you.

I will not use it specifically in this lesson and in the next ones, because you and I would rather learn how to create some tables ourselves, enter data into them and not use ready-made solutions. Basically that's all I have for now. Thank you very much for your attention. I will be glad to have your likes and subscriptions if you are on this channel for the first time and you are interested in the topic of testing.

I would like to remind you that I have course tester from scratch, which is posted on this channel. It's constantly being updated. We've got a few more skillet classes ahead of us. Then we will touch on such a topic as testing mobile applications and finish everything on a good note. On agile, on scrum that is We will learn and find out what it is, and already with all this knowledge, I think you will be ready to be interviewed. You can also safely respond to various vacancies

and try to go for an interview. Even if you will be rejected I would still advise you to go through different interviews, learn, uh memorize some slippery questions as they are often caught in other interviews and pump yourself up. Because when you already go to five or even a dozen interviews, you will already have an idea of how they are held. You will not be particularly nervous

And I think you will successfully pass it and get your first offer. That's what we are all here for. That's what we are learning. And all the information I give you is for this final amazing result. Welcome to our tent. Bye.

Hello YouTube. Today we are continuing our deep dive into database testing and MySQL. We will talk about the selections that are most often asked in interviews and break down the basic queries that you will need to learn and practice writing in order for you to be successful in your interview. If this is your first time joining this lesson, I would like to remind you that I have a course called Tester from Scratch, in which we already had two lessons focused on database testing.

Now the link to these lessons will appear at the top. Well, let's get started. And let's take apart first the most standard, our very first phrase, so to speak, our query. This is the output of all values from our table. But first of all, let's remember our previous queries that we've looked at in the last lesson. This is to show all of our databases that we have. And we need to select the uh database that we are going to work in. We are going to use the same database which is student.

I hope you manage to download and install SUL server so we can all work on the same page. You can follow along in parallel to practice the technique immediately. We've logged into our database and here we have a table named Courses which is what we'll be working with. So let's first retrieve all the values from this table, from the courses table. Here we have. That is, all the data that we have in the table can be outputted with the help of such a query, also known as an operator.

Here we have our keywords select the value and and and our table from which these base uh uh values are outputted. Furthermore, for instance, if we do not want to see Duplicate fields, like when we have two duplicate fields in number, we do not want to see all the freshmen, but rather only one record that contains this value.

To do this, we have to enter the following query. Select distinct, memorize this word. We will need it to separate all the duplicates. In the field, we will take our number and the name of the table. As a result, as we can see, we cut off duplicate values and we see only what does not contain duplicates. Next, let's analyze. Such a command as limit. That is, for example, we want to display only the first two rows of

From our table. Most often your database does not consist of just these five rows or five records. Instead, there are usually hundreds and sometimes even thousands of Therefore we don't need to work with that many values all the time. Let's focus on outputting only the first two records. To achieve this we use the following command select all values from courses. The limit is the keyword that will determine how many rows we want to see.

Followed by the number of rows. As a result, we will only have the first two rows outputted, so we can, for instance, eliminate unnecessary values and focus only on what we are interested in. Additionally there is a feature known as aliases or aliases. These are temporary names for our fields. For example, we might not want the number field to be displayed as number, but for instance as the name number.

To achieve this, we write select number as number from the name of our table. And remember to always put a semicolon at the end. In the end, as we can see, we have a name change, but this is just temporary. If we now apply our select O values from courses, we will notice that the name of our field has not changed. That is to say, we can assign some values. For instance, if we create some complex queries, then we can rename them to make it a bit clearer what exactly we are doing.

The next thing I wanted to go over with you is a comparison or the exact match of some value. So we have our select statement and we want to pull some field from a table, the name of our table, and we have to assign some condition that we're going to look for these values. For example Let's find and select the faculty number. Here we will get two fields or two columns from the courses where faculty and make sure we use bio quotes. This is important because it ensures accuracy in our query.

And as we can see here, we enter those columns and those specific fields that we are interested in, such as faculty and the number provided. We have faculty equal to bio. Also, in this case, we can use the greater than sign, the equal sign greater than or equal to, or less than or equal to. So, for example, we can select the number from courses. As you realize we can only use greater than or less than for numeric values. That's why we use the number here, where the number is greater than one.

And as we can see, we have only found values for course numbers that are greater than one. I also wanted to point out that when we use greater than or equal to or less than or equal to, we write the greater than equal sign first, and the same for less than equal. It is in that sequence so that it works for us. That's the thing about comparisons. And we can also use different logical operations like AND or OR.

That is, if we are talking about end, then we must have two conditions that we set. If we speak about or or in translation from English it is or then we have either one condition or the other being met and these values are then output. Let's check this out together. Select. Let's output everything from courses where number equals one and faculty equals bio. As we can see, only the values where the faculty number is one and In faculty the value is bio or output.

As you can see we also have the theological faculty included in the table, where we also have course number one, but this value is not displayed because it doesn't meet the criteria. For instance, if you and I were to use the value O here and for example the faculty gum, then we would have all the values displayed where we have. Course number one

And where we have the faculty name GAM unitarian, that is either this condition or the other must be fulfilled. That's the reason why we have values output in this manner. This is as far as the logical operations are concerned. The next aspect I'd like to examine is finding similar values. For instance, the We want to locate words that have the letters all at the end. In that case we need to use this type of query. And the keyword we use is like.

That means let's retrieve all the values from courses where faculty. And as I mentioned before, we want to have the letter O at the end. Here we can do two ways. If we're not interested in the number of characters that will come before this letter O, We use the percent sign, put O and run our query. And for some reason we didn't find anything. Why didn't we get anything? Because I didn't use the like keyword So we repeat our query.

As you can see I have already run it several times here to refresh my memory in general what is going on and it was only the fourth query that I realized that I did not use the word like. It happens. When faculty is not equal we should enter like. Yes, now we will discuss underscores. By the way, this is the last this is the final query. As we observed, two values appeared, bio and teo from the faculty field with the final letter O. So everything worked correctly for us. Now when we talk about

The underscore. The underscore always represents one character that is not present. So we can use it, for instance, if we want, it to show us only those values that end in IO. Then we enter the underscore, followed by EO. And as expected, we are shown the bio. So just one character is replaced with this underscore. We can also combine these with each other. So for example, we might be interested in a query like this.

The first letter we have one, we do not care what it is, then there should be the letter and and then a percent sign. That is, it does not matter how many characters come after. We run it and it shows us Tao. that is also nothing complicated as you and I can see. It is very convenient to use. So remember we search for similar values using the keyword like.

Then we can also search for some ranges, for example, in order not to write very many times conditions that for example where number is one, a number is two, and number equals three and number equals four. And so on add infinitum you can make it easier. For instance, if we are interested in a range. From two to four, then we can write the following query. Please show me all values from courses where number the keyword is between

and we write the values we are interested in from two to four and to and from. Let's run it. And as we can see we are shown only those fields in which the condition match That we would have in the range from two to four. We are not shown here. We can also look here. From the contrary, that is, we need on the contrary to show those values that are not within the range from two to four.

To do this, we use the word not after W, so we're not a number between two and four. We run it and we are shown only our ones. Also, as you and I can see, it's nothing complicated. It also works with other words. Just remember to place the word not after where. And again, as we can simplify our life if we are interested not in a range, but in hitting some specific numbers, we can use the keyword in that is in this case.

We use the word in that is show me all the values from courses where number in. Um and these values we have to spell out through commas in parentheses. For example, we are interested in the values one and four. That is, we will now be shown those values in which we have an equal number of one and four. As you and I can clearly see, everything worked correctly, and we didn't need to write a huge canvas. What with numerous conditions.

You and I can also combine various logical functions like this. That is, we are interested in some pair of values. Which is not important, meaning it can be either this or that and some value is mandatory. That is we can use this type of query. In other words, show me all values from courses where we open our bracket, write the value for instance faculty is equal to Tao or faculty equals bio and number equals one.

Here we are shown all the values that will meet all these conditions. So we remember that we can also combine these logical functions among themselves. There are literally a few aspects left that I wanted to cover today. Firstly our sorting. For instance, we want to sort all the values in our table. We want to sort them in alphabetical order. For this we use the keyword order base.

And if we want to use alphabetical order, then we do not need to write any additional conditions or additional words, but just the field by which we want to perform this sorting. Let's sort by faculty. This is the so-called ascending order, that is, in alphabetical order. And as we can see, we have sorted alphabetically. If we want to do this same sorting in reverse order, we have to use the word desk abbreviated to Descending and we have reverse sorted.

we can specify the fields we are interested in by which it should be performed. Additionally, the last aspect we need to consider is aggregate functions. This includes the sum which gives us the minimum and maximum values, count which tells us the number of records filled, and average, which calculates the average. For instance, if we want to select the average value for the number field, we use our favorite select statement. We then write the name of this aggregate function which is average.

The field by which we desire to find this average value in our case is number and the name of our table. We have successfully calculated the average value for poly number. If we wish to calculate the sum, it operates in a similar manner. Select some polynumber from courses, and we have computed the sum in this particular field.

What else can be done here? You can, for instance, find the minimum value in the field, like a number. That is, once again, select min in the number field. We can assign it some value that we would like to see, some alias. We use the S keyword for this purpose, let's call it Min, number from courses and Here. It is uh replaced by an alias. The minimum value we have is one and we are shown it. The same thing applies to the maximum. But I won't show you it works in a similar manner.

And additionally, you and I can also output the number of records that we have filled with some values. So how this works is we output, for example, select count by faculty let's go uh from courses. We have here five values and they are all filled, meaning we do not have any zero or empty spaces. So five records they are filled. And uh this table shows us that there are five. Essentially, these are all the basic selections, the basic queries that you need to know.

Your homework assignment will be as follows. First go through the floor I showed you today. If you have any other tables created, go through those tables and practice each of those created. Also go to the W three schools website under the CQL tab and practice all of these selections there as well. Additionally, you can so to speak asterisk. To go through the other selections that are available there.

Well, I think these are all enough for you to write your interview requests when you get your assignments. I will see you at the next session. It will be devoted to joins, so get ready, practice, get your hands full. And I, in my turn, will say my catchphrase. Welcome to our tent. Bye. Bye.

Hello YouTube. Today we have the final session of the database testing block and I'm going to explain to you about joins and queries like this. Additionally, we'll delve into how subqueries are nested just a little bit so you understand how. We can locate the data we need using extra conditions. But before we dive into this topic, I also want to tell you about the UI component of our square.

and how you can, aside from the command line, utilize the tools that MySQL offers us absolutely free of charge. For this we need to download Workbench. Now I will show you exactly how to do it. Most likely you have our MyCQL installer left in your system. And if you run it, you need to wait a little time.

I've already done this ahead of time so as not to waste your precious minutes. You'll get a screen like this that tells you which MySQL products you already have installed. Since I already have Workbench installed, it is displayed here. You will just have one line with the MySQL server. So what do we need to do next to configure the workbench?

Well, you need to click on the Add button. Here you will see all the available products that we can install and use. You can read about each product separately to understand what it is. There are quite a lot of them here. Also here, you will find various samples and examples for your work. These include ready made databases and tables with test data that you can also use. You can download them from here as well. But we're going to be interested in names.

Applications, we open it, we choose MySQL Workbench, and we choose, here is the only option, it is to install MySQL Workbench and the latest version because I already have it installed, so I have everything here but you choose. You click next, this application is installed and you can work with it. That is there are no problems.

After that, we can close the installer and run our MySQL workbench. When it starts, you will have your local instance here which you have already prepared and probably worked with before. You click on it, end it. Prompts you for a password. I believe you have a standard root password, which you can save so that the system does not ask you for it in the future. Then it opens an application where you can enter the queries that we have studied and will continue to study today.

How do you do this? To enter the query for instance, show databases, you need to do more than just press enter. Simply pressing enter will not work. You must click on the lightning bolt icon to execute. This query. And then we are shown all the databases, just like we had in Commonline, which we have speaking in a enjoyable manner. Furthermore, we can write the database that we are going to use and for instance see what values we have in the courses table that we have.

What is convenient about this tool is that First of all, it shows you errors if you enter something incorrectly right on the UI. It also prompts you for some keywords that you can use and tables to substitute, which is quite convenient. Another good thing is that you can run these commands all at once, that is in this way, or individually by highlighting a given command and clicking on the lightning bolt icon. Basically, that's all you should be interested in at the moment in this software.

Memorizing workbench is very handy and Probably more accessible than in common line. Here you can see it all at once and everything is quite clear. So let's continue our work here today so that you get used to this application a little bit. But before that, let's see what joins are in general. What kind of queries are they? Joins are queries that allow us to join two or more tables by some field that is the same in these tables.

That is, if we need to join multiple similar tables in the same database, we can use joins. There are three types of joins inner join Right join and left join. For our convenience I found these schematics. To explain to you how it works, the simplest join is an inner join that is an internal join. That is, if we have two tables and there is a field that is identical for A and B and the values in it are the same, then we can perform such an inner join. That is one table joined.

to the other table. Let me use an example to show you what this looks like. That is the query itself looks like this. This is our normal select. We have to enter the fields that we want to combine. Next I'll explain why table A is written here, table B is written here. From table A join table A with table B and by the field by which we are doing this join. Let's look at an example.

First, let's take a moment to see what tables we even have in our database under students. To do this, we're going to use the show tables query and run it. As of now, we have two tables, courses and general. That is, as you and I remember, courses is the table we created in the previous two lessons, and general is the table I. Created additionally so that we could merge values from these two tables. Now let's take a closer look at the values present in the general table.

We have four fields here, our ID, first name, last name, age, and gender. And now we can focus on this ID field. Since we also have the ID field, in the courses table we can merge our values. What is really good about using this application is that we can, for example, run two queries simultaneously. And we will end up with two tables. One will contain the general table and the other will have the courses table. So let's get right down to business and merge these values together.

See first we write our word select and then we write down the values we want to output. However, it is absolutely necessary that before each value, before its field We need to write the table that contains it. That is, we write that in the table courses for example. We will be interested in. Let's see what we have in courses, faculty, and let's have. Let's just have faculty. We've only got two fields here.

And in the general table we're going to be interested in, for example, first name and last name. So we write general first name and general last name. Next, we write our table, which is a from courses, and then join specifying which table we will join general to. Additionally, we have to write the value we are going to match. For us, it's ID. Therefore we write courses it equals generalit first. Finally we close our point with a comma. Let's run it and see if it works.

Yes we did it. As we can see we have just merged the values where IDs coincide and the common table is displayed. That is now we can find out which faculty a person studies it. Let's run three queries simultaneously and see how it works in detail. Look, we have we have the general table where the ID number is six. And in the courses table there is itchnik seven since we don't have the same values of For six and seven in these two tables our resulting table in which we did the merch.

We'll not have these two roles. That's why left and right join come to our aid. Let's see how they work. That is, there's nothing complicated here either. In a left join, we merge as if by our left table, while in a right join we merge by our right table. That is, we will have all rows from table A displayed, even if they are missing table B. And similarly for the right hand side merge, we will be shown all rows. from table B even if they are absent in table A.

So what we're discussing now is our icons. The left join and right join primarily depend on how you configure these tables and write your query. The resulting table joins will also be influenced by this, so let's take the time to run these two queries together and observe. With a real example, how they differ from one another. First, let's begin with the left join. We will select the fields we are interested in courses, number, general, first name, and general agenda.

From our first table, which we will call Tab A. We have courses apologies, I meant to say courses. Then we join this with our second table, general. Based on the already known fields that can provide us with a match. Yes, we need to ensure we add left here to specify the type of join we are using. And now let's take a look at uh result.

Observe how our query has worked. We have a table called courses, meaning all the rows from this table will be displayed even if they do not appear in table B. We can verify this together now. So we have An ID number ending with a 7, which corresponds to physical 4. If you and I check, we can see this 4 right here. However, since we do not have the same ID ending with a seven, in general, these values are recorded as nullable, which means they are null.

But uh as we know, left to right join shows all rows from A even if they are not in B. So we just replace B with null values. If we compare to our table that we did just an inner join, here we have five values, and there was only a match on our IDs that are in the two tables. Where are those values? We have six and Now let's perform the join operation for the right join. For this we are going to use our select again.

This time let's also output the ID pin general. Let it be the first name, general, the last name, general, the gender. And let's add some more courses faculty write from courses.write dot join dot general on courses eat generalist. And then uh we will run our query. This is causing an error because I didn't write it correctly. Let's execute our query. And what do we observe? We now have data. On the sixth ID.

on the sixth ID, which was missing in the courses table. However, since we performed a right join We are presented with all the values from table B, the general table. If we examine the order, we can see it right here. Even though this specific ID number is not present in table A. This is how our joints work. In principle there is nothing complicated. Perhaps there are some difficulties with readability.

And syntax of writing these queries, but again, this is a matter of practice. So you need to practice these joins at home. On our favorite site, W3Schools, that is where we Practice it all. There are already ready made databases there. You don't even have to use my CKL workbench and other gadgets, let's put it that way. So let's go over there and practice, practice, practice. Because in job interviews they might ask for joints. More often than not they just ask for selection.

But I would like to draw your attention that there can be. Tasks we uh an asterisk and joins. And if you do them, it's a big plus for you. And the last aspect that I would like to go over with you is nested subqueries. What are these in general? What are they for? For example, if we are unable to use our single select and the conditions we specify need to output the values that we are interested in.

We can use another select within our query. To understand how this all works, let's look at an example. Let's consider our second table general where we have many more fields and records and come up with a complex query, let's call it that. To accomplish that. We would like to output the first name, the last name, and the gender. For instance, let's also include the ID taken from general where H and let's devise another query that our H field should also utilize select in order to output it.

Let's choose age from general where. Let's specify ID greater than one and first name not first name and age greater than or equal to twenty one. Amen. This is the query that we have. And let's run it together with a query that shows us all the values from general. That's what we get. Now let's see if we really got what we were interested in. First we wanted to get the first name, last name, gender, and ID fields from our spreadsheet.

where age matches the following aspects. ID is greater than 1 and age is greater than 21. We need to ensure that our query captures these specific details accurately. By doing so, we can confirm that our data extraction is precise and meets our requirements. Let's say ages greater than twenty one, that is greater than or equal to twenty one. So what we have here is Alan, Peter and Jack. They have IDs greater than one. So those are the three values that we should have here.

Yeah, that's really it. So if we can't use one query and the conditions that we write in it to output the values that we're interested in, we use nested queries. Yes, most likely this query that we have written is not so indicative, but in principle in interview. When you need to do something and you are unsure how to achieve it with a single selector, you can actually use another selector within it. This is a useful technique that can make your work much easier.

So, here is a little tip on how to accomplish this task. You and I have collaborated very fruitfully over these four classes. We have learned a variety of important skills, such as how to install a SQL Server and how to install Workbench. Workbench is a very powerful tool that allows us To digest in present in a more readable and understandable way the information that we can extract from our databases and the tables that they contain.

Also, you should learn the most popular selections that you 100% will need during a job interview if they want to check you out and suddenly they really like you, your robot employer. They will want to know that you have more knowledge, so make sure to learn join and how they are written. Additionally, learn how to create tables and how to modify the data within them. This is also quite useful if you need to complete test tasks or come up with test data directly at your work in the workplace.

I hope you enjoyed this block of classes. In the next lesson we will start testing mobile applications. This will be the penultimate block before we finish this course altogether. All that will be left is agile. And that's basically it. I think that by the end of the fall you and I will have finished the course tester from scratch. And then there will be more courses, more classes, more realization of your wishes.

So please be sure to write in the comments what else you would like to see on the channel. I'm outlining everything, memorizing everything. I have a separate Trello table where my let's say content plan. So everything you mentioned will definitely be implemented to some extent. I remind you that I have a telegram, which also contains a lot of useful. Things such as free courses, links to them, or My Thoughts Out Loud, which will help you to adapt a little bit in the IT sphere.

Uh and helpful articles that you can read as well. And Instagram where you can also ask your questions. There I also try to periodically post posts related. For example, to test artifacts that we, for example, here do not consider in our course, and I try to communicate with you there as well. So if you are interested, please join other social activities that are related to this channel and its author. Welcome to our tent. Bye.

Hello YouTube! Today we are continuing our tester from scratch course. And we're starting an intriguing new unit on mobile app testing that many of you have been requesting for a very long time. There will be a few lessons where we will delve into and understand in general what mobile applications are, how to work with them. How to select the appropriate tools to work with them, how to operate within those tools, and how to install them on your computer.

How to test a mobile app and what specific checks we should use. I'll also share some uh cheat sheets and checklists to help you conduct your checks quickly in the future. All of this in just a few lessons. So plug in and explore, it's going to be very interesting. Let's start with some theoretical background. I'll give you some context. And what's the very first thing we should do before we start testing mobile apps?

Of course, we need to choose the platform we want to develop on, the devices we want to use, and the form factors. That means we need to gather the right statistics. Usually of course this task is not done by the testers, but you might also be involved in these matters because you are the one who will need to conduct this very testing.

So the first thing we'll discuss is collecting statistics on mobile devices. Where can this be done? First, we have two official resources with all the information for developers of mobile apps. Whether for Android or iOS, the two most popular platforms, I'll provide links to those sites so you can explore and find all the information you need.

What will interest us here? First, on developerandroid.com we are interested in information about platforms. Unfortunately this information is not displayed here right now, as you can see.

Uh it says here that uh we can find information about the required versions and platforms in Android Studio. Next I'll tell you about Android Studio and when we install this tool we'll be sure to check if we can do that. Because before This information used to look like a pie chart and you could see these ratios. which versions of Android are the most common at the moment

And this information would be very useful to us in case when we were choosing this or that device for our testing. But here we have information about the size of screens and their resolution, that is We can study this here as well. That is all this statistical information can be obtained on the official website. Um there is also a similar site for iOS device that is

Is developer.apple.com. There is also information here that is we can immediately check which iOS versions are the most common at the moment. And also form that necessary pool of devices that we will test. Because not all versions of iOS are supported on all phones, so we need to choose the one that is optimal for us to affect as many versions as possible and further test. That is, all this can also be found and read here. Another good resource is MixPanel where we collect statistics.

by on how widespread Android and iOS devices are. That is you can see here that for example there are more Android devices at the moment. In principle this is logical since iOS devices are produced only by Apple. And Android devices are produced by almost all other major companies, therefore. There's more of them. And here we can sort by the period we are interested in. So we can find out, for example, how in the 2020 year this statistic changed.

I'm not going to do that now. That is I've brought you the statistics for September through October. 24 October and it's formed. Statistics take quite a long time to form if we take a long period of time, so let's not waste time on that. Additionally, this can be downloaded and further utilized to select the devices we need to test on. And if we still want to enter a more competitive market where there are more users, we probably need to develop apps for the Android platform first.

There are also other statistics available here. For instance, on the distribution of iPhone twelve, iOS 14, and different versions of various phones. You can see everything here. As you can see, there is a lot of information here on iOS system, but in principle for your work for your interest, you are likely to be interested specifically in statistics. On comparing the distribution of Android and iOS devices.

Also not a bad resource is statcounter.com. That is here too you can for example find information about How widespread are the models of certain phone companies? That is again to choose our devices for testing. We can use it and for example realize that. We need to purchase some Sung and Apple phones for our work, possibly Huawei and Xiaomi as the most common manufacturers. That is also here you can see over time how

This is a statistic. Also here we can select directly in the country we want to reach. For example, if we are interested in Belarus we look at it. If we are interested in the United States, we look for this country. for the whole world again we choose for the whole world and see how it can affect us. There's also other information here that is we can see for example by changing.

Screen resolution, that is we can also find out what screens are common now and what we should use for testing and for the development itself. You can also see information, for example about form facts. That is how they are also common. Mobile. Tablet or desktop applications. All of that can be explored here. A very good resource that you can use to get a statistics.

Plus there is also such a resource app ring. Basically it works in a similar way. Again, we choose the country we are interested in. Let's take Greenland for example. And here it is written down how many phones were sold and used in this country. Again so that we know which devices we should take for testing. Also a good resource that can help you, for example, in order for you to determine with the necessary mobile devices if you have, for example, limited budget in your company.

This resource is good because it has information about, for example, if you do not have a lot of money, you are just starting some, for example, startup. And you need to cover as many cases, versions, platforms as possible, then here are prescribe the devices that you need to purchase. The same applies to a growing business of some kind or already enterprise. So you can look at all of this here and see how much you can cover. those cases that are generally all over the world.

most likely you will not have to do this. That is, it will most likely be done. Either by marketers or by the customer himself or by the customer when he contacts your company or by your test lead. Who deals directly with all kinds of financial and regulatory issues and they need to. Filling out this fleet of devices that you're interested in. But for the future, I think it's good enough to know where that information can be found.

Going back to our mind map. We've talked now about statistics and the resources that allow you to do that and find the information that you need. Let's now talk in general about mobile apps, what they are. There are three types of mobile applications. These are native, hybrid, and web applications.

Let's start with you. With web applications. I think that with web application testing unit you are familiar with this definition, so I will not repeat it. But if you are not familiar with it and this is your first time here. There is a link at the top of the lesson where I talked in detail about the difference between websites, web applications, web services, where you can learn what they are.

To a first approximation web applications are more hyped. In terms of functionality, a website and basically it's basically a website that's customized for our our uh mobile apps or mobile app screens. The simplest example to me is if you and I remember our good social network V Contacti, that is, if we just go to it, we open a regular website, uh a web application for I work on the desktop but uh this website also has a mobile version.

And it is the one that is already adapted for mobile devices. So this has a mobile web application. Let's talk to you now about what exactly are the pros and cons of mobile web applications. Let's start with the pros. The web application is one version for all platforms, that is

We do not need to develop a separate application for iOS, for Android, I do not know. They are for Windows Phone if it still lives for BlackBerry, that is. We do not need to develop it all. There is one version for all platforms. It's basically a website that is adapted to work. With a mobile device also From pluses it is possible to deduce that updating of this resource is carried out on a server, that is, we do not need to involve users to this work, everything happens in automatic mode.

And web applications are quite easy to develop because they use web technologies, HTML for example. So there is nothing complicated about it. Of the disadvantages can be attributed to the fact that for a web application, in principle, it is clear from the definition always need internet connections to work.

There is no possibility to use the functions of a mobile device. That is, what does this mean? For example, we have in the cell phone camera we have push notifications, we have for example access to GPS. All of these things. web applications can't use and that application cannot be downloaded.

From the App Store or Google Play Market Google Market. I mean they're not there because it's basically a website. I mean you can't distribute it that way. And these applications are not very well protected because they are Written in HTML5, for example, and we can easily download code of this application of our web. And is at best to use it. In the worst case in this code can be encoded some information.

Sensitive that is sensitive data of our users, for example. And again it can be used. This is something that concerns web applications. There are also native apps. Native applications are those applications that we directly download from our store, from Play Market or App Store, and they are developed directly on. Those tools, those tools in those languages that are needed and used for the platform, they are specific.

Let's fix the typo here because I know a lot of people notice them and write to me in the comments. This is very good. You see, I have already noticed these points myself. Coming back to native applications, applications for iOS, for example, are developed in Swift. Android applications are developed in Java or Kotlin, that is these are specific languages peculiar to these platforms. This should also be borne in mind that the first time.

On the plus side, these native applications work without an internet connection. And they have access to the mobile device capability. So you can send push notifications, you can for example use camera resources, you can use GPS, that is everything that we have in the application we have access to. Well, if of course the users allow us to do this. And these these applications are distributed through stores.

So this is also a big plus because you can download it in a store, you can buy it for money, so the company makes a profit on this. Um you can embed, for example, advertising on it. And companies get some money for that too. In principle, it is at the expense of advertising that various conditionally free applications live. One of the disadvantages is that a separate version of the application is developed for each platform. As I said

These applications are specific and are written in certain programming languages. Plus, we are going to talk a little bit more about guidelines, what they are. That is, each platform, each store has its own guidelines. We have our own. Requirements for the development of this or that application for its design. And for example, if Android has some requirements that are specific to that particular platform, then iOS has requirements that are specific to that platform.

So we can't release the same apps written in the same language for those two platforms. The thing about native apps, that's why we developed separately for each platform. In principle this has the following disadvantage. We need more money and time for development.

In principle, it is understandable because there are two separate versions, two platforms. And we with several teams are engaged in this particular development. On top of that, more money, for example, can go to buying various test devices. For example, if we do decide that we are releasing for each separate platform, We have to buy a device on iOS Android device. But since there are so many for Android devices, you have to buy them in different variations.

And necessarily the updating and downloading of these apps is done with the involvement of the user. That is, we cannot automatically perform these updates whenever we want. So the user has to download. This also causes some risks because for example if you have a critical bug in your application and a user has not downloaded it for a long time. Update

That is, a user can perceive this as a poor quality product, poor quality of your work, put a negative review. The review has a very negative impact that other users see it and won't want to download the app. That is we cannot update it all in a centralized way. So that's a big disadvantage. On the plus side, these applications are quite high speed, and due to the fact that we can involve the various functions of the mobile device, that is, they are.

More more interesting than other kinds of apps, whether it's hybrid or web. That's the thing about native apps. And the last type left is hybrid apps. As the name implies, hybrid applications include both. web elements and native application elements. Again, this kind of application has its pros and cons. First, the pros include the fact that they are cross platform. Why? Because most of the time they are written using different web technology languages.

So there's no such binding to the fact that we have to write only in Java or in Kotlin or in Swift. So again, it's good for making sure that we don't have to develop separate versions for different marketplaces. Hybrid apps have access to phone features, meaning we can plug them in, they have Access to APIs internal to that phone just like native app.

And they're cheaper to develop than native again, because we don't have to develop one hundred minus five hundred versions, let's say, for different. versions of platforms and the platforms themselves and we don't need such a large number of large devices that we need for.

So the minuses can be attributed low speed of work, because we have here used web technologies, we cannot optimize some things. Plus, they are impractical because of the long updates of the framework. That is, if we, for example, use the our apps and wrote it on some kind of framework then basically it could take there about three to six months to update it.

And again, that's a very long time. And they're not secure because most often, again, as I said, it's using web technologies. It may be using HTML five. And as web applications, we have some security holes in those applications. On top of that again, going back to our mobile app design guidelines.

There may be issues related to with the fact that for this or that market Even though we are using the same version, we have to make changes in the design in order to comply with the guideline and not to be rejected for uploading this application to our market. That's the thing about the types of all these apps. If we're talking about native apps. For example, we can include the same Instagram that we download. Through the market hybrid may be some kind of

News aggregators, so you have some kind of PC files that you're you download, install. There is information about various news resources. And it is when you click, for example, on this news resource, you are transferred to the web version of this application. Perhaps so it can be realized. Various applications related, for example, to photography also use this hybrid type.

That is, you can find a lot of examples on the internet and prepare yourself for the fact that if you are asked for a job interview For example, give an example of all of these types of mobile apps so that you know at least a few examples. The next point is the guidelines that I've already talked about today. These are the requirements for our design. Let's go back to our development sites for Android and for iOS. If we're talking about Android, we have we have Guides directly where we have

Information on the user interface and navigation. When we click on the element we need, it opens up information about how it should look like, how it should work, and we must necessarily conform to everything that is written here. In case we don't comply with that, your app will just be decloned and they'll say We can't download this app because you don't meet our requirements. So it's very important

If you decide for yourself to choose the path of testing mobile applications, you should learn these guidelines. The basic principles that are used in them. Often at job interviews they ask you exactly about these guidelines, how familiar you are with them, they ask you about the elements. what differences there may be in iOS devices, what differences there may be in Android devices, that is, we have to memorize all this. A similar principle is used on the developer.apple.com website.

Then there is information about the different operating systems that are used on different form factors of Apple products. And again when we go for example to iOS, if we're talking about a cell phone, there's a detailed description of how it all works. How it should look like, that is also we have to memorize it, learn it. Know it and be ready at the interview to to be asked about. So paying attention to uh those two guidelines. And uh the last point that I wanted to touch on today.

It will have to do with where do we get the device for testing. Not always your company or if you work on freelancing you have the opportunity to buy the necessary fleet of devices and use them in your work. That's why emulators come to our aid. As I said, we use statistics for our work and We found out for example that we have our two platforms. We found out the versions that we are interested in that are the most common now. We choose a device and we choose a form factor.

a tablet, a phone, or I don't know, for example, a watch, a smartwatch. That is, we have to formalize our fleet of devices. The easiest option is of course to buy them. That is, we go to the resources he showed, look at what devices are the most common, what their models are, and just send the customer this big list of what we need.

Buy for testing mobile applications. If we don't have such an opportunity, then emulators and mobile application simulators come to the rescue. Let's discuss them a little more. First, let's go back to our favorite developers from Android.com and Apple.com. There are two primary aphids used by default to emulate either a mobile device or another dot. These are the Android SDK and Xcode. I have not worked with Xcode 12

and have not worked at all with testing mobiles. On the iOS platform, so I cannot provide detailed information about this tool uh about this tool. Therefore, it is left to your own study and search for more information on the internet. I worked on the Android SDK as part of the course when I took it to the Again, I work in web application testing now, so I don't run into mobile either, but I know something.

and what I know I'll tell you. And in principle, for a successful start, this information will be enough for you, because in any case the Android SDK is quite an interesting tool There is a lot of functionality in it. And it is used not only to emulate our applications. We will talk about it in more detail in the next lessons. We will learn how to install it. I will show you what you will need to work with it.

to emulate it, what we will need to test in mobile applications. So be sure to join the next lessons on this topic. I will not talk about it in more detail right now, that is we can, as I said, emulate our mobile device here, choose which device we are interested in. And the Android SDK allows you to create a these emulators and some access to the functions of this device. There are, and we can emulate that.

Also to Android SDK can be connected directly to your phone and also in real time to work exactly with it. Using this tool. There is also a possibility to take logs from the device in case we have some errors and send these logs to the developer. So uh we will talk about this in more detail in the next lesson, I think. It's probably the same thing with Xcode, you can develop our mobile apps directly within Xcode and also test them using various kinds of emulators.

And then there's also this great resource called NGNEMOCON which I've worked with as well. Here there is, let's say, a fleet of virtual devices. You will have the opportunity to use a free version of this tool, this application. There is a simple registration process here. Create your account and you'll have a few minutes to click on it and try it in your work.

Again, let's talk about this in more detail about when we're directly testing something. I'm going to show you the basic testing that you can do here. The emulation interface is very similar to the Android SDK, although it's more limited here, so you and I are going to look at that as well. It's also possible to for example Test different resolutions of our screen directly in the built-in Chrome DevTools. We probably talked about this when we looked at the DevTools device in general.

But let me remind you once again that you click F twelve in your browser, select toggle device toolbar. And here you can select the resolution that we are interested in and see how the adaptive layout works for this resolution. You can also select the resolution of different devices. That are already pre-installed here, or you can add them here too, custom devices, or if they are not on the list, look. Maybe they are here and they are just not checked off for you to use them.

And you can do all of that here and search for it. We'll come back to DevTools as well when we're going to look at mobile app testing. I we also show you how you can connect, for example, your Phone directly to your computer and working it through DevTools. That is it will be displayed on the screen and we can conduct.

For example, testing of mobile web applications directly using Chrome DevTools. That's the kind of lesson we have today. I think you will find the information useful. The homework assignment is as follows. Explore all of these resources that I will leave in the info box. Also study the various guidelines related to design.

If you have decided for yourself that you want to try testing mobile applications and learn, memorize what elements of are In the user interface, how they should look like and how these elements may differ on Android and iOS. You can also for yourself, for example, try Genny Motion Download and see how it works, but keep in mind that there are only sixty minutes there.

Most likely if you're connecting from different emails you'll have the option to just extend that time. Also, perhaps if you have some extra money and you like this tool, you might consider buying. A pay subscription and then you can work in an unlimited mode. That's all for now. Welcome to our tent. Goodbye.

Hello, YouTube. In the last lesson, you and I went over the main theoretical points that could relate to testing mobile applications. And today let's get familiar with a tool like Android Studio, the Android SDK. I will teach you how to install it and show you the main functions that you can use in your work. And in the next lesson we will look at a list of all the tests that can be performed in mobile applications, so that you know. up what you will need to do, to do directly on our work.

Let's get started to begin. We go to developer.android.com to download our installer directly which will allow us to install the Android SDK. It's very simple to do. We click download, select that we agree to all the terms and conditions, and then start the installation process. I already have the installer installed, so let's proceed to installing the application itself.

We launch our installer and then we wait a little bit for the preparatory work to take place. This process usually takes a few minutes. After that, we get this welcome window where we click next and choose what we need to install. Make sure to check that we have a check mark. against Android virtual device because this is what will allow us to use the emulator for our work with you. Click next.

If you have enough space on your hard disk, insert the default path where this application will be installed. Here we don't change anything either. And install our application as standard when we use any installer. Again, we wait for a few minutes. So a few minutes have passed, the installation as we can see was successful. And we click next. And right from here we can launch our Android Studio.

Let's go ahead and do that. And depending on the performance of your computer, of course, the time it will take to download this tooler may vary. The whole thing is quite a lot. And requires quite a bit of performance characteristics of your computer, shall we say.

So again we get the welcome window. Our installation is not yet complete, I'm telling you right away. And here we can either customize our installation somehow or we can choose the default path. Let's take a look at what we have in the customizer. That is, again here we have information about where we're going to install these additional packages that we're going to need for our work. We can choose the themes that we like better. I like dark themes always.

And this is where you need to choose what you want to install. As you can see I already have something installed because I've installed some packages before to refresh my memory a little bit on how this goes. But most likely there will be check marks everywhere here except Android SDK platform. So you'll just have the API selected here. Click Next and finish, and now we wait until we have all the necessary components installed.

This will take quite a long time, so get ready. Okay, we've got everything installed. It took about ten minutes, probably because I have a slow internet connection. Because this I understand is downloaded exactly from the World Wide Web. And uh after that we have our Android Studio Directly open. And what we need using in order to work in this application, we need to create a project, a new project. Let's do that.

our new projection is created as this uh application is created so that we can also test our applications written by ourselves here or We can upload already ready made applications here and explore them as well. That is, here we have the opportunity to upload different templates that allow us to do this. Let's choose without any activities. Directly you will have to choose. The version of the operating system which is used on your phone or which you will be

Use it for testing whatever you want to test, and then click finish. After that, we will start preparing our workspace, which is the environment where we will work. We will be particularly interested in the AVD manager. The Pixel 3 emulator is already pre installed here and we can run it. As you can see there is still some additional installation required. It is necessary to set how much RAM will be used to work with this emulator. The default is two gigabytes.

As we can see, everything was successful, everything updated. We click finish, and for some reason it tells us that we cannot start ABD. Why can such an error occur? We need to install this H. XXM. Let's install it and again we get an error. We have installed the necessary tool, but we also need to enable hardware acceleration in the bio. How is it done? Now I will find out on the internet. And I be sure to tell you.

So in general I have figured out this problem and I will tell you in a nutshell what you need to do to avoid this error if it appears. I will definitely add two articles to the info box on how to set hardware virtualization. In BIOS, there is nothing complicated here, that is, you just enter the BIOS of your system depending on the type of your laptop or computer and the company that released it.

It's all detailed here on what needs to be done. I have an HP that is you restart the laptop, press F2, I hit escape, go to. In BIOS, system configuration, select virtualization technology, and here you will need to turn on. This function and after that is

The computer will reboot again and uh you should not have this error again. That is I'll discount all this, I can't show it in real time because it all happens at Start up of your computer and I can't use a screen capture application and from a cell phone I would not really want to capture it because the quality will be so bad. Nothing complicated here, once again, I will leave all the links to these articles. And after that we again returned.

To our AVD manager and here we have the opportunity to choose a pre-installed emulator or create your own virtual device that is some cardboard settings in it to do what will be of interest to you. On my computer unfortunately does not work so fast. Android SDK as I said it is quite demanding to the system of the application although I have a gaming laptop. But As you can see, even for him eighty gigabytes. There's not enough memory. And here we can s customize the whole thing, choose those.

Emulators and devices that you are interested in, that is, you can hear and TV, and the smartphone itself, and smartwatches and tablets are tablets. All of this can be done here, configured, pre-installed. That is, it will all just take up a certain space on the disk. As you can see, the pre-installed Pixel 3a takes up almost 10GB on the disk. After that you launch the emulator by clicking on that green triangle.

See, during the first installation you will have your emulator turned on the first time you run it. The device will also be affected for a while. Now I've already done this, so it goes a little bit faster for me. All of that. And now you basically have a a cell phone, a smartphone, which you can test what can you do in this emulator. In the former scenario, you have the ability to test the sound and adjust the volume accordingly. It may not be the fastest application as we can observe.

However, you typically have high performance computers at work which enable you to complete this task much more swiftly. Furthermore, you have the option to change the spatial orientation of your device. Additionally, you can take a screenshot of the screen you're currently working on. For instance, if you need to address a bug, a screenshot can be taken, downloaded, and subsequently attached to your bug report. What else can you do here?

You can go into the so called zoom mode. This means it just zooms in on the place you are interested in. Additionally, the navigation buttons that we have in Android work here as well. That is the back button, the home button, and the overview button. And what else can you do here? By pressing these three points you can use GPS and test it. Also, you can add additional displays of some kind. Moreover, you can emulate the operation of your network.

So for example you can emulate such conditions when you have GSM or 4G or 3G or 5G, that is, you can do all of this or full. Then you have absolutely all kinds of connections. You can also Emulate the strength of your signal. So again, if you are for example in a place where you have a weak signal, where you have a good signal, all of that can be adjusted here as well. Plus, you can also choose

VoIP status that is roaming for example or you are calling from home that is. You can do all of that here too, so it's all at your discretion what you need to emulate and what test conditions you need to create. You can also modulate, for example, the operation of your device when your battery level is at the minimum level. That is, you can do it all here too. As you can see you can immediately set up push notifications that tell you that you have a certain amount of percent left.

You can also emulate what you have plugged into an outlet that is charging your smartphone directly. You can also emulate the state of your battery. For example, if it suddenly died, if it's overloaded, you can do all of that here too. You can also emulate the fact that it is charging or not, or it is not clear whether your phone is charging or not. All of that can be done here as well. You can also emulate, for example, directly calling your phone.

And here, as you can see, you have tapping triggered in the same way as it is on your mobile device. This directly emulates the various navigation buttons. For instance, if you have some kind of game, you can also use microphone emulation. Fingerprint if you have. For example a fingerprint lock, you can do that as well. There are also some virtual sensors, for example, the same accelerometer, gyroscope, magnetometer, or whatever it might be. All of this can also be emulated here.

And here you can also directly create bug reports. What is done here at once? A screenshot is created if you left this checkbox. You can also write the playback steps right away. And the logs of your device are also written. Also very cool. If you uh for example, emulate some error and you need to show the locks that directly happens with your application then you can copy all this and save this report. Again, send it to your developer so he can directly fix this bug.

Snapshots, unfortunately, I don't know what they are, or I can't tell you. Record and playback. If I understand correctly you can do something on the device and it's being recorded. And you can also attach this record to your bug report, for example.

various settings that is where we save screenshots, some hotkeys used or not, that is. All this can also be customized here directly for you even you see you can set a proxy that is some intermediate server between your client directly to the final server. So you can test all this here very well if you, for example, do not have access to

some kind of to the device, I think this is a great tool, but not without flaws. As you can see there are issues related to performance and optimization of this application in general Android SDK. But Tula is very powerful and it helps very well in working and emulating directly your devices. What else would I like to tell you about Tula? For example, you can connect your phone directly here. Is a real device.

And you can also work with it directly here. How can we accomplish this task? It is done and I will demonstrate it on the emulator. First, you need to enable developer mode on your phone. To achieve this, we must go into the settings. You will need to locate. A specific button or tab such as about the device on your phone. We navigate to this section, especially if we're referring to a real device.

Once we find the build number or it might be labeled as the build number we have to press it multiple times. After doing so you'll see a message saying Now you're a developer. What does this give us that you can? Use additional features in your phone and for us we will be specifically interested in the debug mode, which will give us the ability to read logs when we connect the phone to our computer and when we use our Android SDK.

How is this done? So you and I have entered the developer mode and now we need to connect our phone via USB cable to our computer. After that you will need to go to developer options and find an area like debugging. Make sure that you have USB debugging enabled. If you don't have that enabled, just change the toggle to indicate that you have USB debugging enabled. What do we do next?

Let me remind you, this is for a real device. Don't forget you need to do all this on your actual smartphone, especially if you have an Android device, for example. Once you have connected the debug mode, you can now work directly with the Android SDK and your smartphone. To do this, you need to go into the Android SDK and then connect your smartphone via a USB cable. After connecting, make sure to enable file transfer on the smartphone itself.

Following that, you will see a pop-up window on your smartphone screen that says Allow USB debugging. You should select OK on this pop-up window. As we can see, our smartphone is now successfully connected to the Android SDK. And here we can see all the information that we have stored in our smartphone. Additionally, if we utilize a tool like Logcat which is right here, we will have access to the device logs. This means that anything you do on the device will be directly shown here.

If there are any errors, this information will also be displayed in these logs for us to review. These logs you can download and if you need to attach them to the report, you attach them. That is, these errors will be directly seen by the developer and he will know what the problem really was. This is much more effective than just describing the steps to reproduce a particular bug. This is what concerns working. With log That is, there is nothing complicated about it.

Find the bug and be sure to connect. Logging to our device. We need to attach these logs to our bug report. Another thing I forgot to mention is if we, for example, want to install some application on our emulator, this is done quite simply. Again, you start your emulator in the way we already know, you wait a little bit. And beforehand, I downloaded the APK file, which is the file for installing our application. And what can we do? We simply drag and drop it right here into our emulator.

And then the installation of this application takes place. This is incredibly convenient. For instance, you have a final build that needs testing. The developers have uh prepared an APK file for you, and you can install it on the emulator this way. And conduct the testing directly within it. As we can see, we have installed Telegram, because this is an APK for installing Telegram, and we can go into it in our usual way. Work just like on a regular foot.

We'll talk to you about the checks themselves, which we need to be sure to do on mobile devices in the next slide. That is, you get this APK, install it on an emulator, for example, or on a real device, and then carry out all the checks that we will understand. Again, there is nothing complicated about it. It's a very handy tool. Basically for you, for beginner testers, I think this will be enough. That is you. Just learn how to install.

Tool, learn how to root the emulator, how to load APKs into it, how to perform some tests in it. understand all these available functionalities that are here. Because the other things that are here except for logging, I don't think you need to know at this point. And most likely, all of this will be taught to you directly at your workplace. Also, today, let's take apart Genny Motion. which I showed you during the first class. Let's set it up and see what we can do there.

Let's go to the official Gen Emotion website and register. Let's take advantage of this nice offer that we have 60 minutes for. Testing. Let's register using some data. And let me demonstrate the possibility of using some test emails to obtain an unlimited number of these. Licenses. Remember, not all sites allow licenses. If I recall correctly, Jenny Motion permits us to do this.

There is a resource called Mailinator that lets us use public mailboxes for Purposes related to needing to register somewhere uh and use the real version, this site will be sufficient. That is, here we can create our own kind of test boxes. For example, a test, let's call him Artem, and we have an opportunity To use it for a certain period of time and gather some data here, let's register with you, test our teilinator.com company name test.

It's quite interesting how everything here is highlighted in red. For example, from a UI X perspective, it's not very good because it's not clear. We seem to have entered our data, but for some reason it's highlighted in red. I have so many questions for the developers of this system. Oh come on now. Alright, let's try to come up with some kind of password. We confirm it, we select our location, and then we confirm that we are not a robot by doing the so-called captcha. So we confirm that.

We want to use it for free. Well, for some reason the system's crashing. Apparently it didn't like mailinator. So let's use a real mailbox. So we have managed to get into our Genny Motion account. That is, we have registered and we have confirmed our email address. Here, we also have the possibility to use some pre-installed virtual devices which are There's one here in and again just a reminder that we only have sixty minutes. So we can also create some of our own devices.

We can also upload some applications that we need to test here. But let's use some default device and look at the functionality of this web application. Let's select, let's go ahead and Again, our Google Pixel 3A. Our virtual device is loaded, that is, it is created. It takes a little bit of time to load. A message pops up informing us that we're on a time limit. And here we have our emulator.

our device running with our Android system. We can also utilize similar features here that we had in the Android SDK. So this is the volume control. This is for changing the position of our picture or our smartphone. We can also choose to display it in full screen. Next we have some sort of clipboard functionality.

Unfortunately, I don't know what that is. Let's try to input some information here. Hmm, nothing came up. That's very interesting. Apparently, these are some notes that we can create right here. We can also upload some files here. Once again, we can use our webcam as a camera for this device, emulate different levels of our battery, and see whether or not our device is charging. Again, our fluff notification appears. Indicating that there is fifteen percent left to discharge. We can also play.

Around with geolocation using GPS. Next, we can create some screencasts, which means recording our screen, or take screenshots if we need to find a way to fix our bug. Next is identify that is We can apply some identities of our device, like generating an Android ID. All of this can be done here. Once again, we can emulate various kinds of Signal strength or the type of connection we intend to use. That is all this can also be done here.

You can emulate a call or send some message to our device. You can directly change the resolution of our screen, which will also affect the performance, for example, or the discharge rate of our device. disk IO. I unfortunately do not know what it is, so I will not tell you. once again navigation buttons and turning off our device. That is we can also do all this here and we can use it well just like in the Android SDK.

This application, as you can see, does not require as much performance power as the Android SDK, but its disadvantage is that it is of course paid. And again It doesn't cover everything that can be done in the Android SDK. The Android SDK in turn doesn't cover what you can do on a real device. That is, it doesn't cover every feature. Therefore, we cannot fully guarantee the fact that a particular buck will not actually be reproduced on a real device. That is, we should Also test on real devices.

Emulators are not a substitute for this kind of testing. This is such an interesting application, so you can dabble with it too. To practice to see how it works. In the next lesson, I will tell you what all these buttons in the Android SDK and in Gennymotion are for, that is. I will tell you about the types of checks that we should simulate events. Interrupts for our smartphone or tablet or smartwatch that is a mobile device that we're testing.

And how we should be testing this whole thing and what to pay attention to first. So be sure to stay tuned to this channel. I think it's going to be very interesting. The next session will be the last one in the framework of mobile application testing because in my opinion

I can't give you more than what I know myself. I don't work with mobile apps myself. Everything I remember, everything I know, everything I find on the internet, I tell you as well. And this knowledge was also given to me in the course of the year.

In principle, I think that this knowledge will be enough for a position of a beginner tester or for a position of a trainee. So thank you very much for your attention. Be sure to leave your questions in the comments if you have any. Subscribe to this channel if this is your first time here. And check out my social media channels like Telegram and Instagram. Lots of great stuff there too. And we communicate with everyone there as well.

If I don't answer the guys who have been on this channel for a long time or who work in testing answer because I know that there are also current testers in the ranks of my subscribers so we don't put you without attention. Thank you very much. Gracias to our shalash. Bye.

Hello YouTube. Today I'd like to conclude our dive into mobile app testing on a positive note and discuss the checks that Must be performed on our mobile apps directly to ensure they function correctly. There are several basic checks that need to be conducted on our mobile apps. Let's talk about each of these. First there are the interrupt checks. What is an interrupt? It is when the work of our application is interrupted.

by something from the outside. What are some of the checks associated with this in general? For example, someone calls us and we're sitting in some application, either in a toy or in our browser. And we should definitely check what happens to the application after the call ends. For example, it may crash, crash out, or Hang, so we need to make sure that everything is working correctly.

The same applies to incoming calls. That is, for example, if we minimized our application in Wordray and we call someone. And then we want to go back to our application. We should see if everything is fine there, if the information about what we did in RAM is still there, and this information is loaded and shown to us in the same unchanged form. So that's something we can test as well.

There are also types of interruptions like pop-ups, notifications, push notifications. So for example, again, you are playing something and you receive a message from some social network and a push notification appears. Again, we can test this, see how the main application we're working in reacts to this. The next kind of interrupts are discharge interrupts, recharge interrupts. So for example, if our phone is at the minimum threshold in terms of charging, how does the app behave?

Again, there may be some sort of notification that you need to put your phone on charge or that your phone has been put into economy mode. So again, we're looking at the fact that our app is working correctly. Charging means that for example we take our phone and put it

on our charging station. Again, see if everything works correctly in our application. That is, whether it does not fly out, does not minimize to the tray, does not start to slow down. That is, we look at this again. Application minimization and modification. Again, everything is simple here. If we minimize our application in the tray and expand it back, we see that yes, there is really saved information.

Again, if the amount of RAM on our phone allows us to do it, because if we do not have enough memory and our application does not work in the tray, we can see that it does not work in the tray. Application, for example, some heavy toy, then Of course, we have the possibility that it is simply because of RAM. Not is loading the state. The next type of testing is testing the installation, that is we check that our application is installed correctly, that we can remove it for example as

from some market or we can remove directly from the phone by long pressing, pressing the cross and everything is really removed or from the Tobina. Applications inside the settings delete, So we have to check all that and see that yes, we do have Everything goes well. Reinstallation. Again, we uninstalled this app some time ago and we decided to reinstall it back.

We may have some, I don't know, data folder from this app saved. How could that affect us reinstalling this app and the app possibly from that could not work properly? I mean we should definitely check that as well. And of course, upgrades are When we make an update from our Mark it, that is again to see that the transition to a new version does not affect

does not affect our main application, its work uh that is also we check all this. The next aspect is to check various things related to connectivity to the internet. That is, we have to check how our application works on different types of connection, whether it is Wi-Fi, 3G, 4G, 5G, 2G, and all of these Gs that can be. Connected to our phone and its updates, so we are looking at that as well. We also have to check the quality of connection that is

when we have a bad connection, when we have a good connection, when we have a great connection, when we have no internet at all, for example, so we have to look at that. Loss of connection. When we have for example, I don't know, the internet is blocked in the country as it happens in Belarus. Or or you just go somewhere outdoors. And there are no towers there that allow us to give out a normal signal. So we are also looking at how our application works.

And changing the connection type, for example, we're sitting on 3G or 4G and we change that connection type to wi fi. Whether it's really going to work well, whether the connection is going to be intermittent, we have to test that.

As we remember, all of these functions, at least the ones that I have shown you today, are implemented in emulators as well. So you don't have to do all this on a Real device, although of course it is recommended to perform all the checks on a a real device, but if there is no such possibility. you can emulate simulate all these let's say. Unfavorable influences or favorable influences for your phone directly in the emulator itself. I'm not going to show it again today. If you don't know how.

Install the emulator, how to work with it, what features they have. Then now at the top there will be a link to my past video. Where I tell you in detail how to install Android Studio. If we are talking about Android devices, show you what features there are. Be sure to go over, explore, and test everything according to the checks that we're going to go over with you today. The next type of checks is

Working with the phone features. That is, we have some built in features. Phone, for example. There is GPS, there is video photo, there are other phone functions like I don't know, gerometer or there is support for push notifications, so we have to check all that. If we're talking about GPS, we look at what For example, with the API we can connect to the phone's IP and use the GPS that's there. We look to see if our geolocation is actually working correctly. Again, if we have the ability to

use the camera that's on the phone we can test all of that. Check front camera, check Rear camera check. Shirik check telecamera that is everything that we have and that our application should support. Work with what that is, all these things we have to check. Screen size, resolution, orientation. The same thing, that is we have to check on different form factors, for example. If it is stated that our product can work, for example, on a tablet can work on a phone.

Where the resolution is full HD, where the resolution is full HD, where the resolution is HD, where the resolution I don't know what others have. There's four K, two K I don't Know if they are for phones or not. In general, we have to check all of this again whether is working correctly, whether is random. All our pages in our application, we check all of this. We also have to check.

For orientation, that is, if it is stated, for example, that it can work in horizontal and vertical mode, does it really work when we turn the phone upside down there? For this purpose, the phone has just the accelerometer. Which allows us to determine its orientation in space, working with gestures. That is also I think do not need to explain here. We check for example there. Tap different on our phone screen, check minimizing, unfolding. Some phones now have support, for example.

For knuckle tapping, that is also somehow it should work. That is we have to check all of this, all of our gestures. tear swipes, zooming in, zooming out of our picture, we check all of this well and other features of the phone, again everything that we can just think of that we have in the phone and the features that our application supports, let's say, and the access that we give it, that is how it works.

The next aspect is performance testing. Here too, everything is quite simple. We check the speed of our application, that is how fast it works. Responsiveness, for example, If we tap on it then for example that should quickly go for example to the next page. Or If we make a swipe, then also after it should come some action, how fast it happens.

RAM load that is we should definitely make sure that for example our application is well optimized for this or that one. Platforms and did not load the phone very much. Depending on the battery level that is interconnected with interruptions, again we look to see if our application is not slowing down when their battery level drops by a certain amount. We can check just about every 10% as it can happen.

That is how your imagination will suffice and what the end user and the business itself wants to get from you in the end. Run internal memory from a flash drive, so this is more relevant too. In an Android app we can for example install an app both on the internal memory of our phone and install it on a flash drive that we have and see again how our app works. Again, the rest of all the other checks are AD connected to the phone.

Which means we can definitely check for installing on a flash drive, deleting. From the flash drive, updating on the flash drive. Reinstalling it on a flash drive. I mean it's all interconnected. And again I repeat, the number of checks depends only on how thoroughly you need to do it all. how your imagination works, what your customer wants to see from you and most importantly, how much time you have for this testing in general. So

This is the basic list of testing you can do. But beyond that there are our standard, all of our standard, all of our testing, all of our testing types that we can also apply to our mobile apps. Let's take a look at those as well. In the description of this video, I will attach two checklists where all the checks that you can perform are also spelled out. And in general, for mobile devices, there are a huge number of checklists, cheat sheets in the public domain on the internet.

So do you just type in checklist for mobile app checks and you'll get just um Huge pile of all kinds of checklists that can help you with your checks. And going back to the aspect of what else we can test here, that is, we can test this. Documentation, that is we test our requirements, functional testing, that is about what we test here, is what I told you a little bit earlier.

all these checks for interruptions, installation and so on. We should definitely of course check that those functions that are declared in our application that are in the requirements, they also Implement. So I would generally say that functional testing is most important thing you should do. And the first thing you should do. Usability testing, that is for example, how our buttons are well placed.

Whether they comply with Android or Apple's guideline, I mean we all have to test that. UI testing again going back to these guidelines. That is we also compare whether Everything corresponds to way it should be implemented according to the guidelines and the mockups that were provided by. To us, UIUX designer What's good about mobile testing is that while there's a huge amount of testing that we have to do, there's also always documentation available. That is, you already have

Documentation in the form of the same guidelines. It describes in great detail how your application should look. how buttons should be placed, how they should react to your actions, clicks, and so on. That is, you have already simplified your work in collecting and analyzing requirements for your mobile application. Again compatibility, configuration, testing that is. Again we look at

compatibility testing, configuration testing, performance testing, which we have already talked about today. Security testing that's security testing, so we're looking at for example what If we're giving access and permission to use some of the features of our phones that we are inside our application. We do not use any other features that are not declared in this access, which was given to us by the user, because it can cause huge losses and risks for you as a developer and for your customer.

and cause a big scandal because The issue related to sensitive data of your users is very critical, especially now. So you can get into a very big amount of money. Recovery testing. Failure and recovery testing are again recalling our lesson on types of testing.

recall the types of testing that we do there. If you've forgotten, there's a link at the top right now. Go over, take a look. And uh all of this again can be applied and to mobile testing. Again, very often, for example, localize some games for different locales. That is, there is a game in Russian for I don't know. There are games in English for the USA, uh and there are uh a a huge number of games in Chinese that is

We're testing our localization or we're testing our internationalization depending on what our goals are for this functionality in our application. Beta testing, well again, it's also very pretty straightforward. Certification testing, as far as I understand. is compliance with the requirements of Apple or Google according to our guidelines. According to the requirements for Uploading our applications to the store in various markets.

That is, if I am wrong, please correct me in the comments and tell me what certification testing is, because I know that I am watched by mobile application testers as well. Maybe they are more knowledgeable in these issues. And then it goes on to spell out all these all these basic checks that you have to do.

So you can rely on them in your work. When you're I don't know, you're at a dead end and you don't know what to do or you want to simplify your work, you can refer to these checklists. And these Checklist is also in principle quite detailed about what you can do, what checks you do. You can also find additional checklists for Android, additional checklists for

So it all depends on how much time you are willing to spend and how many checks you can perform. Again, there is such a test artifact as a test plan, which allows us to prescribe even at the beginning of our testing. Uh what kinds of testing we will use, what tools we're going to use, what checks we're going to run. And this can very much limit the checks that you need to do for a particular functionality. So also pay attention to that and ask your

team leader, for example, if you are coming for the first time, or the person who is responsible for your management team, for example, how it is implemented in your organization, what kind of checks you do. You may not be checking or testing something. Then you don't need to come up with a bicycle. And I remembered something else I wanted to tell you about as part of mobile app test.

Such a topic On the edge of let's say web app testing and mobile app testing is how do we work in Chrome DevTools using our actual device? Let's switch to our Chrome DevTools and see how this can be accomplished. To connect to our phone, particularly to the Chrome installed on it, we must first access the Chrome that is installed on our computer. We then click on the three dots at the top right corner, select more tools.

And choose to connect to remote devices. This action will open a new tab where you you will see a console at the bottom of the screen. Click on the link provided. After doing this, you should receive a message on your phone asking if you want to allow USB debugging for this device. If you watched the previous video, I detailed how to set this up on a Android device, so you can go ahead and watch that.

Nothing complicated about it, you just need to will need to enter developer mode for that device and select the debugging over USB permission. After that you have your phone displayed and you need to go exactly. into from DevTools that you have on your phone and then you can directly from DevTools, which is right here, write some kind of link for the browser that is installed on your phone. So for example we take a link, we paste it, we

And then click open. After that you will have that link displayed on the phone itself. You can also click on inspect and then when the screen is on you will see the information that you have. On your phone. And if you do something directly on your phone, then all the requests and responses that go through your phone will show up just like in regular Chrome DevTools. This allows us to analyze everything that's happening on your phone as well.

That means in this manner, without even downloading any sniffers, such as Fiddler or Charles, which we will discuss in the course for continuing testers, let's call it that, you can still analyze what is happening on your phone. If you have Chrome installed on it, this is the way in which it can also be carried out. Very similar feature if you need to analyse this.

I hope you enjoyed this lesson, learned something new for you, and now you will be ready to interview for the position of a beginner mobile application tester. You should definitely read all of the guideline as I said in the previous lesson, probably even in the first lesson.

Learn it, make sure you memorize all of those basic checks that are. We have learned with you today to memorize those emulators that we have worked with, what functions they have, to learn how to shoot logs from your devices. That is You need to do all this before you apply for a position as a mobile application tester. In the next session we will talk about requirements, how to analyze them in what form they can be presented, how to collect them, who to communicate with about these.

requirements in general in case of finding any errors in them. Make sure to stay tuned, stay tuned with me, and definitely subscribe to this channel. Also, be sure to leave your comments if you have any questions related to this lesson. Visit my social networks where there is a lot of useful information and where you can ask questions directly to me and to members of our already large software testing community. And that's all for now. Welcome to our tent. Bye.

Hello YouTube, we have come. We're almost to the end of our course tester from scratch and it dawned on me that I forgot to tell you in the very first blog. when we talked about testing theory, about such an important topic as requirements analysis and how we work with them as testers. Why is it important? Everyone knows such an expression as The theater begins with the hangar, and the development process essentially begins with requirements.

That is, without requirements, without any idea, without realizing it in the form of documentation, we cannot get to work and realize what the business and the user wants to get from us. So let's talk about this topic. There are three main levels of requirements. They are the business requirements level, the user requirements level, and the product requirements level. Let's talk about each one of them. And I really hope that my friends, business analysts or product managers

Project managers don't imprison the me if I say something wrong because I still do not work directly. With the co-creation of requirements but everything that I know and used or use in my work, I tell you now. So let's get started. From the concept of business requirements level, it is clear that this is something that is necessary for our business, that is the purpose for which our product is created.

What is the use and how to get profit from this product? That is anything that our business is interested in. For example, a business has a goal to create some kind of website that promotes their products. That's their core business requirement. Then we move on to the level of user requirements. That is, it is clear that this site will not exist without users who will use it.

So the user requirements level covers the tasks that the user can perform with the product, like registering, communicating, looking for information about our product that we promote on this site. that is everything that our user can do. And already the product requirements level is how This is all going to be implemented in our product from a development perspective, given the context of business requirements and the context of user requirements.

And the product requirements layer is divided into functional requirements, what our system should do and non-functional requirements, how our the system has to do that. Does that ring a bell? I think we all remember both functional and non functional testing. These concepts are closely interrelated, meaning that functional testing covers the area of testing functional requirements. Non functional testing on the other hand, with all its various types, of which there are a huge number.

covers non functional requirements. And that's essentially all you need to know about these three levels. Make sure you memorize their names, what they stand for, and what they are used for, because often in interviews they may ask you about the types of requirements you know. and to describe them a bit. Plus, try to find additional examples on the internet For each of these levels. I think it won't be a huge hassle as it's not that difficult.

So we figured out what levels we have and now let's talk about how we can identify our requirements. Most often this is done by business analysts, but in small companies the function of analysts, for example, can be performed by college. And engineers, for example, This also happens. So how can we even identify these requirements? First of all, we can talk to our business customer or to the users of some focus group that will be working with our product.

and find out from them what they want to see in it, find out all these requirements. Next, we can observe. For example, there is already some product that is used in the company that ordered our services and we are trying to develop some new version of this product, more improved. So we can observe how users work in that product and find out what they are interested in, what they would like to improve in their product. So we're observing that.

there's also such a thing as self description. That is, for example, we Do not know how our product works, that is we do not have some prototypes, which we will talk to you about a little bit further.

then we can turn on common sense and describe these requirements ourselves. Taking into account, for example, the interview and observation phase and write them. And prototyping, that is, if we have, for example, A certain website and we are developing a competitor to that website, then we can go to it and see how it works, how certain features are implemented on it. And also to spell them out in our requirements. So there is nothing complicated about it either.

It is also absolutely necessary to constantly ask questions clarifying how. This or that functionality should be realized. In our product and you should not be shy to ask them. When you come for example to a project, you also need to find out one of the very first things you need to know where the requirements are stored in this company. For example, if they are stored in some kind of tracking system like Jira or Azure DevOps.

Or if they are some kind of specifications that are stored in Word somewhere, or if they are a wiki that is in Confluence, for example, or again in Azure DevOps. So we learn all of this, we learn how these requirements change, who is responsible for gathering requirements. who we can talk to if we don't understand something about a requirement. That is, we must specify all this so that in the future our work would be the most convenient for us and for the people for whom we develop this product.

Next, let's talk in general about what we check these requirements for. There are so-called properties of a good requirement, that is in essence the requirement. have requirements to their writing and composition. This is what we will mainly deal with when we study some requirements. For example, let's imagine a situation that Analyst, for example, or product owner has collected information from our customer.

formalize these requirements in the form of user story which we will talk about a little bit further and we are connected to reviewing this requirement and what we should check in. There are seven requirements highlighted here that we need to look at. The first is completeness. What is that? Completeness means that the requirement must contain all the information necessary for developers, testers, or other people who will work with it.

So we have to verify that. There's all the information in that requirement and we shouldn't get distracted and go to other requirements that we have in that system. What does consistency mean? For example you have some pictures in your requirement, for example mockups, templates, UI. that will be implemented in the product as part of this functionality. And there's text. For example, acceptance criteria that we have in user story.

Again, we'll talk about user story a little bit further on, so don't be intimidated. These are essentially Acceptance criteria, which are the criteria that determine that our requirement is realized in this functionality, and for example this picture, this mock up does not correspond to the text that is written in the requirement. This means that The data in this requirement contradicts each other. The same applies to various tables.

Or if we know that a requirement says one thing, but this requirement says something else that does not fit with what we know about, again there is a contradiction. That's not the way it should be. We should. Write to our business analyst, for example, and say that this requirement contradicts, for example

the picture that is attached to it. Next, there is such a property as correctness. That is, the requirement should clearly indicate what the application should do. There should not be, for example, some double meaning word. That is, the system must work correctly. We must enter valid data. That is, there should be no such thing. We must clearly understand what kind of data we must enter. If it is valid data, then for example, it must be clearly stated that it is letters, or it is. Numbers.

or it is decimal fractions or it is special characters or both. That is, all this must be correctly spelled out. The next property is interrelated with Correctness is not ambiguity. Again, we have to be clear about what we have written in this requirement. For example, we're looking at a six pack. There are two people on both sides. One person sees a six.

And the other person sees the nine. There shouldn't be anything like that. We must all work in the same information field in the same context. The next property is verifiability, that is our requirement must be ambiguously verified. as to whether it is fulfilled or not. That is, for example, if you realize that you cannot check it in any way, that is there are no such tools, tools, or perhaps lack of your knowledge.

is a little bit different question. That is, you can then turn to a more experienced tester or developer and find out whether it can be done at all or not. If we can't test it, then uh there is no need for such a requirement. To be prescribed, that is, we must be sure to tell the business analyst about it or already develop these templates, mock ups. It can also look simply in the form of a certain scheme.

For example, it simply spells out all the blocks that we have to have in our application, and for each block it spells out what should be on each of these pages. That is to say, there can indeed be such a variant of writing requirements. At times it might simply be I don't know, a piece of paper where it's written that I want to get this, that and the other, just in a very high level manner, without any

let's say further clarifications on the topic. So this also happens if we are discussing startups or smaller companies where there isn't a budget to hire analysts or even where there are no testers. And then people just brainstorm and come up with what should be implemented. They get paid money and uh In the future, the customer just wants to get a finished product so that, for example, he is not disturbed and doesn't have to specify what else he wants from it. This happens too.

It's probably extremely rare nowadays. There can also be large specifications, that is, these are documents that also spell out our requirements. Business analysts, for example, are already in charge of writing them. Again, if the customer requires it, if that is the way the company's process is structured,

then it can also happen. And we test specifications in the same way. We find requirements, we check these requirements inside the specification according to the properties of a good requirement. and we give, let's say, our verdict so that in the future We can correct it and our requirement meets all the necessary properties that you and I have studied today. This topic is very important for a tester, because testers are involved

in requirements analysis and you need to understand very well all these properties that we have studied today. Today we have studied what types of requirements there are and in what form they can be presented. Don't be alarmed if you get requirements, as I said, in the form of a piece of paper, that can happen too. That is anything can be in the form of claims. The main thing is how we will be able to test these requirements, and among other things.

how we will be able to influence our requirement to be written correctly in the end. That's the kind of lesson we got today. I think you've learned something new. If you still have any questions, then be sure to write in the comments. As usual I will try to answer them all. I also remind you that I have a telegram channel.

Uh also periodically post interesting information about testing and eat. There is also our our little chatroom where we discuss any difficulties you have or questions related to employment, related to aspects of testing. And there's also Instagram where I occasionally answer your questions and try To keep you entertained with interesting posts about testing processes and insights from my work.

Be sure to subscribe to this channel if you haven't, and with that, I bid you farewell. Welcome to our shalash. Bye!

Hello, QTube? Well I want to congratulate you. The day has finally arrived. You and I are finishing up a basic course for testers. Testa from scratch on a topic like Agile. And we're going to take a closer look today at one of the most popular frameworks that is used in Agile, which is Scrum. There are also a number of others which we won't be emphasizing today.

If you're interested in learning more about them, we can talk about them in the next few sessions. So, what is Agile in general? Agile is a set of methods and principles. Agile project management, let's call it that. You and I remember the basic methodology.

and software development models that we covered a long, long time ago in one of our very first lessons on the topic of testing from scratch. The link to this lesson will appear just above. That is, we talked to you about the waterfall model, about V model about iterative models. It is the iterative model that is fundamental, let's say, in Scrum in this framework.

What are these agile project management methods good for? As we remember, in the waterfall model all the stages of development followed each other, that is first for example. There was gathering ideas, writing requirements, then there was development, and then there was testing, and we could not return to the previous stage if we were already at one of them. That is we had to Start everything from the very beginning. Beginnings what are you doing?

Are these agile methods good for? Because we can change our requirements, we can go back to the previous stages of our software development without having this interconnection with other stages. That's why In the year two thousand and one seventeen developers got together somewhere in a resort, if I'm not mistaken, either in Canada or in America. And collected all their comments on how they work with Agile methods in development.

So we wrote what we call the Agile Manifesto. In this Agile Manifesto, there are four fundamental values. Which became the progenitor of further all these frameworks, and in general the agile system itself. The first is that people and interaction are more important than processes and tools. What does that mean? For example, if your team has some principles

structures, tools, conditions that can hinder your work, then you need to get rid of them. The most important thing is that people should themselves choose the way of this organization, a set of some processes, tools, And it is these tools and processes that should help the work, not hinder it. That is why we first of all pay attention to people and interaction.

But right away I would like to point out the fact that even when we say that something is more important than something else, we do not forget that processes and tools must still be present in our project management. and we cannot somehow work without them. The same goes for the other clauses. For example, the next value, that a working product is more important than exhaustive documentation. That is not to say that we shouldn't have any documentation at all on a project.

But this documentation should not be redundant and we should not spend a huge amount of time and resources on it. The main thing for us is to deliver our working product, our functionality directly to the customer. That's our number one challenge. So sometimes we can sacrifice exhaustive documentation. But again We can't exist without documents either. The next value is cooperation with the customer is more important than agreeing on the terms of the contract.

What does this mean? Again, there should not be any redundant attachments to our contracts, any documentation that regulates our relationship with the customer. That is, we should first and foremost pay attention to the fact that we are comfortable cooperating with each other. We do not want to spoil our relations with our customers.

Therefore, any of our documents, agreements, contracts and so on should contribute to maintaining a positive relationship with our customers, but in no way should they spoil it. So that's what is embedded in this value. And lastly, the willingness to change is more important than strictly following the original plan. So even if we have some kind of project plan, If we have some requirements spelled out clearly, we should always keep in mind.

that we will still have some changes over time. Even if for example we had some user story that we implemented in some past iteration, but still over time the business may have other needs. This functionality may solve some other tasks in the future. It may need to be extended. So it is important to remember that there are always changes in Agile, and in principle, this system was created for this purpose.

Also, in addition to these four values, there are twelve principles in the Agile Manifesto, but we are not going to dwell on them in more detail because in fact They just clarify these four values. And I will definitely leave a link. To this agile manifesto that you can read

Everything that concerns principles, everything that concerns values will be described there in great detail. That is, you and I are doing a small overview, looking at how these processes can Be implemented in your company, what ceremonies there will be, what

There are rallies, meetings, artifacts and so on, so that you will not be afraid when you come to the project and for example you will be invited to some iteration planning that is uh You will not be afraid of this rally, you will know what objectives are pursued.

It is this rally for you, for the tester, as a member of the development team, that later on you will be trained how these processes are organized in your company. That is, not always companies use pure Scrum. There are some enhancers, for example. something is not used in the Scrum that you have in your company. Of course this is not quite right because we are going to talk about pure Scrum now and all these modifications.

Do not allow us to say that your company used exactly the following pure scrum. Here, these are let's say the initial things that you should generally know about Agile, about the Agile manifest. Principles and values next. As we can see, we've got forty seven items today that we need to cover within Scrum of this framework. So the session is likely to turn out to be quite long, but I think it will be useful for you.

So that you will not be afraid of this name and this framework in your work in the future. There are three such main parts in Scrum, that is the Scrum team. These are the events that we have in Scrum and the artifact.

These are the ones that we're going to talk about in detail now. There are also various metrics that allow us to To evaluate the effectiveness of your team, the effectiveness of each individual team member and allow you to make various reports, reports for management and for your customer, we will also look at some of them. Hm, let's start with a scrum.

There are three links in a scrum team. It's the product owner, it's the development team, and it's the scrum master. And let's talk in more detail about each of these members of our scrum team and what they do. Product owner manages the product backlog. Next we'll take a closer look at what it is. But for you to understand, it's just a set of requirements that we generally have to implement completely in order to make our product is ready.

This backlog is constantly updated, new features, new user stories, new requirements are added to it. But it is the product owner who collects these requirements and let's say describes the backlog, clarifies it, makes it transparent and understandable for the development team, which in the future will be engaged in the implementation of this functionality, this user. In Pure Scrum there's no such position as a business end.

So basically the product officer does the tasks of a business analyst to some extent. Yes, despite the fact that in many scrum companies there is such a role as a business analyst, but when we talk about pure scrum, there is no such specialist, no such separate, let's say, allocation. We have a product officer. That is the main task of the product owner is to collect our backlog, to bring it into such a form that all. Members of the Scrum development team, team understood.

requirements that they need to realize. Also, product owner prioritizes the execution of these tasks in our, let's say, backlog. So that we understand what we do first, what we do second. And basically those are these are the kind of basic tasks of a product owner. The next link is the development team or the development team. Usually we have about three to nine people in the development team, so we don't need more than that.

We don't recommend to include more people in this development team, because the more people we have in our team, the more we have, let's say, dispersion of attention. And our team ceases to be as flexible as it would be if the team was much smaller. So what should be emphasized about the development team? The fact that this Part of our Scrum team is self organizing. In other words, we don't need any leader to tell us what we need to do. All team members have an equal influence on.

What are we going to do? Every voice of a team member needs to be heard and we self organize as a result of working in one iteration or another, in sprints and in general while working on a project. When we talk about cross-functionality, this is the next aspect. It means that every team member possesses all the competencies needed to. That is to say, we do not separate our team members into developers, into testers, or into analysts. That is, we uh

We assert that if this person needs for instance to write code, he or she will be able to write it even though he or she is primarily a tester. Yes, of course, you might think now that this scenario seems somewhat ideal. Um when we still maintain some degree of specificity or specification, let's say, of the people who work within the team. Yes? That's the way it is actually.

It is extremely rare that absolutely all the team members have absolutely the same competence in all the issues related to requirements, analysis, development, testing. And usually just some person, let's take the same tester. He performs most of the tasks related to testing, but we should strive to ensure that we still have guys in the team who perform absolutely all the functions and can cover them in case, for example, if one of the team members gets sick.

So that can happen as well. So it's perfect scrum, pure scrum. We just memorize for ourselves how it should work in an ideal world. And what we should remember is that there is such a concept as collective responsibility. That is, for example, even if you are a tester there.

So you are essentially responsible for the quality of the product. But we should always remember that every participant in the team is responsible for the quality of the product. That is even including the laws of some simple logic, we can say that. In principle, the developer allowed the probability that we have some bug in code in its implementation, that is in fact he's also responsible for this quality, even though, for example, when the tester misses this bug.

And could not find it in full at the right time, in the right place because, as we remember, exhaustive testing is impossible and it is impossible. to release a product That won't have any box at all. In any case, something will come up at some point. So we have to remember this, that everyone is collectively responsible for creating our increment. Increment is this one piece of our functionality plus all the other functionality that has been previously implemented. It's called an increment.

Next we will talk about it in a little bit more detail. And there is also such a role as a scrum master. So this is a separate person, it's also called a servant leader. So this is a person who facilitates the work in the team according to the Scrum. That is, he knows absolutely everything about Scrum, how it should work, what the main stages are.

We have in Scrum what ceremonies, what artifacts, what He helps us, teaches us in case we have any questions related to Scrum, how it should be realized, guides us, but he is not involved in the development of our increment.

He just gives us advice and can tell us how we can do things better. Our task as a development team, which basically decides how we will behave during the iteration what we will do, by what deadline we will implement it, how we will evaluate certain requirements, how we will prioritize them.

After they have been prioritized, for example, by the product owner, he just helps us That is, the scrum master facilitates the work of the team and is responsible for making sure that we work according to the scrum if we have such a process adopted in the company. So most likely, when you come to the company, for example, as a newcomer, and everything will really work according to Scrum, the Scrum Master will teach you.

Train you, tell you how it should work, tell you how the processes are organized in your company, and we'll, let's say, morally support you so that you do not have any questions related to the functioning of the scrum. Scrum within your team, within your project. The next aspect is events.

that we have in Scrum. First of all, let's talk about what a sprint is in general. Either you may often hear a name like iteration. A sprint is a certain time period about Two minus four weeks that is on average during which we create An increment of a product.

That is ready for use, that is that already fully meets the requirements that we take into work during the sprint, and that we can say with complete confidence at the end of the sprint that they are ready to be used by our end user or our customer. And we have four. Let's say events that are tied to this sprint. This is first of all sprint planning. Or iteration planning, you may also come across that name. It's a daily scrum, daily stand-up, you also see that name.

The sprint review, sprint review and retrospectives. Let's talk to you in more detail about each of these ceremonies. So what is sprint planning? We usually have our entire scrum team come together for sprint planning. which means product owner, development team, and uh scrum master. It is held exactly at the beginning of our sprint. And during this planning we decide what our increment will be at the end of our sprint. And How to organize our work during this iteration here?

To get a finished product increment. Next we're going to look at what the backlog is, but just so you understand, that is during Our sprint planning we have a product backlog where we store absolutely all the requirements that we have for our product. But during our planning we choose what requirements we're going to implement during our sprint. What we're going to take into this iteration and what we're going to use to work.

This is, let's say, the main goal of this event is to define exactly the sprint backlog from the product backlog. The sprint backlog is already a set of requirements that we will implement in our sprint, in our iteration. There is also such an event, such a ceremony as daily scram, or delicate is also called daily scram. It's usually once a day, and at that daily scram you talk about what you did yesterday.

What you're going to do today and what are the obstacles you have for the goal fulfillment. That is, if we talk about testing for example, yesterday I wrote a test case for such and such a user story. Today I will write a test case for the next user story. And what are the obstacles to fulfill this goal? For example, it's not entirely clear to me how developers will implement. Data. Use a story.

So what I want to do today is to contact, for example, the developer who's tasked with this requirement and find out from him how it's going to be implemented, what he's going to do. That's what you're saying. If you don't know how to get rid of that obstacle, for example. You don't know what you need to do, the team comes to your aid and tells you How we can help you when you have this or that obstacle or hurdle to realize your goal, for example for today.

goes through for each member of your development team. They talk about all the work they have planned or done and uh the problems they have encountered. And it usually takes about 15 minutes every day just to keep your hand on the pulse and know what you're working on right now. We uh also have a sprint review, which is the task of which is

To summarize what we did during our sprint, we do a kind of review of what we implemented. During this sprint, checking if all tasks were completed and all user stories were closed. So we are on this, let's say. That's what we're discussing. It is also worth mentioning that there is also such a thing as demo or demonstration of our increment to our product owner or to the customer depending on how you have this process organized.

And you don't want to confuse the fact that at the sprint review we have to show how that increment works, show that demo. This is usually a separate event that takes place after the sprint review and in principle we will not discuss it inside the scrum now. You just show this or that user story, demo it to the product owner for example, and it says yes, everything is really implemented the way we want it. So these are small demonstrations like this.

Depending on the company it can be after the sprint review itself when you show absolutely all the user stories that you have. Implemented in the course of this iteration or for example by the degree of fulfillment of all the user stories that is you have fulfilled one particular user story, you have carried out demo, did the second user story did Demo that is, you can do it. Not in one event but just on the outcome of when you do and

Do this or that user story, that is, you develop it, validate it during the testing process, and then you show it to your product owner. I hope I have clearly explained what this is. And there is also such an event as a retrospective. Again, you should not confuse a sprint review with a retrospective. You'll see why in a moment. Because in the retrospective we have the main goal is that we find out.

Again, whether we have accomplished all the tasks, but in relation to people to the development team. And in this meeting we find out what we could have improved based on the results of your iteration that you participated in. So you answer a series of questions usually. How for example I have this set up in my company or how it was set up in a company where the I used to work before. We have a board that's divided into four, let's say, columns.

In the first column we write down what we did well in the sprint. In the second column we write what problems we had. Where in the sprint? Next we write how we can improve performance, that is how we can improve those problems. We come up with some action items. And uh if, for example, we have some ideas during the retrospective, because usually we prepare for the retrospective and come up with action items before the retrospective.

So if we get these ideas already in the course of it then again we add this one to the board. Usually we just put some stickers, for example, if we are talking about retrospective. when we have offline, let's say, all the team members are present. But due to the current situation with the coronavirus, we are working remotely now. That is, we just check the screen.

And write down all these, let's say, problems or some good things that we had and choose a certain top. The main ones maybe some of the team members have the same problems if they're the same. Then we pick that top and decide how we can improve that. Come up with some action items that are carried over necessarily into the next iteration. And we have to in that iteration improve our process.

in a way that solves that problem. We appoint, let's say, responsible persons for this action item, and we will also find out in the next retrospective whether we were actually able to get rid of this problem what was done.

If we could not, and this problem remains, for example, and it is critical for us, then we again move it to the next iteration. And again we decide what we're going to do, how we are going to work on this problem. This is let's say The main four ceremonies that we have associated with the sprint, I would also like to draw your attention to artifacts.

Today we have already talked a lot about the product backlog, that is about the user stories that we have to realize in order for our product to be released, let's say. Absolutely all the user stories, absolutely all the requirements that our customers have

and that the product owner has added to our backlog. We're going to see how Jira implements this a little bit further. So that you have a picture of how you can track this in front of Attached to the backlog is, shall we say, such a ceremony as product backlog refinement. Product backlog refinement What is it in general? The main purpose of this event is to refine, evaluate and organize the elements in the product backlog. That is, for example, a scrum team and a product owner get together.

And the product owner presents you some new user stories he has written. And if you have any questions, if you don't understand something, you ask the product owner questions and he explains them. And in case you need to rework. This or that user story, it reworks it so that it is clear and clear to you how this user story will be realized. For example, in my team at refinements we also evaluate user stories which we will talk about uh with you a little bit later.

That is, we decide how many so. Called story points we assign to this or that store. That is in essence it is the difficulty of executing this or that user story, but not the time we spend on its execution. Next I will tell you about such a thing as Poker planning, and you will probably understand a little bit more what I am talking about. There are also aspects such as preparedness criteria and readiness criteria.

How are they different? Because sometimes the question arises, we hear the definition of ready and the definition of done. And in the Russian translation you can find just criteria of readiness, and we do not understand at all what this refers to. And let's take a moment to compare what the readiness criteria and the readiness criteria are. The readiness criteria are specifically focused on the backlog level. In other words, we evaluate the user stories that

are provided to us by the product owner to determine how well we understand them and how clearly they are spelled out. For instance, we check for any inconsistencies according to the properties of good requirements, which we discussed in detail in the previous lesson on the side. Requirements testing now the link will appear at the top, allowing you to refresh your memory a little bit about the features we have. So these are specifically tailored towards the user story, our backlog.

These definition of ready properties assist the customer in crafting well written user stories that are prepared for development. When we discuss the definition of ready criteria and the definition of done, they already concentrate on the sprint or release level. And they are already directly related to the assessment. Of the degree of readiness of our functionality. For instance, if we set the readiness criteria at the moment, let's say before iteration planning.

Then we use the definition of done at iteration planning. During sprint planning, here we establish some key points by which we will assess whether this or that functionality is ready or not. That is our definition of done helps.

Verify the work against all the requirements of the project, not just demonstrate that the functionality works. For example, the definition of done might include the following that we have integration tests written and they all pass. We have unit tests written and they all pass. For example, we have less than ten percent of critical bucks. That is we choose such criteria of product readiness definition of done that allow us to evaluate.

What we have ready, this or that area of work, this or that functionality, And we use exactly the readiness criteria in this case. I'd also like to draw your attention to user stories. Again, we talked about this when we discussed analyzing requirements and testing them. Let me remind you a little bit of what they look like. So user stories are basically an intent statement that describes something that the system should do for the user.

So in the first approximation it is some requirement that we have to realise. And it consists of the following Some role in the system that is as some role in the system. I can do something for something. Doing something is some functionality that we have prescribed in user story, and for something is some value to let's say our business. For example, as new users in the system, I'd like to buy a phone to please myself.

Let's say we have a user story like this here. They are described like this, that is there is a basic statement. And then we have acceptance criteria. That is acceptance criteria. where we describe in detail how this functionality will be implemented in order to achieve this value for the business. And usually these acceptance criteria when we talk about testing we take them into account and test each of these acceptance criteria. We have to describe in our test cases every acceptance criteria

if we're talking about any positive scenarios. Well also based on that we write our negative scenarios. And we can use them for example to design extended tests, extended tests, extended testing. That is, we take into account the acceptance criteria and test in the same way as all the other requirements that come to us for review. According to the properties of good requirements that you and I have already talked about, Next, what else I'd like to tell you about is poker scheduling.

As I said, we evaluate our user stories, we rate them by complexity, and let's say we rate them in these abstract things called story points. There are several ways to rate our user stories. One of the most popular is Booker Planning. Let's take a look with you. What that looks like. There are a number of online tools that allow us to evaluate these user stories. That is, we create a room where we specify all the user stories that we are going to implement.

that we have to evaluate, for example for example, at the literacy plenary or for example, at the reflection, depending on how it is organized in your company. And There is a series of numbers. This is the so called Fibonacci series, that is that is so you understand. Usually in the Fibonacci series we use, the first two numbers are either zero, zero or one one for example, and the next numbers that follow.

The first two numbers, they are the sum of the previous two numbers. And so we have this Fibonacci series. And we already have these story points. What are story points? They are such abstract numbers that allow us to estimate the complexity of execution and realization of our story points. of our requirement of our user story. So we get some user story and the whole development team

uh development team gets together and they decide how many story points to assign. We have this decision if we're talking about, for example, a team that took place based on our previous experience. For example, in the last iteration we had to develop uh registration page. Which we spent this certain amount of time on. And we have the second one, we have user story, which appeared in this iteration.

For example, here we already have the functionality of password reset. Here we have, for example, the functionality of password update. The functionality of, for example, updating your account name, your login, for example, in the system. And you and I compare these two racks. So we have the first one, for example, we gave it one story point

in the last iteration. And we compare how much more complicated compared to this first counter where we just registered the system, the second counter, where we already have much more acceptance criteria. And we assign them this story point. That is Depending on what kind of experience the developer has, what kind of experience, for example, the tester has. How long has he been working on the project? Is it a new person or not? He can have absolutely different story points.

After that, when all the members of our development team have voted, we see if these story points coincide, if our vision of the complexity and realization of this rack coincide. And if we get some let's say drop offs for example, someone voted one and someone voted thirteen for example, for this story point, we start a discussion and people explain exactly why they voted that way. And in case, for example, after this explanation.

We have the same, let's say, ideas, that is, someone can convince someone that yes indeed there is not one story point but thirteen. You and I re vote and again look at how we voted, and so for each user story. If more team members have voted equally and evenly and there are no more of these big dropouts, we decide how many story points to assign to each user story.

That is in no way says how much time we have to perform this or that user story. Because often many people are mistaken when they say that story points are tied to time. No, it's a tie to the difficulty of performing a particular task based on some of our previous experience. I hope I've made that clear to you. So here it is. Ways to evaluate and assign story points in our user story. Also, for example, some teams use uh jerseys, jersey sizes.

So there's XS, there's S, there's M, there's L, there's XL. So we can also use t-shirts, for example, to assess the difficulty of attack. We can also evaluate, for example, the size of dogs. That is again, there is a list of some dogs, for example, starting from a chihuahua. And ending with a Tibetan mastiff. That is, we have such a row in which the size of a dog will be responsible for the size of a given user. I mean that happens too.

And coming back to our backlogs, we talked to you about the product backlog. That is where we keep absolutely all the requirements that we have for our product that we're developing. There's also a sprint backlog. As I said, we choose exactly what we're going to implement. In this sprint, that is, we just drag and drop from the backlog of the product backlog to the backlog of the sprint.

I'll tell you how you can calculate exactly let's say the maximum number of story points that we can fit into our sprint backlog because that will determine how many tasks How many user stories we can take into the development of a given iteration? Product increment, like I said, is everything that we've developed before.

And we'll develop at the end of this iteration, meaning you never have to say that product increment is exactly what we're developing in this particular of the iteration, and we'll provide it to the customer when it's finished. Product increment is everything that we have already developed before this iteration plus this part. of those legacy features, those functionalities that we will develop

in this particular iteration. And another aspect is the various metrics that we use which regulate, for example, how many tasks we can take on in a particular iteration, how quickly we can accomplish them, and generally view. In dynamics, how it changes. Let's say the number of tasks that we complete over time. So the first characteristic I'd like to tell you about is velocity. This is velocity of our Scrum team. It is calculated as the arithmetic average of the completed.

Story points in the previous prints, so For example, we have a new team and we don't know the velocity. Because, for example, we haven't finished the first iteration yet. So we take a certain number of story points in a given iteration, execute them, and see how many we were able to execute, and so on with each iteration. And then when we have a certain amount of historical data, we can collect the arithmetic average.

Over these several iterations and say that according to the statistics we can, for example, take thirty story points per iteration, no more, no less. And we set this goal. So we can take more for example in the next iteration for the same iteration planning more than we have in our speed.

And the next characteristic is capacity or capacity, the amount of available time of team members. How is it calculated? That is, we simply take here. Those hours that we have per iteration for each specific full time. Developer in our development team.

That is, if we have, for example, an iteration takes ten days, of which we know that we have two days off, we subtract these two days off from ten, we are left with eight days, and we know that the working day, for example. Uh we have eight hours. So we are eight, multiply by eight and we get the figure sixty four hours. That is our capacity. Our capacity per developer. And we multiply these sixty-four hours, for example, by the total number of developers in our team.

And again, this helps us with our sprint planning. Again we need to put different risks in here because of the fact that For example, here we have a pandemic right now that Speed and capacity, for example, may depend on the fact that some team members may get sick, so we pay attention to that as well. Again, capacity may decrease because we get some holidays. Again, we're taking these holidays away from us.

that is We put all of this in right away and we assess the risks before we plan this or that iteration. This is usually done by the scrum master. But just to let you know that there are such characteristics as speed and capacity. And then there are two other metrics like the burn down chart and the commodity flow diagram. You and I are So let's go over to Jira with you and see how this can look at all visually in buc tracking and in a project management system, let's say.

I sincerely hope that you have already downloaded Jira, or rather that you have registered for it, since we discussed issues related to. With the design of backtracking reports in the ten lesson, And you should already be a bit used to the interface of this backtracking. So let's go straight to the backlog tab. Here we already have some project created and we have a backlog. I've created hypothetically several user stories, so

This is basically our backlog of the product where we have several stories. I also created a sprint directly and we can easily redirect, let's say, using drag and drop our stacks into our sprint. And now we have in our sprint backlog three user stories that we have to fulfill. We can go to the board of our project and see that we have two user stories in total status.

In order for us to see how they can be dragged further, I have dragged one of the total stories to the D1 status. That is when, for example, we have already developed everything, tested it. And have shown, for example, a demo. And our product owner has approved that yes indeed this story has been tried and done correctly, according to those requirements, those user story acceptance criteria.

in which he prescribed. This is roughly what our board looks like exactly in Scrum. Of course there can be many more stats. Many more, let's say, columns from which we can pull some or other user stories. Also here during our development we can have different shuffles, bugs can appear, which we also transfer by drag and drop from one status to another. That is

All this can be done visually here too. There is nothing complicated about it. Just to get you a little bit used to how it can look like. And in the user story itself. We have as we see with you a story point. That is when you and I have evaluated this uh the user story, we add this evaluation. Because this evaluation we later influence various graphs and reports.

so that the product owner, the scrum master can understand how far we are moving towards the goal, whether we are on time or not. And can later suggest some corrective, let's say, measures in order to to improve our And there is also such a tab as reports. And here we have various kinds of

Analytical statistical things. First of all, you might be interested in looking at the burn down chart and the commodity flow diagram. There's also a velocity chart, that is how our velocity changes during an iteration. There are also various charts and reports that allow management to evaluate team performance. And somehow influence it in case we see some

Drawdowns. If we talk about burn down chart, then here we simply collect the number of story points that we take in our iteration. That is, for example, we have laid down six story points, that is. The sum of all story points in our user stories is six. And we have let's say our ideal chart, how it should decrease, that is, we should gradually decrease the number of story points and take them to work so that everything would be smooth.

And when for example we have something beyond this line we can analyze it, for example Scrum Master can analyze it and provide a decision to the management on how we can be improved, what influenced it can communicate, for example, with the team on how we can improve it, why we had such a jump.

In other words, the management of all these charts is already doing the analysis. So for example, a tester, a developer, just for general development to understand where the team is at right now, you can go in there and look at that. As for this cumulative flow diagram It looks a little bit different here. That is again we have a legend here. How many entities, let's say, items are in Todo status.

how many items are in in progress status and how many items are in done status. So again, you and I can monitor all this, see if we really Finish our iteration on time, let's say if the number of our items in the todo status is decreasing, how many items are in the done status? That is all this We can also analyze and the management also understands if we really fulfill our goal, if we have time in the iteration to close all the tests that we have planned.

And how we can improve our process as a whole so that we don't have these issues in the future. That's probably all I wanted to tell you in this big, shall we say, overview. related to Agile and in particular related to Scrum, I will leave you a link. to Planet E Poker so that you can see what this tool is and how it works.

I'll leave you a link to the Agile Manifesto so that you can also familiarize yourself with it, read about the principles, read about the values that are in the Agile Manifesto. I will also give you a link to the scrum guide, which you should also read because here is a detailed description.

Of what I told you today, let's say so briefly, plus there are some additional things that I didn't pay attention to, because I think that for a beginner tester You don't need to dive into these points very much, but for general development you should read it. Because it is a fundamental document to implement Scrum in your company and to comply with it. The requirements that we have spelled out in this guide And I'll also leave a link to Kanban Guide which we haven't talked to you about today.

I've never worked with it with Kanban, I have a rough idea of what it means. If you will be interested, I can record a small video about Kanban, but for this you don't need Also to prepare, but you can also read it, that is here as well as about Scrum all the basic aspects that are required to.

This framework are spelled out, so it is also on merit. Read about it's definitely not going to be redundant. And at the end of our class I would like to congratulate you once again on the fact that we have finished the course of tester from scratch. And in fact already now you can apply for positions in different companies. Respond, try to get an interview, try to communicate with recruiters.

Make sure you have a page in LinkedIn, design your resume, design a cover letter. So it's a great time for you to start looking for jobs. Once again, I advise you to revisit those videos that you did not learn very well. Choose the registration form and test test. Make test cases, make checklists, make bug reports. Download the mobile application. Test it according to the features and testing of mobile applications that we talked about. Spoke with you as well.

Discover some bugs, ask me questions, inquire in our telegram channels which are specifically dedicated to assisting you in understanding various aspects of testing. You can message me on Instagram. Once again all the links are provided just like in the video description, so they will appear on the screen shortly.

Don't hesitate to chat, chat, explore, Google, Google, Google, Google Google, go Google and find answers to your questions. And I truly hope that this course and these lessons will genuinely assist you. in understanding testing and securing your first job. I'll see you very soon. We will begin to delve into uh uh various aspects of testing more thoroughly and learn how to utilize the different tools that I employ in my work.

We will communicate, share positive emotions and grow together. This is the most important thing. And as is our tradition, please come to Oshalla. Bye.