Software Tester: From Zero To Hero! | Michele Spoldi | Skillshare

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Software Tester: From Zero To Hero!

teacher avatar Michele Spoldi, Sr. Developer

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

36 Lessons (7h 48m)
    • 1. Instructor introduction

    • 2. What are Software Tester prerequisites?

    • 3. Example of a workday for a Software Tester

    • 4. Software Tester salary

    • 5. Introduction to Section #2

    • 6. Remote work or in the office

    • 7. Different naming conventions for a Software Tester job

    • 8. Windows, MacOS or something else? Which machine to choose as a Software Tester

    • 9. Defect types

    • 10. Defect Priority VS Severity

    • 11. How to report a software defect

    • 12. How to write a test case

    • 13. Boundary values

    • 14. Let's talk about SAT

    • 15. Peer review

    • 16. Different test types

    • 17. SAT vs UAT

    • 18. Expand knowledge as a Software Tester

    • 19. Common tester everyday mistakes

    • 20. SQL basics

    • 21. SQL Coding exercise

    • 22. Prepare for a Software Tester interview

    • 23. Common interview mistakes

    • 24. Introduction to section #3

    • 25. Team leading in Software testing

    • 26. API testing introduction

    • 27. Postman part #1

    • 28. Postman part #2

    • 29. Postman part #3

    • 30. Complex JSON

    • 31. Useful sources

    • 32. Does each tester need to start test automation?

    • 33. Different Test specialities

    • 34. Validated projects

    • 35. Prepare as manual for automated tester role

    • 36. Tester, PM, BA, PO...

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

Community Generated

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





About This Class

In this course, I will talk through becoming a Software Tester - also known as Quality Assurance (QA) Tester.

I have divided this course into three main sections, each focusing on a specific topic, and progressively more challenging and advanced.

We are starting at level 0, so do not worry! If you have no idea what software testing is, what prerequisites are to work as a software tester or how a typical day for a software tester looks like - we do cover it all in the introductory section.

In the following sections, we focus on the fundamentals of software testing as well as more advanced lectures. There you will find hands-on material to follow at your own pace while learning more technical topics (GITflow, Rest API testing, reading and understanding a JSON).

Apart from that, you will find Quizzes and "Coding Challenge" which allows you to test acquired knowledge.

Meet Your Teacher

Teacher Profile Image

Michele Spoldi

Sr. Developer


Experienced IT Professional (+7 years) who had the privilege to work in various roles and companies (video game tester, functional tester, automated tester, developer) across different industries (gaming, banking, pharmaceuticals) and varied projects.

Daily tasks and challenges required different skills that thanks to Udemy he can share with you. Passionate programmer for Garmin Watch-faces and Xcode iOS Apps.

Deep believer in lifelong learning and knowledge sharing with other people all around the world.

See full profile

Class Ratings

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

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

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

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


1. Instructor introduction: Hello and welcome to our next lecture. Before we move any further with other interesting topics, I have planned ahead. Let me start by introducing myself. More than seven years ago. I started my testing career as a video game tester. I remember till this day the moment when I saw an opportunity to join a British video game testing company called tests running. At the time, I didn't really have a clue what exactly testing in general, software testing meant. But I was open to a new challenge at so I joined many times while using a software, whether it's BI desktop software, mobile software, or video games. Yes. I am an active video again player. I've had many, many consoles and I always enjoyed them. So I was familiar with the whole concept of video games and understood that sometimes there were bugs, issues, defects on a video called a problem in a video game. Of course, we've all as giving you again, mers encountered issues, whether it would be some disconnection from online match, maybe a boss that was impossible to kill due to her issue in the code, issue in the game. So as our gamers, we probably always encounters some issues. However, after joining the company, I had a crash course. So for 23 straight days, I was from the morning till the evening learning quickly about testing software. And the boy was I for a surprise, in a very condensed training, I learned about testing the video games in a black-box manner, reporting defects, retesting defects, executing very simple test suites. Let me tell you that it was a lot to take in for a new joiner. However, I did it, I managed. I was testing mobile video games afterwards, also moving to console video games and compliance. All the goods sometimes ends. So I moved to accompany called Roche pharmaceuticals. Ross was another big, big step up for me and a huge challenge to be honest with you, mainly because it was a medical company. So it involved really difficult testing when you compare it to video games, are very responsible testing because any mistake could be really grave. But also due to more complex testing. In general that I was performing while working as a contractor for Rosh, I was involved actively in the SAT testing as well as validated projects. Let me just say that it was a really, really tough, right? However, from there, I went to our finance company called IPF digital. Where I was, for another surprise, I was welcomed into the financial world, application, software testing. It was a little bit less of a jump, less of a challenge. Let's say that in joining as a contractor, rush, because I already knew what SAT was, already knew how to write and execute great test cases. I knew how to report defects, returns them. There was no surprises there. However, apart from learning the nomenclature of finance and financial testing while working in IPF, I also met a great leader, test automation leader, who introduced me to the topic of programming and in general, more technical testing. While working there, I started learning programming, started working more on databases, API testing. In general, I was exploring new skills, technical skills. This is what enabled me to start learning by myself. At home. I was, I was really hooked, Let's say I started learning programming. So I start with live learning all 10 basic languages. I've done some boot camps. I've done some online courses for Java, Python, of course secure, advanced secure, but also Postman. Then I moved to Android Studio. Of course, using Java. While working at IPF, I started developing my own personal applications. So either it was some commute up for iOS that I developed in Xcode, connecting the APIs and displaying them on the maps. Or whether it was even a simple thing, like watch face for smartwatch, Garmin spot watch basically, and publishing it so other people can enjoy it. Absolutely, of course, for free. The next step from the IP or digital accompany for me was to move to another finance company. This time Citibank. Citibank was a great journey, gave me a lot of possibility to work strictly in a technology company. I wasn't really doing much manual testing, but I had great opportunity to develop and enhance my technical skills while working with some of the best professionals on the market. So this is briefly my last 78 years of my life. Now I am living in Hong Kong with my wife. And I am trying to move more into teaching, into being an instructor. Because I strongly believe that one of the most important thing that you can do is to pass on the knowledge and really make more and more people interested and join development as it is, whether it's an development or software testing in general. I strongly believe that we are going to see in the next couple of years more and more what possibility in those areas. So that is my mission. I strongly believe that many of us should consider this particular career path. And here I am trying to pass on to you my seven, almost eight years of knowledge. Let me welcome you to this course. And I hope you enjoyed all the lectures that I have prepared for you. 2. What are Software Tester prerequisites?: Welcome to our next lecture. This time, let me talk about what are the prerequisite for a software tester? Of course, same like for other jobs. Not everyone is suited to be a software tester. You have to fully accept older comes with it. And at the end of the day, ask yourself, do you liked it and is it for you? But before encouraging you to think about even switching or starting your career as a software tester. Let me shed some light on what being a software tester requires and involves. So we are looking at a person who is fairly new and has not yet been working as a software tester. First, let's talk about H. Is there a specific age for a tester? Is there a limit of age for a software tester? And the answer is no. I have been working from my career with both very young testers and by very young, I mean, 1819 years old testers, as well as very, very mature testers or software developers in general. So I've had the pleasure of working with more than 65 years old professionals who are still enjoying every day of their work. So no, there is no specific age restrictions for becoming or working as a software tester. Next point by ground. So do we need to have a IT or technical background to work as a software tester. And here again, the answer is no. Remember we are talking about a person who is going to start working as a tester without any prior experience. Everything you learn, you will learn on the job, on the trainings or like you are doing now, maybe before applying for the software tester job, I had the privilege to work with many, many different professionals in various companies. And I've met many different people with different backgrounds. So of course, you will emit a lot of people who are either at the moment studying electronics or IT related, studies, IT related college courses. But at the same time, you will meet many people who there are studying or have already majored in completely non IT, non-technical majors, like for example, History, Literature. I've met even people after majoring in art. They all had successfully started working in software testing or in general software development. So now there is no baggers prerequisite to start your testing journey. Now the next point, IT knowledge, do you need to know a lot about IT in general to start working as a software tester. Well, here the answer is little bit tricky. Yes and no. No. You don't really need to know much about technology. I have also met some testers that had absolutely no idea about a given technology that they were testing. For example, mobile phones or given operating systems when it comes to a desktop or a video game console, they did not out of the box know how to operate one. And they had they had to learn, they had to get to know the system. And still of course, and they were successful in their job. However, it would be your advantage if you want to go testing web browser applications to be a little bit familiar with using a computer, using a desktop browser. The same thing goes to mobile testing. If you'd like to test Android mobile apps or iOS mobile apps, it would be really nice if you knew how to fluently quickly navigate those operating systems. And the same goes, of course, to video game consoles. If you'd like to test on PlayStation, it's nice that you know how to access various settings of the PlayStation, how to capture screenshots, captured video, et cetera. I wouldn't call this must I wouldn't call this up such requirement. However, this will be for sure your advantage. The next point is working conditions. And here it is a bit simpler. Considers, in my opinion, only one way to look at this in software testing or in general in IT app development. You will be looking at a lot of time spent sitting, or in general, in front of a TV, monitor, computer, whatever it is on you are testing on mobile phone, whatever it is. So you should really assess if this is something that suits you. You will be spending that say, in general, eight hours per day in front of one or more, probably even a few screens. It of course will be your workstation, for example, a TV for a game console. One smartphone, one tablet. So you will be in front of the screens. At the same time, you will be sitting down at a desk. So if you really hate sitting down for more than 12 hours, this can really be a deal breaker for you. Of course. Nowadays, there are some smart desks that are desks that you can lift up so you can stand up while working. This is not a solution. If you hate sitting down more than one hour, you will not really be standing up for seven hours a day and then going home and still loving your job. So working conditions, please really think about this, the result of sitting involved and there is a lot of time in front of the screen on multiple screens, new health as well. The next point, personality. So here, what I mean by personality is that whether you are a software tester or another role in the development of an application. Please remember, we are all small parts, small cog wheels of our big machine that is developing an application. What does this mean? This means that in general, you could be a team player. You should be open to talking with others, communicating smoothly with others, working in software testing, but in general, in application development is not really something that you can do on your own. Of course, we all consider down in front of our desktop. And once we know how programming is done, we can write an application should. But here we are talking about the professional aspect of the job. So coming to the office, and of course, we will have big or small or too big, but still those will be things made of different members. So again, being a team player is something that is a nice to have when you're thinking about becoming a software tester. And my last point is English. So do we need a specific degree? Do we need a specific language level to be working as a software tester? So as you can here, of course, I am absolutely not a native speaker. My English is what it is. I really do hope that I am speaking slowly and you are able to fully understand me. However, you can clearly hear that, of course, English is not my native language. No. You do not need to be a native speaker 2 or in an everyday software testing job. Software testing is being done. Now all around the world. I have myself in working in at least two projects where if involved cross globe tins. What does it mean? It means that our team was stretched through a few continents. So in the morning, for example, that would be Japan working hard. Afterwards, way in Europe would pick up where a Japan left. We will progress with the job. And in our afternoon, United States would also login. And of course we would hand over the current progress of testing. What does this mean? Of course, we all communicate in English. So whether you are in Japan, in Europe, or in the United States, we all communicate that using the same language. It was English. This means that, no, you do not need to be native speaker to work as a software tester. Now, let's stop here, however, and this is crucial and I would love to stress this. You need to be able to fully understand what you are reading. For example, from an e-mail, what you are hearing, for example, on a team meeting and be fully able to express your own thoughts via an email or on a meeting. This is crucial. This means that please remember this is a professional environments. You are expected to understand what someone is writing to you or telling you. In English. You are expected to fully and clearly communicate your own thoughts. In English, this is really, really important because unfortunately, I've met many software testers outside of us, outside English speaking countries that had this problem. And of course, when you are receiving some email that you do not understand, you can kind of cheat now. You can use Google Translate and you will more or less accurately understand meaning of this email. However, this is a slippery slope and absolutely the one that I do not recommend, especially that it truly be obvious in 1 second when someone is trying to talk to you or when you are in a hurry when you need to write our issue, a bug defects that you are just really, really struggling with English. So my advice would be to ask yourself or maybe do some tests and really makes sure that your English is at a proficiency of professional level, that you can clearly understand suffering that you are reading, someone is saying, and the Q that you can clearly communicate. You can, of course, like me, have a weird accent, a strong accent. However, if someone English native speaker does not understand what I'm saying, I have the privilege that I can repeat it once, twice. And of course, finally, we will get where we want to be. However, if you are not sure how to translate something, that is whether you will have problems. So this point again, English skills. Yes. If you are thinking about becoming a software tester, there is a possibility that if you are lacking professional skills in English, you will need to address those either by studying yourself learning, or by signing up to a language school in order to boost your language skills, your English skills. Those are all the points that I had for today's lecture on what are the prerequisites for software testers. I hope you enjoyed this lecture and see you in the next one. 3. Example of a workday for a Software Tester: Hello and welcome back to another lecture, another introduction lecture designed to help you introduce into the possible career path of a software tester and get you acquainted with what being a software tester involves and help you make a decision. If it is that I think for you today, we are going to be looking into a typical work day of a software tester. This would be an example of a workday that you can expect working as a software tester. Okay, so a few notes before we begin. This will be a typical day for what's called Manuel software tester. So this will not be a typical day of an automation tester. This would be a typical day that she can expect if you decide to switch our begin your career as a software tester in general, in this example, I will describe two days for two different roles. Because you need to understand that there is a significant difference in awarding day of a video game software tester when compared to an application software tester. Video game software tester, video game tester will have a little bit less of daily activities when compared to an application software tester. Let's begin. A typical example of a day for a video game tester. You would arrive at your office in the morning where you will receive an e-mail or a notification that a new build is ready for testing. Built means in tactical terms, basically a new version of the video game in question, if you again in testing. So what does this mean? There is a new version that has been created probably the previous day, in the evening. After all the programmers have finished implementing their changes and deploying them to the repository. So the next morning, you are receiving the most up-to-date version of the video game that you are testing. As a video game tester, you will install this newest version into the device that you are testing this on. So for example, PlayStation, Xbox, maybe a mobile phone, depending on what is your testing target device. Afterwards, you will typically receive some daily tasks, daily activities from your testlet. This is another important thing that as a video game tester, often you will have a testlet. Really, really rarely, you will be left alone to pick up and distribute your own tasks. Most often. You will have a direct leader, a team leader, testlet, and he will every day give you or assigned to you specific tasks. This can be testing our particular new character, or maybe a new car, if this is a racing game, or maybe part of the level that has just been implemented. Last evening. You will focus most of your time during this day on the given task. So you wouldn't be either testing the new car or exploring the new game area. And of course, if there is anything that is an issue that is not correct, you will create a defect, a ticket, an issue letting the programmers know there is an additional work that needs to be done regarding this particular part of the game that you are today testing. So to recap, as a video game tester, you will often get your daily tasks in the morning from a testlet. You will then execute a given task. By testing specific part of the game. Report any encountered issues, they will eventually get fixed by programmers. So you will also, from time to time get a new version of the application containing the repair, the defect you reported fixed. So you will need to pre-test. You will need to check, in other words, that the issue that you are experiencing and reported has been in fact fixed by the programmers readily in video game testing, you will also receive some test scripts. Scripts being a list of steps that are precise and help you test a particular scenario. However, in video games, often you will be doing some exploratory testing or focusing on a given part. But you will not be working every day with test scripts and tests scenarios. In my opinion, video game tester is a very good place to start as a new software tester. Mainly due to, as I mentioned before, video game testers having a bit, a little bit less of daily tasks, which lets you focus more on the things that you are learning every day. So of course, creating a new defect report. So reporting an issue, of course, communicating with the programmer. So images, testing meetings. This is a really slow paced introduction position that is a really good opportunity to start working as a software tester, but at the same time, have a little bit more of a briefing space. Now let's move to the software application tester. As mentioned before, this will involve more daily activities than a video game tester. So let's begin and application software tester will mostly be testing on a specified target device. This can mean desktop. For a desktop application, for example, Windows machine, macOS machine, or maybe a mobile device for mobile application. So an Android or an iPhone for iOS system, of course. It can also mean simply browser, target. For example, from Safari. If you are testing a browser on the application, working as an application software tester, you will probably in a Scrum or agile methodology, even if you start as a new tester, junior tester, Scrum and join in recent years has become what you can call hot thing. So more and more companies every year, but basically every day are moving or trying to move into the Scrum agile sprint methodology. Living on this, some giant companies struggling with implementing the new methodology and remaining in the waterfall. What does it mean for a software tester? Well, for you as a new joiner, it means that working in a Scrum agile methodology, you will need to plan better your day from the start, even when you are basically learning the job in comparison to the video game tester here due to the methodology. So Agile Scrum, a testlet will be dedicated to either oversee the whole of the projects or even higher, the whole of the test team working in a team, you will rarely are basically never have a dedicated testlet, a person that will oversee your everyday work, your everyday problem, uh, testlet will be on the organization level site and not directly in your team, in your project or not even present at all. Maybe organization will have only testers and no testlet. Again, working in a sprint in Scrum. As a tester, you will need to do a lot more planning At your own. Often, you will be present on many squatting meetings and as a tester, you will be also asked to either estimates some changes that need to be tested or some Barbary pirates. And as a new joiner, this can be really challenging. So here's already one big difference when it comes to video. Again, testing an application testing, I will be having a dedicated lecture to Agile Scrum in general sprints ceremonies, as well as the methodology itself. But this will be far ahead in our upcoming lectures. So this will be covered. But you don't need to know this. Now, so after this short introduction, Let's provide an example of a workday for our application tester, as well as we did for a video game tester. So you can see clearly the differences, of course, for an application software tester. And today we'll also begin in the morning. However, due to Scrum methodology, you will begin your day by a daily meeting. You will meet with your whole project team members quiet and go over current problems and also what each of you is working on. You will directly be talking with the whole development squad. While as a video game tester, you are readily meeting on daily basis with programmers and other team members. You are mostly working with other testers here. As the application tester, after the daily meeting, you will basically get on with your job. As mentioned before, the testlet is rarely or never present, so you will not really be getting any precise daily tasks from another person. This means that you need to already have and knowledge, proper knowledge, to know how to prioritize your job, your tasks, what to do first, what to do next? What is the good practice? What is the first step of testing? Of course, you need to do analysis of the given tasks. They need to write, test cases. They need to get reviewed afterwards. You probably should execute someone else's test cases and they will execute your test cases. In the meantime, you will be reporting as well defects. You'll be creating test scripts scenarios. You will be pretesting defects. However, this will get really more complicated as an application software tester compared to a video game tester. There are also other ceremonies involved in a Scrum sprint, like grooming or introspective meeting, sprint planning. However, those might not bring any bells at the moment. And as mentioned before, I am planning a separate lecture dedicated to explaining to you every one of those ceremonies. So for now, just understand that as a software tester working in an Agile Scrum application squat, you will really have more meetings where your input, of course, will be evaluated. But also you will have a lot of difficult questions. Ask directly to you. As the main point, I would say that application software tester needs to have much more experience. Of course, you can join as a newcomer. Our company that offers you a position for a junior software applications as them, however, you need to expect the first few months to be a tough one. You probably will have other testers on the project that will kind of introduce the application to you as well as all the good practice you will need to be much more self-organized. And now what you are doing and what is the next step that you need to do tomorrow, the day after tomorrow? Because remember, you will be responsible for the deadlines. You will not be getting the tasks that need to be completed this day. You will see the bigger picture, Let's say two weeks ahead. And you will need to somehow schedule your workload by yourself in order to complete those tasks on time. And if wherever you are struggling, prefer decision. Should they go work as a video game tester at my first job? Or should I work an application tester? I always recommend working a little bit. The video game tester, there is nothing wrong with this. This will give you a little bit mode of briefing time. You will be learning slowly. There will be less pressure. I tell my friends is always the same, like we have a motorbike. There is nothing wrong with starting your motorbike journey on a smaller bike instead of going for the big one, is the same with testing. I have always endorsed becoming a video game tester as the first job. 4. Software Tester salary: Hello and welcome back to our next lecture. This lecture is the last one of our introduction section designed to help you better understand what software testing is about and who can do it. Today's lecture topic is salary. What salary are you looking at while working as a software tester as the time goes by, we will also look at software does a salary depending on the candidate, years of experience and skills of curves layer as well. Let me start by saying that more and more companies are developing video games and also especially I would even say, software applications. Every day, every year, there are more and more applications on our devices. This means that year-by-year, there is more opportunity for you to work as a software tester. First of all, let me start by saying that salary will of course depend where you are working, in which country and also for a company from which country. So those figures will differ depending on wherever you are working around the world. Order, where is your employer located? Also, do not forget that your own individual negotiation skills will play a big role in the salary you are receiving. Lastly, please remember that all the figures that I will give you are based on either my professional experience, my colleagues, or the medium, the average earnings for given position in the, mostly US or Europe. So please treat this as our reference point, but not as a guarantee. In this lecture, let me give you three candidates salary examples, depending on candidate experience and skills. Candidate number one. In this example, we assume that the candidate has absolutely no working experience as a software tester. He or she has 0 years of experience working as a software tester or in IT development. In general, the candidate has some Windows desktop experience, meaning basic Windows desktop skills. He or she, the candidate can read emails, working on Excel, work in wars application, of course, open a browser, do some really basic things, take a screenshot. But still, this is a skill that our candidate has. Our candidate also uses personally mobile phone and is familiar with its operating system. In that example, let's assume Android and also on daily basis uses video game system. Let's say PlayStation. Such example, paints a picture where the candidate is just starting his journey into the software tester role. Meaning the company will need to invest a lot of money and time into teaching this candidate. Everything there is to know about, well, at least video game testing, because we can assume that it is a video game company looking for a software tester, video game junior tester. In such case, the video game company will mostly offer such candidate a temporary contract. Let's say a trial run for a few months to see how the candidate does in those few months, we've, of course, an opportunity to extend into longer contract if the candidate proves to be a good employee. So when it comes to the salary for our candidate number 1, let's assume that candidate is working five days a week, eight hours per day. And here you will be looking at a relatively low figure, 24 to 40 thousand US dollars per year. Let's move to the example number two, candidate number two, our tester is applying for a software QA engineer to a web application testing company. Hour candidate has now to three years of experience. Proficient in English can successfully and quite easily write a test script issue defect report. Candidate has also, on his own, learned the basics of secure can quite easily execute basic secured. Queries can be the number two, does not require a significant amount of training once he she joins the company. So we are looking at our candidate that after a relatively short period of time can be fully efficient in a new company. Here, in this example, we are looking at probably parliament contract with a salary around 40 to $60 thousand per year. Now, let's move to candidate number three, senior software tester. Our candidate number three, senior software tester has now four or five years of experience. Candidate is very familiar with software development lifecycle. He has spent many, many hours working on different applications, different projects. Our candidate has a very good knowledge of Scrum agile methodology. With all the ceremonies that come along, our candidate is also a very experienced software tester, can very precisely analyze all the requirements in our functional specification. Along on the corner cases, our candidate is very fluent with secure and can find test data no matter how complex the query will need to be. Senior software tester can also actively support testing lead by helping other team members, testers wherever it is needed, whenever his guidance, if needed, senior software tester can be asked to temporarily lead a project. Or reported directly to our client. As due to his years of experience, he's really comfortable with such situation. Senior software tester can have a daily task of taking Manuel already executed and tested test scripts and automating. Then in order to run every day, for example, as a smoke test or a regression test. Programming is known to our candidate number three, our senior software tester, for example, Java, python, or Swift, on an intermediate level, sufficient enough to write automated tests as well as maintain them and review them for other team members. This means our candidate number 3 is familiar with primitive datatypes, control flow, of course classes, inheritance, functions, good flow, and code review. Other technical skills like reading application logs are also not a problem for our candidate. Number 3. He's very technical. I will candidate number three can also test the rest APIs. So also do some back-end testing. Of course, please do not forget our candidate number 3 is still a senior software tester. The code that our tester is creating, that our candidate is creating, is designed to test the application. Of course, he's not a programmer. The code is not designed to change the application. The code that our candidate number 3 creates, it's only testing the application here. Please remember we have a very experienced, let's say for 56 years candidate with many technical skills, such candidate will be looking at a permanent contract with Men and bonuses included, of course, as well the yearly bonus. And it's looking at a salary from, let's say 70 to 120 up 1000 US dollar per year. Please note that in this scenario, candidate number three there, and salary depends heavily on the company. The budget of the company, and the negotiation skills of our candidate number free, along with of course, how well the interview host. And this will be all, we've covered all three of our different candidates. I really do hope that this shed some light on what you can expect as a future software tester, what kind of salary you can expect. Of course, this will be depending on a candidate experience as well as skills. But I hope this gave you some general idea you have completed now the introduction section. I hope that those lectures helped to shed some light on what software testing job requires. In the next section, we will be moving into more detailed lectures on working as a software tester. See you there. 5. Introduction to Section #2: Hello and welcome back to our course. Let me welcome you into the second part of our karmas. In the first part, we focused on getting to know the role itself. So I hope that now you understand better what being a software tester involves. What are the challenges, what are the requirements, and how a typical day can look like for a software tester. I also mentioned briefly the salary. So I hope that now it is a little bit more clear. You can expect working as a software tester. Now, let me welcome you to our second part of the course. Or in the first part focused on introducing the role of a software tester. The second part will be one of the most important in this course. In the second part, we will focus on all the fundamental skills of the functional tests, then this will be crucial to understand. So please ask any questions or if whatever something is not clear and if needed, please do watch it twice or more times. Really, trust me, understanding the fundamentals of software testing is crucial. The fundamentals of testing will be used regardless if you are a junior tester or later on moved to a senior tester position or automation test her position. In all of those, you will need to have a strong understanding of testing fundamentals as he will be using them in every day work. So again, understanding this section of a course is crucial. So without further ado, let me welcome you to our second section, testing fundamentals. 6. Remote work or in the office: Hello and welcome back to our next lecture. In this lecture, I would like to talk about remote office work from home or whatever you would call working remotely from a different location that your office. I would like to talk about advantages, disadvantages, and what are the prerequisites in order to be able to work from home. Let's begin. Currents times are especially difficult when it comes to going to the office by using public transportation, commuting due to possible exposure. Once everything comes down as a software tester, you will be asked in many different companies whether we prefer to work regularly from an office or whether it was preferred to stay at your home to work from your home office on permanent basis. If you've never worked regularly from home, how to make a decision, how to be sure that you are making the correct one. So right of the bench, Let's say that probably even if you decide to work from home button, then realize that it's not really suited for you. The company probably will, without any problem, lets you switch to on-site office working arrangement. However, for example, in my case, once I started working remotely on permanent basis, I completely fell in love with it. So you should also give it a try and maybe it will have the same effect as on me. First of all, let's start with the technical requirements. So what is needed to even be able to start working remotely from your home office. Now, let's list a bare minimum, what is required in order to be able to work from home. Of course, you need a desktop or a laptop, a machine on which you will be working and connecting to the office. Components like email, gyrus, test applications, you need a desktop or laptop. The next step is high-speed Internet. In those days, you need a high-speed Internet in order to be able to efficiently work from home. Next is communication. Of course, it will be joining meetings. We'll be having phone calls with your colleagues. So you need at least working headset. So a microphone and some earpiece in order to be able to speak and also hear your colleagues. And nice addition will be a video camera so that people can see you when you are talking to each other. And those are, in my opinion, is the bare minimum is needed to work from home. And the next step is being eligible to work from home. Of course. If you have a question in the office, you will just stand up and go ask your colleagues. Next to you about this particular question. However, if you are working from home and so are your colleagues, you will need to use some instant messaging app in order to communicate and ask the same question. However, this can mean that the question will take 34 times as long to answer as it'll stay in a office on-site office situation when you just get up and and it wasn't a question. This unfortunately makes it difficult to work from home for new test status. Less experienced testers, typically, our junior colleagues, our less experienced testers Will. And of course, it's a good thing, will be asking a lot of questions as we've just discussed. If there is a lot of questions and answering, each of them will take more time, then it becomes really unproductive to have dose less experienced new joiners work from home. However, of course, the opposite is for unexperienced cluster. Even if you are just joining a new company, if you are experienced and you understand all of the basics of testing, of the fundamentals of testing, you can effectively work from home, even if you are new to the company. But with, let's say, three years of experience as a tester, you will probably be just fine working remotely. So in my opinion, in general, full-time remote office is for more experienced testers. Not really recommended, in my opinion, for the junior status people who are just starting working in software testing. So let's move ahead and talk about advantages. Disadvantages while working remotely from your home. Let's start with advantages. However, piece naught, those are my personal opinion and we heavily depend on the type of person that you are. Advantage number one, no commute time. So there is no communist time, both in the morning when you are going to the office, as well as in the evening when you are returning home from the office. Working from home means that you are skipping the commute. So this can save you 12 hours a day depending on your commute time. Advantage number two, cost-saving, working from home can be cost-saving both. When it comes to, as mentioned, commute. Of course, you need to pay some fee. It's not for free, as well as, for example, food. So it can turn out that eating at home can be less expensive than eating lunch at work. Advantage number three is the one that I mentioned before. That will depend on the type of person that you are. So for me, it's a huge advantage. Quiet environment. So when you are working from your own home office, there will be no chit chat. There will be no discussions about irrelevant stuff like football matches last night TV show. You will be able to just simply focus on your current tasks. I personally discovered that while working from my home office. I was way, way, way, way, way more efficient in my job and I was able to do much more work in our work day when compared to the office when there was a lot of noise and distractions. However, as mentioned before, maybe this is something that gets you going, gets you motivated being able to talk about some unrelated work staff with other people. I'm not judging this is, as I mentioned, really, really, depending on the type of Paxton that show our next advantage, having a comfortable working station. So for me personally, this was always an issue in Delphi's. I am a very tall person and I almost never found the perfect combination of desk, chair and the other accessories. So TV monitor and et cetera. However, when I'm working from my own home, I can of course select the desk and challenge that perfectly suits me. Thus, I am having a very comfortable workstation. So this is an advantage. You can configure. You can set up your own workstations hover however you like it. Whether it's the size of the external display, the chair of the desk. You are your own boss. You can set it up just to suit you perfectly. And the last advantage is kind of obvious one, but well, while working remotely, you are at your own home. For me, personally, this has always been the same point. I am always the most relaxed why I am at my own personal home when compared to the office, when of course, the environments, it's a little bit more stressful. So this is also an advantage to me. Being at your own home even while at work. Now, let's move to disadvantages. Disadvantages that I see from working from home instead of an office. So this advantage, number one, it is connected to our advantage. You need to have your own workstation. Of course, most of the companies will provide you with some company laptop. However, you need to have a place to comfortably sit. Trust me, sitting for eight hours with your laptop in front of a dining table will not be the perfect solution. You need a comfortable desk as well as a comfortable office chair. The same goes for accessories. So if you want an external display or a specific keyboard, mouse, you will probably need to buy them. These adventures number two, sometimes depending on the team, it can be more difficult TO communicate. In my personal experience, I was working with great things in Rosch. We were all working remotely across the globe. We had a team in Europe as well as in United States. And we never had any problems with Swift application development. However, I've personally in other companies met people that had difficulties when it comes to communication while working remotely from home. In such cases, or let's say in extreme cases, you would write to such a person or an e-mail or instant messages. However, the question would remain unanswered for one day, automobile or even days. Of course, such a thing would not happen in an office where after, let's say one hour, you will just get up and approach the person, ask them this question directly. So depending on your team or teammates, let say, you can possibly have a little bit more difficulty when it comes to getting some answers. And in general, communicating while working remotely. Disadvantaged. Number three is being able to focus. While, as mentioned before, for me, working remotely is a great thing, a great possibility to fully focus. I have known personally many, many people who are actually the opposite. So while working at home, they are finding it extremely difficult to focus, whether it's by having some keys ask you questions and in general, the Stelvio or maybe to your cut, you have pet, your dog, your neighbor, your favorite TV show. I've known many persons that are actually really, really struggling with being able to focus while working at home. And of course, if we're talking about a permanent situation, they will simply unable to fully work from home for an extended period of time. Next, small disadvantage is that, as mentioned before, working from home will save you a little bit of money on commuting and maybe dining out. However, The same goes for electricity bills and internet. You need to pay those bills by yourself and why you will be working at home. You will see some increase in the electricity bill as well as you will need to pay your fast Internet, fast broadband bill. And the last disadvantage on my list is time management. This is again, a very, very personal point and will be different for each of us while working at home. You are your own boss when it comes to time management, of course, most of our testing controls will require us to work around eight hours day in our king week. However, again, I have met many of my colleagues that have extremely struggled with working from home. Due to the fact that you wake up, you are at your home. The company laptop is right there. You are working your whole day and when you quit work, the laptop remains there. So many of my colleagues get into a trap that they just continue working. It doesn't matter if it has been eight hours, nine hours, ten hours. They would just sit in front of the laptop and work work work doesn't matter if it's evening. This can be extremely problematic due to the fact that of course, we all need some time off. We all need to relax in order to be better employees, in order to work more efficiently the next day, we need to do other things that only work. However, many people have real, really struggled with separating your job from your personal life while working at home. Meaning that, for example, now you are staying for one week without leaving your home. Unless you try this, it can sound funny, but separating your working hours from your leisure time from your time off while staying in the same room at the same flat can be really something that you need to work on and manage. My best advice would be to just try it, see how it works. However, plan out your day, set a clear start and end of your workday. Plants some time with your family, with your pets, on for your own hobbies, whatever it is you like. Really just tried to make a plan and then stick to it. Otherwise, you will be just overworked and in general, unhappy indices, my experience from the people that have Ptolemy the study, you need to have some boundaries and clear understanding what time is work time and when do you get off and enjoy the rest of your day? Those have been the advantages and disadvantages of working from home, working remotely. I hope that you enjoyed this lecture and learned something new. And I will see you in the next one. Bye. 7. Different naming conventions for a Software Tester job: Welcome to our lecture. This lecture will be about naming conventions, as you've probably already heard during our course, I have to use a few different terms when it comes to software tester position, software tester, job naming. So I used of course, software tester as well as QA tester, QA engineer. That is because many of those job titles are basically synonyms. They mean the same thing we are testing software, but the naming conventions differ. I would like to dedicate this lecture to shed some light on those naming conventions and explain Whether they're all the same job, the same position, with the same requirements, or maybe do they involve different things and different skills and different levels. So without further ado, let's begin. In my career, I have seen many, many different job titles, whether it was for myself or my colleagues. We were most of the time doing the same job, the same challenges, the same daily activities. However, at one workplace, my job title was test specialist at another company I was doing, let's say kind of similar things. I will still testing software, but my job title was QE technician, quality assurance technician. And yet in another company, my job title was QA specialists, like quality assurance specialists. So what's up with that? Are those the same positions or maybe know, like, why are there different names for a software tester? So let's begin with the synonyms, job titles that from my experience, involve the same activities, the same everyday tasks. And let's say we are looking at candidates or professional, that is every day working as a tester. He or she, the candidate is testing your software to reporting defects, creating test scripts, executing test scripts, joining team meetings, but also doing some basic technical work like using basic SQL queries, Reading basic application logs, output logs. And in general, as all of us testers, such person is responsible to maintain the highest possible quality of the final product finally, released application for such a role, I have seen many different job titles in my experience, they all mean the same responsibilities mentioned a moment ago. Those titles were as follow, QA tester, QA specialists, QA technician, they all related to quality assurance, Tahitian specialists tester. Another job naming convention that I saw was functional tester, where it was clearly indicated that the position will not involve any automated testing. And also, to be precise, I saw a physician named labial tester in order to make crystal clear that the candidate will be testing applications on only mobile devices. Other two examples of different naming conventions, but the same responsibilities were tests specialist and software tester. So as you can see, we have quite a few different. Naming conventions. However, they all have very, very, very similar responsibilities and daily activities. I wanted to mention this because when you will be looking for a tester role, you may encounter various different names were looking for a job. So do not hesitate if you see those fuel mentioned job titles. Go ahead and click in the job description to see if you are the perfect candidate. Do not hesitate, do too. Weird, or different job titles that maybe you held in the previous company as a tester, if in a previous company you work other functional tester in your name description, do not hesitate to apply for a test specialists or QA tester at all. As probably the day activities they responsibilities will be quite similar. Now, I would like to mention that there are, however, naming conventions when it comes to testing jobs that do involve some different responsibilities and skills required to apply for such a job. Two examples, number 1, automation tester. Of course, if you see a job opening for an automation tester, you know what the job will involve? The job will involve automating manual tests into automated ones. So you probably will be using Java or Python, and you will need to have a strong programming skills, at least in order to create and maintain automated tests as well as good knowledge of good in order to of course, use that repository, as well as general coding practices in order to create a pull request and also review public requests from your colleagues. And the second example is QA, engineer in general, as the word, engineering involves more technical skills, such a tester will probably be more advanced, also have additional skills, technical skills, but still can be involved in the, let's say Manuel testing. So SATs. However, such a tester, I expect, will have more years of experience, let's say 45 years, and will be fluent when it comes to advanced secure queries. Also probably will have some automation background. At least the QA engineer will be able to, maybe not, right, but at least use automated tests even locally on the machine so that the engineer will be able to download the repository and trigger lunch, the automated tests, for example, on the desktop while testing the application locally. This is the end of our lecture. I hope that now you have a better understanding of the naming conventions related to working as a software tester and many different job naming will now not look so scary when you are browsing some job offers. Thank you for attending this lecture. Bye. 8. Windows, MacOS or something else? Which machine to choose as a Software Tester: Hello and welcome to our next lecture. Today's topic is Windows, MacOS, Linux. What systems are best for software testing, and which one should you choose when it comes to selecting an operating system for a machine that you will be working on it virus. Sometimes startups will give you the opportunity to choose any model that you wish, as long as it is within a specified company budget. This means that you will be able to choose any machine that you want, whether it's Mac or Windows, as long as the price tag is a given threshold. However, such situation is read mostly limited to small startup companies. Most of the companies, or for sure, bigger companies will give you a choice of 1, 2 machines, but probably from the same vendor, from the same company. This is mostly due to the fact that, for example, if you are choosing from the novel, then company has a great deal and a discount on each machine due to the fact that it's a big company and they will be buying many, many, many units from the vendor. Of course, having one or two machines for the whole company makes life easier also for IT support. But let's be honest. Most important reason why the companies, the big companies do it, is because of the discounted price tag pair the machine. So if you are the lucky one and you have the opportunity to choose whatever machine you want as a desktop or laptop, which machine should you choose? In my opinion, the best way to approach this is make some small list of items that make the Research Complete. Write down the answers for some questions. For example, what will you be using this machine daily for? Is it testing a native app and Native for Windows and Mac OS up is it may be for testing mobile devices. If so, is it Android or iOS? Is it may be a CPU intensive application or macOS only application. I know it's some silly, but writing down the key points of what the machine should have will make it easier for you to choose the correct one. If you'd be testing our web application on the Chrome browser, then it doesn't really matter which machine you chose. All of those will probably run from browser, just fine. And you will be able to test the application. It will come down more to your personal preferences. Which system you prefer, macOS, windows. And then if Windows, which machine you prefer more. However, the testing should be done just fine on whatever you choose. The next point, native up here, your choice, of course, will be limited. If you are testing a native macOS up, you will not select a Lenovo mushy. Same way around. If you will be testing and native Windows app, you will not be selecting a MacBook or iMac. Of course, you could round some visualization or some bootcamp. But as a general testing cool, you should never use any emulation in order to test the final product. So testing the final version of the app for Windows on Mac would be a really bad Fink and no-no from testing guidelines, point of view, mobile testing, if you will be testing mobile application, well, the situation here is a bit more different. Android will be fine with both MacOS and Windows machine. However, an iOS app will be best done on macOS. Machine testing will be easiest, and also the features, additional possibilities offered by MacOS are not to be found on a Windows machine. Test automation. If you are planning on using existing automated tests or creating new ones. In general, both MacOS and Windows machine should do just fine. Of course, as long as they are quite powerful and goats when it comes to performance in general, however, please make a mental note that if you are about to write automated tests for iOS mobile application, then you need to select a macOS machine, do to Xcode working on macOS system and being the easiest to automate on iOS when it comes to testing video games, there isn't really much of a difference. It will come down most to your own preferences. As nowadays, we are able to connect all the main game consoles. So of course, PlayStation, Xbox, Nintendo, to both macOS as well as Windows operating system based machines, and do all the basic stuff. So this will come down more to your own preferences. And this is the end of our today's lecture. As you can see, when choosing a machine to have dedicated for your testing, there is a lot of possibilities. Only a few scenarios dictate a specific machine, specific operating system. However, most of the cases, let should chose the operating system as well as machine of your choice. Thank you for attending this lecture and see you in the next one. 9. Defect types: Hello and welcome to our next lecture, defect types. Whenever you are testing software, if you encounter something that should not be there, an issue and defect and bug, you of course, will need to report this. Creation of a new defect will be covered in detail in the upcoming videos. However, today, I would like to go over effect types so that you know what kind of defects you can expect while testing software applications. Defect type will be one of the mandatory fields that you will need to feel while creating a new issue, a new defect report, defect, type number 1, visual defect. Official defect is one of the easiest defects to spot due to the fact that as the name suggests, well, it's a visual one. And thus, it can immediately be easy to spot that something is not right. Let me give you some examples. Our game character missing half of its body, big mountain with missing background behind it. Or maybe from some mobile applications, half of the image missing a cropped image, cutting health, of course, all of those are visual defects and should be reported as such, defect number TO functional defect. A functional defect occurs when you are expecting a certain behavior from the application. But another different one Accords the expected behavior is not met. A very quick and easy example would be a calculator application, let's say on your mobile phone or on your desktop. And a result of five, when you input two plus two, obviously, you are expecting a different result. So this is a functional defect. The application is not functioning as expected. A video game example could be a car that is at full speed hitting the wall, but the collision does not occur. The car just drives through an empty map and goes on, goes on forever instead of crashing into the wall. This is as well a functional defect. You are expecting something else, but the expectation is not met. Can you see they're all before the car drives right through it? Yes, you can. So this is not a visual defect. However, the functionality of the wall is missing, thus, functional defect. Just as a remark, we have also number 3, defect type localization defects. However, you as a regular test cells, will probably not be involved in any localization quality assurance. When it comes to quality assurance of localization that are dedicated test cells that focus only on localization quality assurance. So most of the time you will be just passing any concerns to those testicles and not reporting by yourself. Of course. And defect when it comes to colonization means that, for example, if your software has been generally created in English, but you are trying to translate it to another language, for example, Spanish. And there is some issue of the translation. Well, who then we're going to have a localization defects. However, as this specific testing, well, you obviously need to know another language to do it. This is not something that you will be doing on daily basis. Not do we have the competencies to do it? Defect number for performance defects. And easy example of a performance defect would be video game. Well, we are expecting a stable 60 frames per second of performance. And upon accessing a specific location than frames per second count falls down to 21. Or maybe we're having an issue if our mobile application, when after accessing some money, after accessing a specific tab in our application, the screen freezes for four to eight seconds and is completely unresponsive. For those few seconds. In general, performance, the defect will occur whenever we see a substantial decrease in the performance of our application in testing. And defect type number 5, stability defects. Those defects are critical as here, the user experience is very much at stake. None of us, as the end-user, would like a situation when we are just about done taking a few minutes video of our children playing somewhere on the vacation. And suddenly the application crashes and the video is gone. It completely disappears. We have no way of recovering this. Or maybe if you are playing your favorite mobile game, you just finished the race are very difficult to raise as the first person, as the first car, as a winner. And the application crashes right before saving your current achievement. An application crash, meaning lack of stability of an application, is a very serious one. And such defects should always be deeply and thoroughly investigated along with all the crash logs. Those were just a few examples of the main defect types. Each organization can have additional ones as they can be configured in JIRA or other reporting software. However, please note that those are the main and most common defect types that you will encounter as a tester. I hope you enjoyed this lecture and I will see you in the next one. 10. Defect Priority VS Severity: Hello and welcome back to our course. Today's lecture is about priority versus severity of a defect. Before we move on to the next lecture and actually get a hands-on experience on how to write and report a defect. We need to cover one more, but very important to understand section. And this is priority versus severity of a defect. In my experience, one of the things that gets new testers confused when reporting the effect is the difference between two fields on the defect. But creation page, defect severity and the defect priority. Understanding and distinguishing those two is crucial when it comes to application development lifecycle and should be understood before raising your first defects. So let's begin. Let's begin with defect severity. Defect severity can be explained or looked at as how much given defect is serious from a business point of view. In order to best understand this, let's look at another example. Imagine that you are testing a mobile application and Mumbai and banking application. One of the application may features is to onboard new customers. However, while testing, you have discovered that upon trying to upload a photo of your official ID, a mandatory step, that application completely crashes. It happens every time you try this and there is absolutely no way the QC, you can upload ID photo to the application form. As mentioned before, the official ID attachment is mandatory, so you are not able to move anyway farther with the new customer registration. Now, when it comes to severity, you have to ask yourself, how much will this defect impact the business? Well, in that case the answer will be a lot. As one of the main reasons to create this application is to easily and quickly onboard new bank customers. So now new customers will not be able to join us. The crash we did occur and they will be forced to stop new customer registration. One of the main application requirements will be completely failed due to this defect. In such a case, when reporting this defect, your foot mark the highest available severity for this defect. In that case, it would be blocker. In other words, you are communicating to the whole development team that these defects will completely block the release of the application. The application cannot be released with this defect and fixed. It will completely block the release and this needs to get fixed. The severity is the highest the blocker. Other severity types include critical, which is of utmost importance, however, is not blocking. Progress, major for the generality effects, minor defects that can be fixed along the way, but do not really have to in this iteration and can be fixed in the next application version and cosmetics, defects that can be fixed. But if they never get fixed, it won't be the end of the world. They are really, really small defects. Kind of nice to haves. In my opinion, just to give you some context. Minor defect would be image on a website that was supposed to be exactly in the middle of the page, however, is just a few millimeters to one side. Now let's move to priority, defect. Priority. Defect priority in comparison to defect severity is focused on the project general timeline. Let's best explain it by using the previous example of a defect. The one where the customer cannot move forward with new customer registration due to a crash occurring while trying to upload the photo of the official document. As we have already established, the customer cannot move forward with new customer registration. Does this defect we have the highest severity possible blocker. However, when assigning a defect priority, you have to kind of adapt a different mindset. What is the priority of fixing this defect in relation to current development cycle, to current state of the sprint or your current team objective. Let's imagine that you are in your last two days of the current two-week sprint, where the sprint objective has been to prepare our login customer in order to demonstrate to business that an existing customer can successfully logged into his her account, execute a transfer. See all the existing credit cards, debit cards, et cetera. Well, in that case, this is your main focus for your whole team. The process of logging in an existing customer and seeing the customer. Main screen. However, a crash occurring when onboarding a new customer will not be the most important thing. An existing customer login will be the most important field. In such a cases, the priority will be, let's say, a medium one, or even law, depending how you see fit. Now, let's change the situation. Now, let's imagine that you are for days from the official release of the application to the live markets. So to the Google Play Store and App Store for days left and you discover such a defect that will in fact completely stop permanently possible millions and millions of people from creating new accounts with your bank client. Well, the situation has changed rapidly, hasn't it? In such a case, of course, the priority of the issue of the defect would be the highest one. You need to get this fixed immediately, both the severity and now the priority due to have very close and go live very close. Release date is the highest one. So there you have. We've discussed both the defect severity as well as defect priority with examples. I hope this is clear now you can clearly understand the difference between defect players defect severity. If there are any questions, do not hesitate to ask. I will see you in the next lecture when we will be finally reporting new defect. And to end, See you there. 11. How to report a software defect: Hello and welcome to our next lecture. In this lecture, we are going to look on how to report defects and issue a software bug. Those names are all synonyms and mean the same thing. A problem with our application, with our software that we are testing. For our demonstration, I will be using Jira. Jira in my opinion, is one of the most popular tools in current software testing companies in order to track software development along all of it, tickets and items. In general, if you are testing an application like medical complication or maybe I'm autonomous driving car application software. In other words, software that affects human life. You might be using another type of application to manage your ticket items, defects, probably HP ALM or another validated application. However, please remember that the defect will look similar and will consist of the same points. Okay, in order to start, we need to imagine defect. So let's look at our super secret project story. And as you can see, this is a story about a simple login process. You can see the description of the story as well as the acceptance criteria of this particular story. Of course, as you can see this a very simple story. It requires the fields to be present, as well as the customer being logged in upon providing an existing customer data, meaning of course, the username and correct password and seeing an error message upon entering invalid credentials. Now let's imagine we are executing our test scenario for this particular study, a positive test scenario. So we are on the login page, we have entered an existing customer username password. We press the login button. However, as instead of being logged in into the Maya count, we are seeing an error message, for example, 500. So at this point you can see that some of the acceptance criteria have been met. We see the login page. There is a username field password, field login button. However, the logic is not correct. We have entered an existing customer username as well as correct password, crust the login button. However, the customer is not being logged in. In this case, of course, we need to raise an issue. Defect software back. This needs to be changed by a programmer. You start by pressing the Create button. Select our project and the issue type. Of course, it is going to be a bug. It's not a story is not an epic. This is a software bug. In square brackets. I will be writing the section that is mentioned here. Of course, in real life you will not be including those brackets. However, it is a way for me to kind of give you some tips on how to visualize each section of our defect. So let's start with the summary. Briefly describe what is the problem of the issue, what is the issue about? So in our case, we will be describing that customer cannot login after providing correct data. Now let's moving into the description field. The description field is the main field of the defect report. Let's start first by briefly writing the defect description and expand on the summary. As you can see, we briefly described what is wrong and what is the problem with these particular and back. The customer cannot login. The login remains in view and the network console shows a clear error, network error 500. The next thing to do will be to write clear retroduction steps. It's meaning the steps needed to reproduce this issue. This section is being used so that other people in the development team can easily reproduced this issue. It can be a product owner, but of course also the programmer that we'll be fixing this issue and wants afterwards to check before deploying whether this issue has been fixed by retesting the issue, following our steps. As you can see, the steps are very straight forward. We are accessing the login page, inputting a valid username, values, passwords for the username, and pressing the login button. The reproduction steps are not difficult, but also they are precise in this case. The next section will be the what is called repro section. Of course, it's about the reproduction rate. Reproduction rate means how many by following those steps above, the issue can be reproduced. In this case, we've checked this issue twice, and both times the issue did occur. Sometimes you will encounter issues that are not easy to reproduce and also do not gets triggered each time that you try to reproduce them. For example, there might be a case that you input correct username and password for an existing customer. However, sometimes the customer, upon pressing the Login button is correctly logged in, and other times there is an error. In such a cases, your reproduction rate would be different. For example, five out of 10. However, in our case, we are experiencing this back, this defect every time we try to reproduce it. Two out of 200, 100% Next section will be the expected results section, as well as actual results section. Those fields are meant to provide quick data for a person that looks at this issue for the first time. It briefly describes what you are expecting and what is the final result. Instead, as you can see, the expected result of course, is that you would expect a customer to be successfully logged in upon providing correct existing customer username and password. However, the observed result, the result that is observed after executing the steps from above, the customer remains on the login page and in the network console, we visibly see a network error or 500. This is kind of the essence of correct defect report. You can see a short summary of what this issue will be about. Afterwards in the description field, you can see our bit expanded, the summary, a bit more info steps to reproduce. In order to help anyone to reproduce the issue. I put hashtags here. However, this is a shortcut in Jira. Jira will automatically enumerate all the steps. This is just a shortcut. Now, reproduction rates, meaning how many the issue is visible upon trying to execute the steps above. And we ended the description with expected to result and absurd result, meaning, what did we expect upon executing the test steps and what is the observed results after executing the steps from above. So what is the, what is different from the expected result? A defect written like this is clear. If I was a programmer and received such a defect, I would have no complaints. It is well-described, but provides all the necessary and expected data at the same time. The next week you should update is the priority. In this case, I would give it the highest priority. Of course, the customer cannot login. In the environment field. We will impose demo environment, however, of course, it can be an SAT or UAT as well, depending on which environment you are expecting, experiencing the issue. As a good practice, you should always try to attach some kind of test evidence even to the defect report. Of course, this can be as short as well as video or maybe a crash log from the application. This helps, of course, resolve the issue as well as quickly understand what is the problem. Next field is the assignee. Normally you would put here in there the person assigning further these defects or the programmer directory. Press Create and the defect is created. This is the final result. Of course, please keep in mind that the fields you are seeing here might defer. Those fields are fully configurable and may differ from project to project, from company to company. As you can see here, we are seeing the field priority. However, there is no field severity. Again, this is a configurable fields. So it's up to the Jira admin, project admin to add or remove those fields from the defect reporting page. Here is our final result. Good description straight to the point, but also including all the necessary information. So again, umbrella description steps to reproduce, reproduction rate, expected result, and observed results. Those are the bare minimum of a successful defect reports. And you should always try to input, atleast those sections, at least this information into your defect report. Do not forget about attaching some screenshots, video, maybe some logs. It will always help with fixing the defect. This is the end of our lecture on how to write a defect. Please remember, of course, the more complicated the defect gets, the longer the defect report will be. In this example, I focused on a simple defect to describe, just to give you an idea of the sections in the bug report, defect report that needs to be present. Of course, and complex defect can have 20, 25 steps, for example, direct production steps, as well as more complicated description. See you in the next lecture. 12. How to write a test case: Hello and welcome to our next lecture. In this lecture, we are going to look at how to write software test scripts. Test case. Again, a test case, a test script is our guideline describing on how to execute a test to test a single particular functionality requirement. For this demonstration purposes, I amusing demonstration environment of the test flow. Test flow is JIRA plug-in in order to write as well as execute test scripts. However, this is just one of many existing tools in order to write test cases as well as execute them. It can be done in test flow, it can be done in their fear. It can be done in HP ALM as well. Depending on the company, you can be even writing test scripts in a simple Excel spreadsheet. I will be doing this using test flow demo environment. However, please remember that this is just an example and the main thing you should focus on is the test script itself, because the key points will remain exactly the same regardless on the application or plugin. She will be using in the end to create this test script to execute those test scripts. So let's access the demo and let me show you how our basic test scripts that looks like. Let's access the project backlog. And let's imagine we have an active test plan. We would like to add a new test scripts. In this test plan. As you can see, we have already existing other test scripts. Let's imagine you are a software tester and you are joining our team, which already has software testers. As you can see. In this case, you would see that other testers are already working on this particular test plan. Test plan is meant to gather all the single test clips relating to testing. One bigger release, one bigger built, or maybe one bigger application. In a test plan, there will be many, many single test scripts. In this case, we are looking at scripts related to testing some new Chrome build version of a plug-in. Probably. As you can see, a test plan below has visible test scripts. Each test script, as you can see, has a clearly marked status. So in this case, all of them are past. There were no failed test clicks. And at the top you can see the test plan progress overall. Now let's imagine that we would like to add one more test script to these existing test plan. Let's imagine again that we would like to add the test script for. Login screen as this is an uneasy and shortest example. And afterwards added to this test lamp. Again, let's use the Jira create function. And here we'll be creating a test case template. A test case template is kind of a template for the test case. Later on. Let's start again by writing a short summary of the test script that we will be writing. So here we'll say from login positive path, the summer is short, yet immediately shows what the test script should be about. You can add a table. A table will be a visual representation and easy to read. We can start by the most important information. So the environment of the test script where it will be executed, in this case, the demo environment. Next important thing can be the test script description. It will be a brief, short, yet to the point description of the test script. If someone accesses our test clipped, they are able to immediately understand what the test is about without reading, for example, AT test steps. The next column can be the test script objective. Here we are describing what is the objective of this test script. What is the expected results after executing this particular test script? In our case, it will be that the customer is logged in into his account after, of course, providing the username and password for an existing customer. Next important field will be the prerequisites Fields, credit quizzes, our test data, or some particular conditions that need to be met before we can start the test execution. So before you start the first step, before you start executing the first step of the test script, you need to either acquire or met all the conditions written in the prerequisite section. In our case, of course, we need to make sure that the test user has access to the environment. Often, a test environment will have a firewall, some particular login password just to access the test environment. This needs to be known to the test username. Of course, we can enumerate them. The next prerequisite for this test script will be to have the correct existing user, data, customer, login, and password. So as you can see now, the prerequisite column assures that if another tester is executing this particular test script that we are writing for this tester even begins to execute step number 1. They will need to prepare torre prerequisites. So number one, being able to access our environment, test environment, and number two, test data for an existing customer. The next field is priority. However, please remember that Jira is highly configurable, meaning you might see different fields in your company, in different fields in your project. Now let's move to adding tests steps. Of course, again, there are different test script plug-ins, test script applications. However, the core things like summary description and test steps along priority probably will be present across different test applications, test plugins, whether it is JIRA, HPA, LM, Zephyr on or some other tool. Now let me quickly fast-forward the process of writing down the test steps. And in a moment, we will go over the test steps. Now let's look at the test steps. As you can see, we have not a lot of tests steps, just seven however, again, please remember that the number of steps will differ from test crypto test script. If like in this login case, the test is fairly short and straightforward, the number of test steps will be short. However, there might be also test scripts that are extremely complicated. And for example, consists of 30 or 40 or more test steps. As a general rule, please remember to write the test steps as detailed as possible and follow the general flow of the application. So not to skip any vital parts of the test script execution. As you can see, we are writing down some steps that might be obvious, like to open browser. However, again, please try to be as much precise as possible in writing a test script along its steps. Here, as you can see in step number two, we are mentioning the prerequisite section. This is kind of a fail-safe if somehow the tested executing this test script jumps immediately to test execution. Well, this step is meant to kind of flag signal that there is a prerequisite section. And then the tester needs to prepare some test data. In this test scripts. As you can see, we are accessing our testing environment. We are logging in. We are accessing the test environment, whether by inputting a password on connected maybe 12 VPN or internal company network and are greeted with a login screen in focus, we are inputting again from the prerequisite section. As you can see, it's important to mention in the steps to which prerequisites we are referring. We are inputting our username, password and pressing the login button, expecting that, as you can see, user account is accessed after the successful test. We are closing the browser, and the browser is closed. As step number six is validating the most important part of our tests. It is a great place to also take a screenshot or take a video and in this step, Insert test evidence. As you can see, there is also a requirement field enabling us to link the new test script we are creating with our precise JIRA requirement, meaning this test script we'll be covering will be testing our particular requirement. Let's press the Create button. And just like this, you have created our test case template. You can of course, review the test case template, short summary, a good description, along with prerequisites and the steps precise, clear, no matter who is executing the test script, all steps should be clear and easy to follow. Now just as a bonus, Let's go back to the test plan. We have just created a new test script. And let's try to add this new test script to an existing test plan will differ across different test execution applications. However, there will be a similar flow. So you will probably on a test plan, press a button to create or add test scripts. Afterwards, you need to find the test script you have just written. In our case, we named our test script tests from login. Let's just look for a login or Chrome, let's say. And as you can see, we have our test case template. And in order to add it to our active test plan, we just select our test case template plus the Select button. We just need to enable our test plan is a flow of JIRA, nothing towards him. So now again, we should be able to add our test script. Of course, this is tall forest, the peer review of a test scripts. Now we have an active previous test script. We have successfully added our test script to the active test plan. As you can see, the status is not executed. Thus, the whole test plan, percentage, the whole test plan progress has been visually affected. Of course now, any tester is able to execute this test script. It's an active test script. You can mark the steps. Let's assume we've opened calm, but we are unable to access the test. Environmentalist failed it. As you can see, that test script has been executed, it is failed. And again, the test plan reflects current progress. However, the video is about writing a test script scenario. I will not bother you too much with the test plan. Maybe we will touch upon this on some other lecture in the future. So to wrap up our test script creation, again, please referred to the main sections we've covered in this lecture, a short clear summary. It has to be unique so you cannot have the same name as any other test script. And also it should immediately be easy to understand, at least on a high level, what this test script is about, what this test script is testing. What is the test objective of this test script? Just from a simple, somatic, short but precise description, along with all the required prerequisites to execute successfully this test script test objective that we will be validating and the end of the test script execution, as well as, again, clear but short test steps. And this is my recipe for a good script scenario. I hope that you enjoyed it and I will see you in the next lecture. 13. Boundary values: Hello and welcome to our next lecture. You have already learned how to write and basic test scripts scenario. Now, let's focus more on the analysis part. Analyzing specific requirement will give you a better idea and understanding on how many test scripts are needed in order to cover fully specific requirement. But remember, it's you as a tester who in the end, will be responsible to analyze and decide how many test scripts are needed in order to test requirement. Precise analysis is crucial. In that case, we will talk more about analysis in the next lectures. However, let's start in this one by talking about boundary values and how to test them. While creating test scripts scenarios, you will be creating positive and negative test scripts. What are positive and negative test scripts? You might ask positive test scripts, our test scripts that are testing the application in a manner that the application is designed to do, designed to perform and seeing the results. And negative test script, on the other hand, is composed of steps that are not really designed to be used by an our application. And we do not know how the application will handle such an attempt, such a case. Of course, the end-users have their own freewill. So they probably by Miss, either by mistake or internationally, will try to mess with our application in our industry doesn't application was not designed to do so as a good practice, it is important to also test what happens with our application when we execute some steps that our application was not designed to do. This is a negative test script. Now, an important note. Please note that as a good practice, we always execute positive test scripts first, followed by negative test scripts being executed only once. All the positive test strips haven't been passed successfully. Executing a negative test script before positive one can be a problem. If later on during testing the positive, we find defects. Which we mean that basically, once the defect has been fixed, we will need to retest the negative test scripts anyway, basically doing the same work. Again. That is why we always start with a positive test scripts scenario. Now, in order to easily explain how to create testlet scenarios and how to know how many are needed when it comes to boundary values. Let's look at an example. Our example would be a simple application that measures temperature in Celsius. The application measures temperature from 0 Celsius degrees to 99 degrees Celsius. Simple application, and that is our, let's assume only requirement that we want to test. So again, the requirement is that the application should always display correctly the temperature from 0 degrees Celsius, including the 0 up to 99 degrees Celsius, including as well 99. That is our requirement that needs to be tested. Now before we move forward, please take a minute and write on the side, how many in your opinion, tests should we create in order to fully test requirement? How many tests are needed? Well, for this particular requirement, the correct answer is at least five tests. Five different test strips scenarios are needed to at least test this requirement. Now, let's type in into which and how short dose testlets look. Let's start our test scripts creation by creating the positive test scripts. Again, as you remember, positive test scripts scenarios are designed to test our application functionality. Kind of like double-check that the application is doing what it was designed to do. In that case, I would suggest creating free positive test scripts scenarios and they would be as follow. Number 1 would be to test the application by setting the temperature to 0 degrees Celsius and checking whether the application correctly displays 0 as its short, of course, second positive test scripts scenario would be to test the value in the middle. So our application should be working from 0 to 99 degrees Celsius. So I would set the temperature to 50 degrees and check whether the application correctly is placed 50 and works as designed. Positive test case number three would be to set the temperature to 99 degrees and also verify whether the application displays the temperature correctly. Those three positive tests have correctly checked the boundary values, which in our application, our requirement case has been 0 and 99. In other words, those boundary values have been the minimum and maximum value that our application should support. In that case, 0 degrees up to 99, including the grease. So our boundary values have been checked, or at least we have created test scripts for them. Now, testing this requirement would not be completed just yet. We still need negative test scripts scenarios for this particular requirement and those boundary values. So 0 and 99, I would create two negative test scripts scenarios. We're facing boundary values. We need to check and see what happens when we provide the application value that is just outside of our accepted range. In that case, I would create two negative test scripts scenarios. Number 1, negative 2 seeps scenario would set the temperature to minus1. Minus1 is just next to our accepted value 0. And the second negative test strip scenario would set the value to 100 as 100 is the first not accepted value after 99. So by using minus 1100, we are focusing on testing the values next to our minimum and maximum accepted value. What should be the expected results for a negative test scripts, you might ask, well, of course, we do not expect the application to work as usually. So in that case, when we set the temperature to minus one or 100, we do not expect the application to display this number as our application. As per the requirement. We only work from a range of 0 to 99. So both minus 1100 are outside of this application range. However, we cannot expect that a proper error message will be displayed. For example, please set the temperature from 0 to 99. In this way, the application would gracefully handle value outside of the accepted range also. And this is a very important point when it comes to negative testing. We have to always make sure that the application remains stable. In other words, when we provide our temperature of minus one or 100, dedication cannot freeze, not the application cannot also crash. The application must remain stable. And this is it. We have five tests keep scenarios that are covering boundary values for our requirement. And that's basically it. Whenever you have a requirement that needs to be tested by boundary values testing, you should always use a similar approach and create dedicated test scripts for the boundary values testing. Remember both positive and negative. I hope that this introduction into analyzing requirements has been clear and you're now feeling more comfortable when it comes to unbelief knowing and understanding how many test scripts requires and what values should they contain when testing a requirement for different boundary values? Remember, if you have any questions, please do not hesitate to write them in the comment section. I will see you in the next lecture. Bye. 14. Let's talk about SAT: Hello and welcome to our next lecture. In this lecture, we will be moving forward when it comes to analysis of requirements and creating test cases covering specific requirements, it's a good place to mention the SATs. The term SAT stands for system acceptance testing, especially working as an application software tested. You will encounter this term quite often SATs, system acceptance testing is basically a phase of development stage in the development process. However, it is such a broad one and sophisticated that you can be even a dedicated tester only for the sole purpose of conducting SAT. It's in general, a tester and SAT tests covering all the application requirements from the functional specification documentation. And of course afterwards, executing the SAT test scripts, thus validating that the application meets all the requirements from the functional specification document. However, in that case, your job will be to both analyze the functional specification along all of these requirements, as well as create test scripts and afterwards execute those SAT test scripts. Of course, whenever needed, racing defects if the application result differs from the expected result from that functional specification document. In general, requirements into functional specifications are key points for the application defined by business, but also translated into a more technical language by a business analyst. An example of this can be when business says to business analysts that once provided correct data. So username and password, the customer should be logged in to the user account. Business analysts will dig in more deeply and specify which network code should be also in a response of such requests, which requests should be triggered, and also which table in database should be queried for this, as mentioned before, requirements are groped and put together in a document. This document is functional specification. Functional specification will be often updated during development and also share it with the whole development team in order to be transparent. As a tester or SAT tester, functional specification recommend will be kind of your dictionary. Whenever we have any kind of doubt question, this should be the first place that you look for an answer. Functional specification document is an official one and thus shows contain all the most up-to-date application requirements and application data. Just as a side note and maybe a tip from my side. Please remember we are all humans. So when you are reading through their functional specification documentation and maybe selfing. Does not seem right, or the application differs from what you see in the functional specification documentation. However, it seems right in declination and wrong in the documentation. Please do not hesitate to reach out to business analysts who created this document for an SAT tester. Business analyst is one of your closest friends when it comes to development team. And trust me on this, I've had weeks and months where BA was the closest person or the person that I had most conversation with during SAT test script creation and the script analysis. Of course, as mentioned before, then can always happen a situation when there will be a mistake in the functional specification and the, in such cases ba with, of course, thank you for pointing this out and accordingly, correct the mistake, thus releasing new updated functional specification, documentation and validation. Also, there will be times where you will think that there is a mistake. But after stocking with the business analyst ba, they will explain to you that no, no, no, everything is correct and you probably read something wrong or misunderstood. Those cases are also perfectly fine, as in general, BAs also look very closely at the application final quality. Thus, they are really happy that you are asking questions and in general, testing for early the application. So just as a side note, whenever in doubt, even when reading the functional specification recommendation, never hesitate to ask business analyst about this particular part of the documentation, this particular requirement. They will shoot at least be more than happy to help you understand this and clarify whether everything is okay. As in the previous lecture, we already discussed covering requirement with appropriate test cases, both positive and negative. In this lecture, let's focus on another example covering with test cases are requirement diagram. In quite a few requirements in a functional specification, you will encounter diagrams. Diagrams can be either simple like the one that you're seeing now are complex, consisting of many, many, many paths and points. However, diagrams are crucial to understanding and fully testing application. When it comes to writing test scripts for a diagram, it is quite easy. However, of course, if the diagram is huge, this can be a bit more painful, but the approach will be the same. Thus, we are looking now at a simple one, just so you understand the logic behind analyzing and diagram and understanding from this analysis how many test scripts are needed. In this particular case, we are looking at creating three tests scenarios in order to cover this particular diagram with tests, my approach is to start always with the end to end path. In this particular example, the test script would look as follows. Lumped doesn't work, lump plugged in. We answer yes. We go below bulb burned out. We answer no and detests. And with repair lump, this would be our test script number one. So again, we would call lambdas and torque. Lamp plugged in. We would answer yes. Bulb burned out, we would answer no. And repaired lamp would be the end of our test script. Now, as you can see, there are two more paths that needs to be covered. So the test script number two would be Lambda doesn't work. Lamp liked in, we would answer no. And we would move to a new direction and it would be plugging the lamp. This would be testlet number two. But of course, as you can see, there is one model path remaining that we have not yet covered with test scripts. So testlet number 3 would be Lambda doesn't work, lump plugged in. Yes. Bulb burned out. And here we would answer yes. And the end on testlet number 3 would be replaced bulb. I hope this example showed you how to cover a diagram with test scripts scenarios. In other words, all possible routes have to be covered in a test scripts scenario. The same goes here as in general for other test scripts are good practice is not to combine all the tests into one, but separate them. In this case, we will be looking at three different test scripts scenarios and of course not one. For example, lambdas toward clump like Dean know, plugin lamp, then continue lambdas toward clamp like deniers about burnout. In general, it's my advice that it's always better to have more shorter test scripts scenarios. Then to combine them into being big tests containing many different paths, many different requirements. To be honest, it's a terrible idea. One of the examples could be that if you have a defect somewhere along the way, your basically mark this test script as failed while other functionality tested afterwards. And being separate from the defect can in fact be working. So a side note here, kind of a mention. When creating test scripts, please make sure to create short ones and covering only one path, one requirement. Do not create containing several requirements combined of several requirements or several paths. Test scripts, test script should be covered in one path or one requirement. If you have another combination, please do create another test scripts. It will keep things clear, clean, and professional. And this is it for our lecture. I will see you in the next one. 15. Peer review: Hello and welcome back to our next lecture. We are moving along the path of requirements analysis and in general, test scripts creation mostly focused on the SAT. During SAT testing. One of the important steps will be test scripts creation. Here we have a good opportunity to mention another important step, which is peer review. Peer review is basically the process of reviewing your fully finished test scripts scenarios before the SAT execution. As the SAT execution is the formal process, test scripts should not be changed during execution. This means that if you spot a mistake, an error that you made during creation of the test script design for SAT? Well, it will be kind of a big mess, especially if your project is a validated one, then you're in a whole lot of trouble and problems because of course, during SAT, you have to close, follow the steps in the test script. And if there is a step missing or a step that, well, you cannot really executed because maybe there is something wrong. There is application changed. You haven't updated this. Well, again, during when you when you spotted this during the city execution, well, this would be a problem as you will need to start the formal procedure of changing this test script. And this will involve a lot of people who will ask you questions like, why haven't updated this before, and why a peer review has not picked this up? Yes, peer review. So whenever creating the SAT test scripts, once you are ready with the test script, you wrote it down, Your looked at it 10 times, and you are sure that this test script is ready for the SAT execution. That is the time for a peer review. Peer review will involve you as an outdoor, asking another teammate, another tester colleague, to fully review this test script and give you feedback. Petri view of a test script is very similar to our pull requests video. Basically, you are asking your colleague for a review of your creation. And the colleague will review, commenting whatever something is needed. At the end, the reviewer will either approve or disapprove the review in question. So let's go back to our testing. Let's imagine that you are there an SAT test her. And you have created SAT test script. You have sticks to all the good practices you have flowed prerequisites. You have lot of detailed test scripts. Of course, your test script is only covering a specific one requirement. You have read the steps as well as expected results for each one of them. And you are completely satisfied with how it looks. You remember to ask for test evidence whenever needed. The test script looks done from your site. Now it's time to involve another tester. In this script creation process. You will most likely reach out to one of the other testers on the project and ask them for reviewing this test script. You will either give them the name of the test script or send them the link directly, maybe for Jira or Iran and ask for a review. Once the peer reviewer is done, they will apply comments whenever needed. This can be, for example, applies directly to particular steps. For example, your colleague can comment on step number five saying that it's not really clear where he needs to press login button because you have kind of skipped some important details or maybe comment step number 12, saying that in his opinion, SUR verifying our requirement here, that test evidence is needed for this particular step. However, you have not asked for it to be taken. All such comments are valid and you as an outdoor shot, apply them to your test script and then is from step number one. So you have to ask again, your peer reviewer to review again your test script once you have applied the changes, of course, not all comments from a peer reviewer will always be right. So you are in the right TO disputes anything that in your opinion doesn't make sense. So if the test step is crystal clear, but some reviewer says that you need to write in more details because he doesn't know what to do. But again, We've all the honesty. You think that is crystal clear and nothing more needs to be done. So you can comment saying this, and basically disregard such comments. And basically once your applied all the necessary changes, your ask the peer reviewer again for a review and you received an approved for this review. Your test script is ready for SAT test script can be added to the SAT test plan and our eight official SAT execution. This as an author gives you, well a peace of mind that someone else, some other tester has fully and in detail reviewed your test script and also approved it, also verifying that it looks ready for execution. Now let's move on to a peer review, but from a visual point of view. And here we will have many, many more comments. In this case, we will imagine that we are the colleague being asked to review our SAT test script. Step number one, while reviewing someone else's SAT script, would be to look into the mentioned before functional specification documentation, in particular, regarding this test. He will be reviewing, get yourself familiar with the requirement that this script is covering the discrete. Discrete is testing and read more about it in the functional specification documentation so that you are more familiar in general with the requirement that is being tested by this test script in review. Before we actually begin reviewing the test script, there is one crucial points that you need to remember. Actually, many testers forget about this good practice or this crucial point. So I would like you to make a mental note and remember this wherever you are reviewing SAT test script. And here it comes. While reviewing SAT test script, you are reviewing the content of this test script. By no means are you executing this test script on an active test application? I know it's very simple, but it's crucial to understand this. Peer-review. Foot absolutely not be a functional one, should not be executed on an application. Everything you do as a reviewer, you are doing this on paper or of course on computer. But nowhere should you have an opened application and be trying to go step after step, literally executing this test clip. Please remember this as this is crucial by executing the test script. You are jumping a few stages ahead. Because after the SAT test scripts are approved, reviewed, and approved, added to SAT test plan before the official SAT will start. And that will be under Iran. For those test scripts. That Iran is execution of those test scripts, however, not an official one. So they will be executed before the official SAT testing phase. However, by doing so while doing the peer review, you are unnaturally extending the time needed for a peer review, as well as completely missing the process. So again, I know this is a 100 gets on my nerves because you can be waiting 34 times longer for a review and someone might be doing completely unnecessary testing. Please do not execute test scripts while performing period of your focus on the text. Focus on the contents of the test script. But sleeved application alone do not execute the test script. Okay, So actually what you should review in a test script, SAT tests, click number one would be prerequisites and making sure that they are connected to the later on steps. An example of this would be in the prerequisite section at the top, having detailed existing user login and passwords and afterwards seeing the reference to active user login and password in the next steps of the test script, checking login functionality. The same goes for a test website. If you're a step number one is to open Chrome browser and step number two is to access test website. Please make sure that this test website is specified in the prerequisites. For example, www test However, you cannot approve a test script when there is a reference to our test data that is not well described in the prerequisites, that is not present in the prerequisites. Remember, as always, good practice as Castells, we cannot assume anything. You are not sure who's going to be executing this test script. You cannot assume that they will know the test bank, the bank test site, or the whatever application sports betting test website. Also remember that the address of a test website can change. So let's not assume anything. Make sure that whatever is referenced in the steps the steps later on is present in the prerequisite. Section. Number 2 would be a logic. Makes sure that the steps are well logical. Let me give you an example. Imagine that you are reviewing a test scripts scenario for SAT, where you see step 1, open Chrome browser. Browser is open step to access test site to site from the prerequisite, okay? To say the success. Number 3, check customer balance and the expected result is balanced, is displayed. Well, it doesn't seem right, does it? Because in the prerequisites, you have the existing customer login and the password. And here somehow, we are already logged in and we are checking the customer bands and whether it is displayed or not. Well, it doesn't make sense because probably we skipped some steps as some steps involving login process. In that case, pointed out comment on those steps that it should be more detailed and that current logic is, well, it doesn't make sense. This whole login process is skipped. Makes sure that the outdoor ads missing steps in general, makes sure that the steps are as detailed as possible. And in my opinion, and professional advice, more steps, more detailed steps, It's always a better approach that less and condense. One other thing that you will see us testis, is that some software testers like to condense test steps. Of course, is a bad idea. It's a bad practice, but some people do this. An example would be a test script where as you go again, you open a browser, your access the test banking page. You input login into the username shield. You input password into the password field, you click the login button. And afterwards you check that the balance is displayed for the customer and of course that the customer is successfully logged in. Well, I wasn't counting, but this should be probably like seven or eight steps. Well, what I mean by condensed steps is that you will see test scripts and people are writing test scripts that we literally put all of those things into step one. So your test script will have Swan step and all of this will be in the same test step. Of course it's a bad idea because imagine that you want to report a defect. Now. Imagine that the, well, well, exactly like even if you think about this, a moment, like if if you fail this test step, like what was the problem? Was the customer not logged in? Was there a network error? Was the Boston displayed maybe the user name She's was not displayed, the login button missing. Well, it gets it gets crazy quickly. So if you ever see a test, the test case like this, fortunately, while working on the SATs, It's less and less likely, however, skipping dare say this part in general, whenever you are doing a review and see such a test case, really comment on this. Ask for separation, ask for creating 78 steps instead of this one condensed as is, as this is a very, very bad idea. Quickly, another thing would be expected result. Whenever there is a test case, you always see step and expected result. Another thing that commonly tested us do is put into the expected results. My hated words, application behaves as expected. Please do not do this. Let's go to some example. You cannot ask someone to login to a banking application. And in the expected results, import application behaves as expected because this is neither here nor there. What happens if there is a banner? What happens if a banner should be there but it's missing. It's a terrible idea if you see this comment and ask for a clear expected results. For example, customer is logged in into their bank account and a welcome banner is displayed. Expected results should always be clear and detailed. As a software tester, you should not be speculating what should be the end result. You should not be assuming anything. You should know exactly what you are expecting to see and what you are testing. Next thing on my list would be test evidence attachments, especially in the SAT. Remember this point? Whenever a step, actor script step is testing a requirement, it has to have a mandatory tests, evidence. Let's imagine that we are again testing our from the previous example application that measures temperature from 0 to 99. If you have the three positive scenarios, test scripts scenarios when you send the temperatures to 0, 50 and 1909. And in those testing scenarios, you have a step when you execute the measurement and the expected result is application displayed 0 degrees or application displayed 15, 99 degrees. This is the step that validates, that verifies the requirement. The single-step, of course, at the end of the test. The same goes for the test evidence. This particular test step must have a test evidence. So you can write also in description, please take a screenshot, please take a video, whatever you want. But in SAT, for a test step that validates a requirement, it's mandatory to ask for a test evidence. Because otherwise the tester executing this SAT can be tired. Forget to take tests evidence. Sat is a formal process. Remember, you have to have test evidence for each requirement. And my last note will be to avoid, and of course, also high Writing 1 to avoid hard-coded data, test data. What does it mean? Let's use a very simple example, banking test site login page. You need to use a username, password. Then press login and validate whether the user has successfully logged in. Well, username and password for an existing customer that will be used to execute this test script shows not be inserted into the steps if the input username and passwords are step number 3 and 4, well, they should literally say this. Input, the username from prerequisites to, let's say, and password would be inputted password from prerequisite number three. And then the tester that is executing this testlet, we'll just look at the prerequisites and see, okay, the password is baba blah, and the username is John the 23rd, 2020. He would have the test data. However, the test data will not be hard-coded to the test script step. A very bad practice. And the one that you need to pay attention to is if someone put into step three, the username, input username, Johnny bla, bla, bla 20 into the username field, as well as in step four, if someone put input password 12345678 into the password field, this is a bad thing and bad practice and this should be picked up while executing a peer. This is a bad practice because imagine what happens when the test data changes. Well, you have to look in every step and imagine that taste test case that has 60, 70 test steps. You have to look in every particular step and change those hard-coded test data. But if you are using not hard-coded data parameters, Let's say that you named your pedometer. Use username and password. You'll change only the test data in one place in credit quizzes in at the top of the page, in a clearly and easily accessible place. You will be sure that the test data has been fully updated and that the test script is using most up-to-date test data. So watch out for this hard-coded test data. And this is it for my points and suggestions when it comes to reviewing someone else's SAT script. Of course, the same applies to you as a reviewer. When you comment with all your remarks, you need to give the outdoors sometime to apply those, and then he will come back to you for a second. Review. Take a look again at the script. If you are satisfied with all the points, mark the test script as approved. If whatever still needs some work. Comment again, ask again for some changes from the outer. Remember, you are also a very important piece in the development cycle when you give the proof. And often this can mean that you will be tested executing this test script when the official SAT cycle comes. So make sure that this test script is up to standards, has the highest standards and only then give an approved on it and approve this testlet. This is it for our today's lecture. I hope you enjoyed this and see you as always in the next one. 16. Different test types: Hello and welcome to our next lecture. In this lecture, we are going to go through the different test types and what exactly to the imine. We have already discussed SATs. But we're going to cover more than different tests types in this lecture. Let's begin. As testers, we will encounter many different task types. It is important to understand what each one of them means and when should they be executed. Thus, type number 1, smoke test. Smoke tests should be done at the beginning of testing a new version, a new build, a new application. Functors by design, should be a very quick test. The main purpose of running a smoke test isn't determining that the new version of the application is functional enough that it can support further, more extensive testing. Smoke tests are designed to catch any defects that will, in fact blog and a further testing, an example of a smoke test fails tests that would prevent any further more advanced testing is a video game that crushes every time on the first screen you see upon starting the game, when the screen has a text saying press, please press the Start button. You press the start button, the controller, and how application crashes, whole video game crashes. And this is something that should be picked up on a smoke test and is in fact blocking any other testing. In such case the smoke test is failed and there is no point of doing any further testing on this version of the application. In such a cases, the Halting can roll back to the previous version of the application and continue testing once the new version of the application has been deployed containing a fix for this smoke test defect. That's type number 2. Defect, greatest. Defect retest is retest of reported defect retesting the issue where we had a video game new build failing every time upon pressing the start button on the screen, saying, please press the Start button to begin. Unittest of course, occurs once the report that defect is fixed by a programmer and new faction of the application is deployed. Once the defect has been retested, it can be either retested as fixed or still requiring some work. So testing can be either successful or unsuccessful. If the application, despite the fixed attempt, keeps on crashing while pressing the start button on the video game. Well, the defect sweetest is a failure. It has not been successful, and the programmer needs to put in some more work and analysis into this one. If the application, if their video game now lunches correctly, proceeds to the next screens. The defect retest has been successful type of testing. Number three. Regression testing. Regression testing will occur usually before the major software application release. Before a new version is released, testing team will execute a regression testing. Regression testing aims at testing the parts, components of the application that have not been directly worked on during the new vection, new application version development, the regression testing main focus is to ensure that while the development team has been working on specific parts of the application, under the parts that have not been worked directly on, remained stable and unaffected by other changes in application. An example would be if a banking application has a new customer registration as well as existing customer login. And during this new version development, the team has focused only on existing customer login experience, but have not touched at all new customer registration. Well, a regression tests would check that the new customer can still successfully register and the flow has not been interrupted or broken. Next type of testing, exploratory testing, black-box testing, exploratory testing, black-box testing is executed when the test does not have the source code of the application. But as well that does not have functional specification documentation. So in other words, the tester does not really know all the requirements of the application nor all the behavior of the application. An example, if we had the application from the previous example measuring the temperature from 0 to 99, but we did not have a functional specification stating in a requirement that the application will measure only from 0 to 99, then if we'll use the application, we would not really be sure what is the range of working measurements. So whether it's 010020, maybe minus 10, 20, this would be exploratory testing. We would be literally exploring the application without precisely knowing what to expect. Such a testing is great for finding defects, bugs from an end-user point of view. Because, well, the end-user will also not have the full specification of an application. So testers performing exploratory testing are kind of assuming a role of an end-user and trying different things that are potentially end user can try as well. If a defect arises, the exploratory tester will report it. And afterwards, another person familiar with the functional specification will review whether it is a valid bug defect or maybe something that is as designed by the application invitation, application requirements. Next type of testing, white-box testing. White-box testing is a unique testing type because it involves giving a tester full access to the application code repository. Test there is free to browse any technical classes functions that the tester wishes and of course tells the application accordingly. So not only reading through the documentation, but also looking directly into the code, into our function. Maybe the tester can come up with test cases with tests. Next type of tests are the test case based tests during SAT, SAT system acceptance testing, we are creating test scripts based purely on the functional specification and the requirements that are within this document. So this type of tests, we'll focus only on the requirements and of course, positive negative test case around them. However, it will not involve an exploratory where you are just free to go and try whatever in the application. You will have clearly defined number of test cases. And during the SAT phase, you will focus on executing all of those test cases. Next type of tests is performance testing. This is more skilled, more technical type of tests. As performance tests focus mostly on very small parts of the application. And whether via front-end or back-end, they test small transitions from one another. So for example, this can be a transition from one screen to another, or maybe the whole registration process done via backend services. And performance testing measures that time execution, the time needed to perform this particular part of the application, this path and application. An example would be a back-end. So using services, no front-end, no browser on the backend services, new customer registration, and measuring all of the time needed to proceed from the start to the end. For example, it would be 20 seconds. This would be our benchmark. And afterwards, every time a new version of the application is released, you would around those performance tests and see how now on the new version of the application, these, the same tests looks like whether it's faster, whether it's slower and slower than y. Next type of tests, api testing, API testing, testing of the application services. It's a technical part of testing. We're testing purely on the back-end side, similar to the performance tests, it will involve a lot of small quick tests. However, here we will be specifying precise parameters, the body of our requests, and validating the response. Of course, the tests can be both positive and negative. The advantage of API testing is that all of those back-end tests are extremely quick to execute. And any failed tests points quickly to our culprit and let us reported the defect less the programmers gets on fixing this without the need to manually go through the front-end, manually go through the new customer registration, for example. And the last type of tests that I want to mention is automated smoke tests. As mentioned before, smoke tests are essential to even conclude if the new virtual application is ready for testing or whether there is a critical bug defect that needs to be fixed before we as a testing can start testing fully the application, automated smoke tests are basically the same thing, but as the name suggests, well, automated. The advantage here is that of course, apart from the test being automated, tests that is being able to trigger those tests. And the tests execute automatically while we, as testers are working on something else. The other advantage is that of course, we can connect those automated smoke test told the continuous delivery or CI pipeline and set up the environment in such a way that if the programmers push a new version of the application, well, then, immediately our smoke test would kickoff, would launch. We can really experiment a lot with their configuration, even in such way that if the smoke tests are failed, then the application would roll back automatically to the previous version. Anything basically that fails, our smoke test would not get deployed and the programmers would have an immediate feedback, for example, from Tim city. And this is it for today's lecture. I hope you enjoyed it. I hope to see you in the next one. Bye. 17. SAT vs UAT: Hello and welcome back to our next lecture. In this lecture, we are going to take a look at UAT testing. In particular, we are going to talk about UAT testing in general, but also how it compares to the SAT testing. Let's begin. First of all, let's start by the definition of UAT. As you already learned, SAT stands for system acceptance testing and is a crucial part of application lifecycle development in which we as testers, validate that the application is in fact reflecting the requirements from the functional specification document. Now let's move to UAT testing. Uat testing stands for user acceptance testing. Uat phase, or user acceptance testing occurs after the SAT, the system acceptance testing is completed. This is very important to understand that SAT testing is done before the UAT testing begins. In other words, UAT testing begins once the SAT is completed. So we asked SAT test tells me the green light. Go ahead that we have tested validated application. And we are saying that application is in fact corresponding to all the requirements from the functional specification documentation and there are no issues and known defects present. Another key point of UAT testing is that it is, as the name suggests, mostly done by the users. So in that case, business users and business users will execute scenarios, test scenarios in order to validate that what they have initially requested to be implemented in the application. And afterwards, BA business analyst has written it down into requirements that we as SAT test status have afterwards been working on with our test scripts. Yet again, the business now we'll simply validate that their, their expectations have been in fact implemented in the application. Please note that this is done by business users. Often those test cases will be less technical that the SAT ones. Some of the UAT test cases, UAT test cycle, we'll focus mostly on validating what is or what can be checked in the application itself. And either not test at all or in a very limited scope, more technical test cases, for example, on the database level, requests or in the application logs itself. Now that you understand what UAT stands for and what UAT testing involves, Let's move on to comparing. Sats, UAT testing. What are the differences and good practices associated with both? First of all, let's begin by good practice of test execution when it comes to UAT and SAT, of course, in general, the idea is that a dedicated tester or testing will execute SATs and afterwards, business users will do all the UAT testing. However, in real life, business is either partially testing UAT or having dedicated test teams only for UAT testing. So in other words, business is not always. Unfortunately, it's not always involved in the full UAT testing. However, regardless, if the business is doing hallway testing or he's using some other tests to help with that initiative. That is one crucial principle that should be followed. And that is SAT and UAT test cases should be executed by different people tested who are executing SAT test cases should not be executing UAT test cases. This has everything to do with the principle that one person can execute a given test, follow a given step, a different way than the other one. So by executing SAT by one person on one thing and UAT by another one, we are kind of getting this double verification or a second layer of people checking the given a requirement and also of course, looking at potential issues, defects. The second is very similar to the first one, for sure It's related. But while at the first one focused on the execution, the second will focus mainly on test script creation. Sat test scripts and UAT. Test scripts should be not only created by different persons, different testers, different people. So SATs test scripts will be created by given person, but another person should be creating the UAT test scripts. However, this point goes even farther. As mentioned before, UAT testing cycle occurs only once. Sat test cycle is already done. And of course, the UAT testers are using the same functional specification documentation as the SAT testers. In other words, both SAT tests and UAT tests will be checking the same application requirements. There are no specific documents for UAT testers. They are looking at validating. They are looking at testing the same requirements that an SAT team does. However, if there's a T testing cycle happens at first and UAT follows, this means that the SAT test scripts will be ready first. Uat can be done a little bit later, and this can be tempting even if a UAT test script creating person is a different one from the SAT test script creating person. It can be tempting to kind of ask for the already analyzed, already written down test scripts just to have a log, just to kind of copy may be some test cases because yes, in fact, many UAT test cases will be checking the same thing as the SAT test cases. Because again, they are based on the same functional specification documentation and on the same requirements. So many UAT test cases will be checking the same thing as already written SAT test cases, however. And here is the key point. Dos test script should never be shared. It comes down to the same practice of us with execution UAT tester creating here AT test scripts while looking at a requirement, might arrive the test script idle bit differently. And thus covering some very important step that by some chance might not be in the SAT tests creep. This is why UAT test scripts should not be copied from SAT test script. You will get us there should not even be looking at the SAT test scripts because even looking at the list can give them an idea of what should be tested and they should not be getting this idea from the SAT test scripts repository. They should be getting this idea from the functional specification and from the requirements least, they should be doing the analysis and they should be the one deciding how many tests bits are needed to cover those requirements. I have been working in some very secure oriented companies and you might encounter even such limitations where UAT testers and SAT testers will have their work accounts set up in such a way that privileges will not allow them to see each other's repositories. Meaning if a UAT testers even tries to access the SAT test scripts repository, well, there will be access denied and the same the other way, if by some chances, SAT tester wants to take a look at UAT test scripts. Well, there might be a situation when the privileges are set up in such way that the access will be denied. This is rare. Most companies don't do this. But you might encounter situations when literary. The two testers from UAT and the city will not be able to see each other's test scripts by privileges, restrictions. So the key points to remember are that we should separate as much SAT and UAT testing, Both when it comes to test cases, test scripts execution, as well as testlet preparation. In general, test plan preparation, they should be limited and separated as possible. And this is all done in order to cover as much as possible and make sure that both tests tell us both teams are doing their best to cover all the requirements and test Farley. And my last remark is that having this in mind, it does not mean that the SAT and UAT testers or teams should not cooperate with each other. However, on the contrary, many times working as an SAT test, you will be assisting the UAT testing or UAT business users. Because as mentioned before, often they will be less technical. So for example, if there is a test cases requiring an existing customer already present in the database and set up in a certain way with certain privileges that can only be done by inserting into the database. Well, UAT users might find it difficult or have even no idea how to prepare such a test data. And this is perfect opportunity to cooperate by creating test data if we already have ready scripts for our SAT testing. Remember, those are two different things. We should not be cooperating with the UAT team when it comes to test script creation or execution. However, we should fully cooperate when it comes to, for example, preparing test case data, test data. And this is it for today's lecture. I hope you learn the differences and good practices when it comes to SAT and UAT testing. See you in the next lecture. 18. Expand knowledge as a Software Tester: Hello and welcome to our next lecture. When we are going to take a look at how we test status can expand our knowledge. Software tester is one of those roles that require constant self-development and expanding our knowledge. Working as a software tester means that you will kind of also be required to be up-to-date with the newest technology. Of course, technology doesn't stop. We are seeing huge leaps forward when it comes to technology. On yearly basis, new model of hardware is significantly different from the previous years. Thus, we are software testers need to constantly stay on top of the game, on top of the newest technology. As often as software testers, we are going to be seeing the data. The three released, either hardware or software. So in other words, we need to be able to operate the new hardware or new software before the customer gas. Due to this, we need to stay on top of our game when it comes to knowledge and new skills. So how software tester can regularly expand the knowledge as well as learn new skills. Let's be in possibility number 1, boot camps due to its popularity in recent years. For sure you have either heard or seen an advertisement for a local bootcamp. In general, the idea behind a bootcamp is to have a small group of students and group that meets regularly, most often on all week days for several hours. And they, the course is intense and you are meeting every single working week day for many hours to study together. There are many schools. And also when it comes to testing, it can be either bootcamp for a software tester or functional tester, Manuel tester. So attested that will be manually testing, for example, SAT UAT, writing test cases, writing test scripts, executing test scripts, writing defects. So in other words, more Manuel bootcamp regarding testing. Although it can be also more technical, bootcamp automation tester, security tests, for example, for penetration testing. Or in general for programming. For example, Java Bootcamp or Python bootcamp. There are many, many schools offering boot camps nowadays. They are located all around the world, probably also online. So there are many options to choose from. However, personally, I am not a huge fan of recommending those, especially for new joint heirs, when it comes to the IT world. New software testers, for example. Why am I against input comes for new testers? Well. When a bootcamp is done, right? Of course, it has huge advantages. You will be in a high paced environment, simulating work day workweek, where you will be learning quickly, your future neural auto, quickly gaining new skills, for example, when it comes to programming such boot camps, in my opinion, I haven't grade, however, in my personal experience and I have been observing this particular part of the market closely. There are many boot camps that do not offer this kind of quality and have men in downsides. One of which is price. What crimes have been growing more precisely. And nowadays, the amount of money asked for, for example, bootcamp to become a software tester, a manual tester. Well, it's just ridiculous. Like nowadays many boot camps. At least technical boot camps, for example, for a tester, automation tester. Of course Programming. Well, when you look at the price, stock is not only a joke, but also you will see as a regular think now, payment plans next to the price. So many students are not able to pay the price of the bootcamp at once and need to result in installment payments in order to cover the cost of the bootcamp. Well, this just shows you how expensive boot camps have become. The next thing that I don't think works well with men and boot camps is that apart from this huge, ridiculous price, the cost of the bootcamp, well, the quality will just not follow along. I personally have taken several boot camps. However. I have also spoken with many of my colleagues and also interviewed many candidates for attesting role that have successfully completed bootcamp. And here is the problem. As I said, the cost of the bootcamp does not equal its quality. There are many boot camps that will have candidates with different IT skills mix in the same group. However, the instructor will just not be able to cope with this, to deal with this situation correctly. There will be students that will follow along, but other students might, for example, get lost or get confused, need additional help to understand a specific topic. For example, when you start programming, the whole idea of classes of functions of how the application works. For example, me personally, it took me several months to get a hold. They get a grip on. Only in the ideas of how everything is connected when it comes to programming, especially when your application grows, your code growth, how all this works? So again, there will be students that will get overwhelmed, overwhelmed with the new information and we need assistance. However, many of the boot camps have clearly designed schedule that needs to be followed. And often instructors lack, lack the human touch. And we'll just move along with the course material. Of course. I don't need to tell you that if you do not understand something, the course just moves along, then you will not understand the other part of the course and you'll get completely overwhelmed. Especially when we're talking about technical bootcamp programming or maybe also penetration testing or any other kind of automation and technical testing. What if you don't understand the fundamentals, then you will not follow along the rest of the course. So basically, if you get lost and the teacher is not willing to help you understand those topics that you are missing, that you have not really getting. Then such a bootcamp is like probably in the middle or even at the beginning. Waste of time and waste of money costs. Well, it won't really do you any good if you will, get lost and not receive the help needed. Also another downside of boot counts apart from cost and sometimes the lack of quality is the fact that, well, most of the boot camps are really focused on the timing. I really condensed when it comes to learning. So they will be, for example, for three weeks period of time, and they will happen from Monday to Friday, eight hours per day. Well, of course, we are all adults and we need to have a job in order to pay the bills. So this means that most of us, unfortunately, are not able to really sign up for a free week bootcamp and attend Monday to Friday eight hours per day. Due to this. As I said before, boot camps would not be the first thing that I would recommend for someone in software testing. Of course, it can be a great way to expand your knowledge. However, you need to really do your homework when it comes to the school or to the company that will be executing and performing this course, teaching cure. You need to check that they are trustworthy. And also, well, this is a huge burden when it comes to the finances. So you need to be careful when it comes to the price tag, as well as the U3 time to attend this course for the possibility number 2, when it comes to expanding your knowledge. And this is by far my favorite online courses. Nowadays. Online courses as well have been steadily gaining popularity. Why I do recommend. Online courses to people wanting to expand their knowledge in software testing. Well, number 1, costs. In general, the cost of a bootcamp that Sosa costs of our online course is nowhere to be compared. You still will find on a courses that do not really offer the value when you compare it to the price tag. However, in general, as a rule, only courses, I are way, way, way cheaper than bootcamp because of course, they are not done in person. You are not actually attending live course. So thus the price tag comes down. Next, adventures of online courses. And for me this is a very important one. Online courses are self-paced. This is extremely important point for me, as well as for probably many, many people need to stay longer at work today. No problem. You can resume the course later this evening. You plan on studying three hours, but your child is sick and needs your immediate attention. No problem. You can pick up today's lesson, tomorrow and make up for it by doing two lessons at once. Maybe you are commuting to work and it takes you one hour of embodying commute time. So now, instead of watching funny cat video, you can spend one hour of commute time to actually learn and execute today's lecture, Today's learning plan by cutting the human real-life interaction. When comparing an online course to a bootcamp, you are gaining the flexibility of being able to study whenever it is convenient to you. There is no set start and end time of a particular lecture. You can pick it up whenever you have time, you can easily reschedule. It's up to you. You are setting the pace on course. You are setting the pace in which you are learning, in which well studying, of course, another advantage of online courses is, and not forget, there is still a lot of great content absolutely, for free on the Internet nowadays. Mostly those will be way, way shorter. Courses may be focused on one particular area instead of the hollow one. So you will, for example, have a 30 minute lecture. However, it will be completely for free and can still offer great value, great knowledge. Idea number three, to extend your knowledge and learn new skills is to join a meetup. Meetup, of course, is hosted by the website meetup. However, the general idea is to join a group with a specific interests. Whether it's security testing, penetration testing, automation, software testing, SATs you 80's nowadays that are tons and tons of meetup groups. And the best part is that they are regional based. So you can easily find a group of enthusiasts on a specific topic that is located in your area. The general idea behind a meetup is that members of this group will meet in often public places like restaurants or maybe a small conference room. And the meeting will be most often completely for free as there is no one making money. This is just a group of enthusiasts sharing together knowledge, sharing together ideas. This is a great place to either join a lecture. Many of my friends have conducted on the meetups lectures on specific single topic. So it's a great opportunity for you if that is something you want to learn on a specific topic. For example, spring when it comes to Java. And such a meetup can also be a great opportunity for you to meet new people, make new connections, and do it completely for free. My last point when it comes to expanding your knowledge is to not dismiss or maybe even suggest in company knowledge sharing sessions if you are already working. For example, as a software tester in an IT company, do not forget about the talent that is already surrounding your other and accompany. This can be a great opportunity to increase your knowledge as well as share your own knowledge in order to help some other colleagues better understand specific topic that you already mastered. Companies will often encouraged such sessions by providing you the wrong completely for free, of course, in order to perform such knowledge sharing session as the company is only in gaining. Because of course, all the participants attending this session will be better employees at the end of this session as they will learn something new. This is a great opportunity for you to expand your knowledge. Create, for example, sharing sessions when it comes to software testing, expand your, for example, SAT team's knowledge and understanding of good practices. But also, you can ask, for example, a Java programmer or a Python programmer to share his knowledge of the basics. So you better understand automation testing. Or maybe you have a database engineer that could do a quick session when it comes to basic or maybe more advanced secure queries. So you can use it in an everyday software testing. This is the end of our lecture about expanding your knowledge and a software tester. I hope I gave you some ideas on how to improve as a software tester. See you in the next lecture. 19. Common tester everyday mistakes: Hello and welcome to our next lecture. In this lecture, I would like to touch and focus on a delicate topic. And this is every day test mistakes and how to avoid them. Let's begin. Let's start by disclaimer the points that I am about to present to you. The results of my experience, of my own observations, of my own interactions, but also from the experience of all my colleagues. They are not an official worldwide survey. They are just my observations as well as my colleagues. Now that this is clear, also another point. Most of those will be applicable to software testers, manual testers, not as much automation testers, and in general, more technical testers. For example, back-end tests and integration tests. There's no Okay, Let's start with number one, mistake number 1. There was a saying in the first company that I worked for and it was when you're shorter time, go yellow path. So of course the allo means you only if ones and pass stands for the status of a test case. It is pass. The insights meaning of this was that whenever you are running short on time, short-term execution time, the end of a test cycle is approaching quickly. Well, say yellow, say you only once and mark a test case as executed. And the status of a test case as passed. A bit of context here, whenever there is approaching deadline, you, as a tester, might get actually quite a lot of stress. Quite a lot of people asking cure. When you finally finish the testing cycle, when will you finally mark everything as past, mark everything as green. Green, meaning there is absolutely no defects. Everything is fine. Any we can go with the release US plant. The pressure can really mount up and can be a lot for especially new joiners. New test status. Especially, for example, when the person asking will be quite a senior person, quite a senior manager in the company. Of course, as this is a mistake number 1, you already understand this is a completely terrible idea. Marking a test case that you have not executed as both executed and passed without any defect. Again, it's a terrible idea. Absolutely never do that. If there is someone pressuring you into well, passing all the test cases, marking as done or maybe doing something quickly. But you are literally doing all your best doing following all the good practices. And well, the progress is just not acceptable for some senior manager. Then the best thing to do here would be two. Ask a senior tester, asked test manager, testlet for help in this particular situation. Trust me, pressure for senior management is something that for senior testers is completely unknown thing. And they will happily help you. They will happily talk with the senior person and explain that tester. Every single one. And testing in general stands for the highest quality of application being tested. And we cannot bend time if we need some time to test it fully, end-to-end, execute all test cases. Then sometimes we need to push the release back. Sometimes we need more time to Andy's point marking test cases as executed and past when you have not really done this is a no-no, don't ever do this. In my opinion, this is suffering that luxury can get you fired on the spot. So even if we have pressure from senior management, please don't do this. Mistake number 2, skipping test script creation. This often can occur when we're not talking about an official testing phase, for example, SAT or UAT, but maybe a small change, for example, there is a very easy to fix issue of production is absolutely not urgent. But a programmer has picked it up, fixed it in literary five-minutes, and for example, asked you to retest it so that he can deploy it to production. The fixed can be something trivial. For example, there is a new image on the website, and instead of being in the center of the screen in the middle is on the left side when the business wanted it to be in the middle. So the programmer has just changed the location. Now it is in the middle. Testing done, right? Well, not exactly the temptation to skip writing and creating a test script for this particular test. Well, it's very tempting. You literally are looking at a new and positioned in the middle centered image. Why should you write any test script that will take you 10 minutes when the retest takes one minute. Like, why do this? You can just say that it's okay and you are done. Bam. Well, the problem here is that in general, test scripts for you as a tester are kind of documentation, documentation of your work being done. This is something that says, Okay, Me as a tester, I have done this then that. And this is also your proof. Your documentation. The example mentioned here with a centered image is kind of obvious one. And for example, you could also take screenshots which would be attest evidence that you have actually tested this. However. I mentioned in this, because it's a slippery slope. If you do this once, then maybe the next time you will be just tempted to make a screenshot of the final step, again without writing the test script. However, afterwards, you can find that someone comes back to you and asks you for the proof of testing because for example, some other feature was broken due to this fixed. If you had a test script, that test script would be your documentation stating every step that you took in order to reach the final step, the final expected result, and you would have a clear documentation backing up your job done. However, skipping the test, skip creation. Well, it basically means that you're losing the documentation supporting what work have you done on this particular article? It's not a great idea. In general. Please remember to always write a test script stating the steps that you have taken to retest this particular issue. Do not skip testlet Creations. Trust me, you will be wearing but not skipping this step, we take number three, test scripts. Remember to keep the test scripts clear, consistent, and have the highest standards when we are writing one test script after another for the whole day. For example, preparing for an SAT test cycle. Well, we are humans, we also get tired. We also get distracted and you also get annoyed by doing the same thing the whole day. It is tempting to just start not being so precise. Maybe skipping a few steps may be writing in a manner that is not really precise or not really of a highest standards when it comes to stem description. However, please always take a break and try to maintain your test scripts up to the highest standard. Mistake number 4 is a bit related to their mistake discussed previously, and this is skipping test evidence while retesting an issue or executing a quick test script. There might be situation when a test is quick and easy to execute and you don't really want to be bothered with, for example, having two stars are video recording. And maybe the video recording breaks in the middle of our screen capture, forcing you to start testing all over when you are already in the middle. And a few minutes later, you indeed verify that the defect has been correctly fixed, or maybe then the test script has been successfully passed, as there is no defects in such a cases, skipping the test evidence can be tempting, however, please note that again, test evidence is the evidence of your work of the test that you have executed. So it's a crucial part of documentation and Documenting your work. Remember that documentation for you as a tester that you create is also designed in order to kind of let say, honestly protect you. For example, if later there is an issue in production, well, you have a clear documentation. For example, tests, evidence recording your test execution, stating that, well, during testing the application indeed was working as expected. And maybe the defect on production is due to missing step during deployment and release procedures. Next mistake is more of a advice from my side and it is related to what I call made-up titles, made-up job titles. Many companies nowadays tends to create made-up job titles. And I especially noticed this with startups, but I think this is a general issue. For example, if you are already working for a longest time on a project, it might be tempting to call you, let's say specific market coordinator. If your application is divided into several markets, or maybe specific game, area, lead or whatever the title might be. Often those titles will be made up so it can be whatever your boss calls it. You can be, for example, I don't know, racetrack testlet or applique banking application, head of testing. Suddenly, following this made-up title, for example, you are expected to maintain detailed metrix, send everyday reports, coordinate other testing members, and in general, report directed to your supervisor. Again, this is more of my advice, but really be careful with such an opportunities or however you want to call this. Because as I said, the job title is only in your imagination and on the imaginations of your supervisor. It does not come up with a contract change where this new job title would be stated. And of course, it does not come up with any kind of pay raise. So in other words, you will be doing an additional amount of work that is not really probably in your specific role description. For example, you will be leading your own team or you will be creating detailed reports to the end user, to the client. And in general, of course, this can be a great opportunity for change and for a pay raise. However, my rule of thumb is, if of course you are interested in such a potential role, for example, leaving a small testing. Again, my advice would be to accept if you are interested in such role, additional responsibilities, however, maker, clear cutoff, clear deadline. If you're a supervisor, for example, say, Okay, I will do this for one week. Let's make it attests to IQ tests ran. Let's make it. For one week and after the one with Willie, we will meet and discuss how it went, whether you are satisfied with my performance as a temporary testlet or temporary market coordinator, whatever you call it. And if so, we will discuss next steps. Then of course, do it for one week. Do your best and well, say honestly to your supervisor that if he or she wants you to do this on a permanent basis, then you ought to really like a pay raise and also update of your official job title, job position on their contract so that it is basically official. However, do not agree of doing this temporary job, of being on this temporary position, for example, for 12 years, like I have seen, many of my colleagues do every few months hoping that they would receive a pay raise and they receive a job title that is appropriate to what they are doing. Come on. Why would your employee give you additional money and additional job title when you are already doing this job for maybe six, 12 or more months. But if you are okay with this for this amount of time and you'll probably be okay and going follow-up to it, Why should they pay model? Why should they bump up your title? So in general, be very careful with those kind of opportunities, let's say next mistake or maybe something to avoid is burnout. Routine is deadly if not managed properly. Be careful when working on the same exact project, doing the same exact things day after day, for example, for a few months, this can lead to very dangerous behavior. For example, being overconfident and doing the previously stated mistakes of, for example, skipping test script creation, creating not detailed test scripts, or maybe skipping Test evidence. This can all occur when you will get overconfident because you already know these applications. Sowell, you have been working for one year, for example, on the same application development. So why do you need to create this test script? Once again, solution to this situation would be to switch to a new project. Often, switching to a new project can be really refreshing as everything we've seen new and exciting. Another potential solution to this problem would be to, especially if you are more experienced to become a mentor for other tester. In this case, you would recruit for your project and new testing member, potentially less experienced one and mentor this tester by sharing your own knowledge when it comes to this specific project. Basically preparing the tester to take over this project. And maybe later on, you could move to our next one while being certain that the project is in good hands. And my last maybe mistake may be more of an advice. Again, is be very careful when doing favors to others when it comes to IT development. It working environment. Of course, this is a very sensitive point, as we all in general are trying to be team players and help one another. In that case, my advice would be to, of course, be helpful. But set a clear line where you stop being helpful and start getting taken advantage of. Do not let other team members take advantage of your. An example would be working overtime on Friday, on the last day of the development. For example, working 1314 hours shift. If the Hollweg, for example, programmers have not been putting the necessary work. You're literally Sodom living every day, elderly working for six hours may be chit-chatting around, drinking coffee all day or whatever is happening in your company. Literally, you that was super obvious that they were not putting any effort. And you all agreed that application is going to be ready for testing on Wednesday morning. But due to this slacking of new received application ready for testing a day later, on first day, and now you are forced to work overtime. You are forced to work late 1314 hours. They shift on your last day on Friday. In such example, be careful when granting such favors. And in this situation, working hard light into the Friday night, Do not be afraid to ask questions when it comes to such situations. For example, confront the person telling you that hour you need to get it done today. The release is tomorrow, Saturday, so you need to work whatever amount of time is needed, concerns such a person and ask questions like, why have we come to such a situation? Why the programmers did not put additional work in order so you can start testing as planned on Thursday. Why is it yielded? Have to put overtime now? And maybe also creative questions in order to solve this problem. Okay, lets us and the programmers to help with testing. Now that are already created test scripts scenarios. Programmers can as well pick up the scripts and execute them. If we all work together, it will get done in one hour. If you all sit down and start executing test suites, of course in general, you will encounter over time, you will encounter a situation that were not planned, then the PN could not do anything about this. However, as stated in this example, It's important for you to clearly mark a line where you're uncomfortable with requests and when you become uncomfortable with requests and you feel that there was a piece missing, someone really dropped the flag and Sufi could be done better. And you are not happy with this situation. Do not forget. Of course, many of your employees are your fans, but bosses. At the end of the day, our bosses, they really do care about the release, getting through the release date being unchanged. And if there is a problem in this means that you now have to walk over crazy amount of time. Well, sorry, but often they will not care in size. They will literally go home and only check emails for statuses of how you're testing is going. And you will be the one sitting alone in the dark in the office. So be careful with granting such a favors. And do not hesitate to say that you are Miss content and say that this is not how it was planned. So now let's change the plan, for example, as I said before, by involving programmers into the script execution, this is especially a good idea in an Agile team. As stated by Agile principles. Don't forget that in general, an Agile team should be linked together and should be interchangeable, meaning that in theory, the whole squad is able to do each other's job. So do not hesitate to ask your teammates for support whenever you feel it's needed. And this is the end of this lecture. See you in the next one. 20. SQL basics: Hello and welcome back. Let's begin our hands-on SQL queries lecture. In this lecture, we are going to cover around 56 of the basic SQL queries. Just to get you started using SQL queries and checking the basic test data using SQL query to check the data in the database. As you can see on the sequel queries cheat sheet, there are many different SQL queries apart from those 56 that we will be covering during this lecture. However, I will leave this cheat sheet with you so you can explore it at your own pace. Maybe try some other of those queries, or maybe read more about them online. In order to conduct this lecture, I will be using my own local database. While you practice, you can as well create your own local database using your own machine. Afterwards, such database opens in a web browser. However, you can also look for some web browser based databases that are not located on your machine, that are just simply accessed by accessing regular websites, in my opinion, is a good idea to create a local database using your own machine. Because you can see additional structure and investigate in depth how a database is created and water database consists of, as you can see now, we are looking at the tables in our database. Table contains columns. If this doesn't make sense, Do not worry. At this stage, we are introducing the main concepts that are database has tables and tables contain columns. And we will be working on this data and those concepts today, having a local database is also useful to be able to quickly and easily check the database tables and columns. And you will see in a minute this will be really helpful when creating a query. Let's create, Let's start by opening editor, a query editor, and create a first very easy query, CQ and query. Let's start by creating the first very easy secure query. There might be a chance that you already saw all heard somewhere in this very basic SQL query is select star from and the name of a table. Let's select this table country. And let's execute such are very basic and easy query. And here we have it. Our first successful SQL query has been executed. The query has returned the records that we queried. So in this case, we have seen from the country table three columns. Trade the country and last update. Now let us go through the query we just executed and what has happened here. As you can see, there is an asterisk after the keyword select. And the asterisk means that we are querying all the columns from the table. As you can see here, our stable country has three columns and our results also contain three columns. Going forward, we'll see another keyword from from specifies the table that we are querying. In this case, we selected our table named country. Now let's look at another example. We see a table named city, and now let's change the country to city. So we will be querying city table. Let's execute the query. And as you can see now, the query result contains four columns because we are querying the Syfy table and we are querying all the results using the asterisk. Now that you are able to execute your first very basic security query, let's move forward. Touch lightly upon good practices in SQL queries. What you should always try to do and what to avoid. As you can see, keywords are capital letters or the letters are capital. So as you can see, select in capital from another keyword and the table name in small letters. Such a particular query would not be considered good practice. By using capital letters. Keywords are easier to spot and easier to distinct from the parameters. A second good practice is that basically our first query is not that good. As you can see, we wrote select asterisk, which means we are querying all the results from this table. If the table has 300 rows, we are querying 300 rows of data. If the table has, the table contains firstly 1000 rows, we are yes, querying 30000 rows. If the table contains three millions row, then we are probably breaking the database or at least freezing it for the whole development team for a few minutes. This is about practice. As you can see in the second table, we have 595 records and all of them are queried. All of them where in this case, in this example displayed, imagine also a situation where not only you, but maybe several people at the same time, our acquiring one, the same database. If few of those people query all the data in a particular table, the database will be at risk. The database will be overloaded and can even potentially suffer. Crash. So again, good practice number 2, you should not really query by writing select asterisk. You should use what is called limit. After our initial query, we should write a keyword limit and for example five. Now let's execute our updated original query. As you can see, by writing the keyword limits, we are still executing our query from our table. However, now the output is limited to only five rows. This is a very good practice as this reduces heavily the Lord on the secure database. And we should always be limiting our output. Thus query what is really needed and not everything that is in the table. Just as a side note, it we could also, instead of using limit, your keyword, select top five asterisk from city, this would also work and give us a similar result. However, both select top five and select asterisk from city limit five works completely fine and is a good practice. Whichever you use is up to you and how you would like to write your query. Of course, sometimes you need more data, more rows. Thus, updating the value in the limitation works just fine and it's still a good practice to use. There might be a case that you are just looking for a specific 12 rows. In this case, limiting the output to a small number, we'll make it even more easy for you to read, for you to understand when compressed to a big output. Okay, Now let's move to good practice number 3. And it is narrowing down our research, narrowing down our output results. In this example, let's use the column named country ID. For our example, let's imagine that we would like our SQL query to display only rows, only data containing country ID equal to 6. This is of course just an example. However, it's meant to show you how easily you can query a very specific data from a table. Of course, doing it visually is basically impossible because even in such a small table as this one containing 500, 95 Rose, doing this visually would be very difficult, tiresome, and probably causing mistakes. Task. Let's update our query. To narrow down our search, we are going to be using a where clause. We input the keyword where followed by a condition. In our case, we are looking for country ID equal to six. So you basically just need to enter the column name. And the condition in our case equals 6. Let's execute. And as you can see, we have limited our output. We have made a very direct, very clear SQL query. And now, despite the limit 500, only first-in rows of data meets our current secret query condition. Meaning it is from the city table containing country ID equal to six. The next thing I would like to touch upon is getting rid of the asterisk. The asterisk following the select keyword means that we are querying all the columns in a table. In our example, the City table contains four columns, city ID, city, country ID, and last update columns. However, again, depending on your project and on the database and table, there might be tables containing many, many more columns, 2040 or more. Maybe you are looking just for a few important columns and an output of 30 columns makes things just difficult to read and is redundant, not necessarily insecure. You can specify which tables you want displayed in the results in the SQL query output. You'll do this by simply removing the asterisk and inputting directly the column name. The column names that sure we'll input after the select keyword will be displayed in our query results. In our case, let's display the city and last update columns only. Let's execute our query. And as you can see now, our query results display only two columns, only columns specified after the select keyword. This has incredibly with the visibility and ease of reading the query output, especially as mentioned before. If we are looking at a more complicated, more complex database, more complex table. Again, to get this result, simply input after the select keyword, the name of the column you wish to receive in the query results. If there are several, simply separated them with a comma and space. Of course, in this case, we inputted to column. However, you might of course inputs another comma and add additional columns as you wish. As this is only an introduction to secure oil, we will continue updating our queries with only two more points. The first one will be orderBy and the second one count. So our thereby, Let's do it for now. Our workloads just so I can show you easier to understand. For example. Orderby, to understand it in high level means basically sorting our table by a specific condition. Let's write our order BY keyword. Of course, it has to be written in capital letters. And let's use again countryID as our condition. And we will sort descending. As you can see now, the query output has sorted out query results, output sorting by the country ID and in descending order. Now the whole output has been cited. Of course, we can still use other query elements like limit. And instead of descending order, we can have as well on ascending order. The ESC is for descending and ASC is for ascending order. So you can sorted in one or the other way. And this is a very easy example of the order BY keyword. Okay, so let's move on to our last element of this introduction lecture. Let's do it is not a good practice for now. And let's execute our query without any kind of limitation. This is, again, remember a bad example and should not be done in real life on real projects, databases, there might be times when you are not exactly looking at a specific data, specific query output, but more on our statistics of a given database, statistics for a given table. In such examples, you will not be really interested in the data itself. So for example, seeing 13 rows for country ID equals 6, but maybe you will just be looking for the number 13, meaning how many rows contain the country ID equal to 6. In such a case. You can use the count keyword. You simply write the count keyword after the select keyword. And you need to state something upon which you want to count the query output. In our case, let's use the city column and continue of course, with the second part of the query, like we did before. Just for a moment before we execute. Please understand that in line number one, we are using there select count keywords, and in the bracket we are seeing city. However, this city relays, if you look below to the column name and city, line number 2 contains the keyword from. And again, we are seeing city. However, this city refers to the City table you are seeing on the left in the tables space. So we are seeing twice the name city used in line 1 and line 2. However, please understand that line number one contains the column name city and line number 2 contains the table named city. Now let's execute our query. And as you can see, this is the result we get when using the count keyword. The results mean that in our table there are 600 rows containing a value for the column city. Of course, you can narrow down your search. You can specify again more details. For example, you could count only the rows that contain the country ID equal to six. The count can be very useful when you are looking only to get a number of data in a given table containing a specific condition. It's a lot faster to get the number, the results like this, and also it's a lot less stressful for the database. So whenever you are not really interested in all the columns, but simply looking for a number of how many occurrences are in a single table of a specific condition, you should always use select count keywords instead of querying all the other columns and just checking how many rows you have in the output. And this is the end of our introduction lecture. However, I will kindly ask you for a longer homework. I would like you to really practice additional queries on your own either by installing database locally on your machine. There are plenty of solutions already step-by-step, written down online on YouTube or on other platforms, as well as websites that have already up and running databases that you might just access. Lookup some tables, columns, and start using queries on this demo online website, database, website. See you in the next lecture. 21. SQL Coding exercise: Let's select another more interesting table. For example, film. As you can see, there are more columns than in previous examples. So now the first challenge, please pause the video and write a query so that your query returns all the columns from the film table, limiting the output top 20 rows. I hope that you all succeeded in this task. However, now, let's go over the correct answer. We write the select keyword, all the columns. So we put an asterisk after the Santa keywords from keyword followed by the field table name, and limiting the output to 20 rows. And as you can see, we have queried successfully all the columns from the film table, limiting at the same time our output to only 20 rows. Quiz number two, please take a moment to modify the existing query in order for the query to display only three columns in the, in the query results title column, description column, as well as release underscore Year column. So modify the existing query in order to display only those three columns. Next task is to increase the limits 250. And the last thing is to sort the query results by the title column ascending. So please pause the video and modify this query in order to meet all of the conditions mentioned. Okay, so let's go over the correct answer. We increase the limit to 50. Instead of the asterisk, we are specifying the free columns we would like to see in the output in putting the column names. So title and description comma released under a year. And we still need to order our output using our order BY keyword and sorting by the title in an ascending way. We execute our query and as you can see, this is the correct answer. Before we end our lecture, I would like just to mention another good practice that is ending our query with a semicolon. Of course, the query will also execute if you do not put a semicolon at the end. However, this is useful because a semicolon means that this is an end our query. And this is extremely useful in a situation where, for example, you have a file with several queries and Geokit execute by mistake. Well then if we put the semi-colons, we are not risking two queries executing Aswan, each one will end with a semicolon. The execution will be separated. And this is the end of our lecture. I hope that you enjoyed it. And you can see now that basic secure is really easy and has great potential. See you in the next lecture. 22. Prepare for a Software Tester interview: Welcome to our next lecture. In this lecture, we are going to talk about software tester interview. What are the common questions and how you can best prepare yourself? Let's begin. I have divided the questions into three candidates categories. Junior, software SR meets software tester. So let's say 23 years of experience. And our senior software tester with more than 45 years of experience. Let's start with the junior software tester interview. The first potential question for a junior software tester on an interview would be asking the candidate how the candidate would test login screen. So you may receive a piece of paper with a login screen. So a field named userName, along with a password below it and below the password button named login. Here the expectation from a recruiter is to see how the candidate things analytically. Of course, there is no expectation of the candidates actually writing down precise test cases due to the candidate recruiting for junior position. However, the correct answer for such a question would be to name a high level tests regarding this particular situation. In this case, it would be, of course, starting due to good practices with positive scenario. So test number 1, positive flow of the application. So providing username password, pressing the login button and expecting the user to be logged in, the candidate should also follow by several negative scenarios. So for example, inputting the correct username. However, internationally, putting the wrong password, pressing the login button and expecting the user to be logged in along some error message that the user password combination was wrong, as well as an adult my search upon trying to login without inputting any username and password. Another question for our junior candidate would be the question what the candidate would do in a situation where the candidate is testing, given login window, providing correct username, correct password for an existing customer. However, upon pressing login, there is a technical error message and the customer is not being logged in. Naturally, the good answer here is that the junior tester candidate would write an issue, would raise a defect in order for this to get fixed. Again, at this stage, there is no real expectation of actual in the candidate writing proper defect issue. All of these can be taught. The candidates still has time to learn how exactly to do this. The recruiter again, is simply checking whether basically the candidate has are good. Sense on what should happen at this stage of what should happen when the application behaves in such a way. And of course, the correct answer is to report an issue, to report our defects and other kind of similar question from a recruiter to test the candidates reactions might be asking a question, what would the candidate door if the candidate header task of executing our test script, however, had no idea on how to execute. And given step, for example, a very technical staff regarding inserting variables Ross and into the database, or may be updating different values on the database before executing the test. Here, the correct answer would be to seek advice from other team members. In general, the recruiter here is looking for an answer about seeking help and asking for guidance. As a junior tester, joining your team will need to ask a lot of questions, will need to reach out a lot for help before the junior tester actually gets familiar with the application. And the last part of this very short junior fester interview would be the recruiter testing the candidate's proficiency in English. Of course, the candidate is not a native English speaker. It could be a very simple task of even simply writing down the description of the paper are given to the candidates beforehand. So the piper with login screens, meaning username, field, password field, and I'm big login button. Of course, in this step, the recruiter, I just wanted to see whether the candidate can quickly and effortlessly write it down or to the candidate sees on the screen. This is a skill that requires a candidate to be able to quite easily and quickly write in a good manner. Write in English what the candidate sees in front of him, in front of her. And this would be the hand of a junior tester recruitment process. Now let's move on to our second interview. Let's imagine we are interviewing for a meat software tester role. Let's say we have 20 years of experience as a junior tester and you want to move on a software tester position. Now that questions will be a bit different. The first question that you might encounter is as follows. Imagine that you are joining our team. What would be the things that you do first on day one? Meaning it is the first day of your new job. What do you do? What are the things that you do on your fans day? By yourself? Of course. Here, the recruiter just wants to see if the candidate is familiar with good practice and understands what should happen once joining a new project. The correct answer is, in general, to ask for documentation and first get familiar with the documentation, for example, a functional specification documentation. This will bring the candidate quickly up to speed and help understand how the application works and what is the main purpose of the application without involving other team members time to explain the same thing. Another question, testing the knowledge of good practices by the candidate is to ask the candidate, what would you do if you had to test? Well, write a test script for a requirement is not perfectly clear to you. You'll do not fully understand this requirement. What would you do? And of course, the correct answer is ask the outer of the requirement. And in that case, the BA business analysts who are out of town this specific requirement ask for clarification. Ba will always be happy to clear this out, to explain to you, maybe even updating the functional specification documentation, updating the requirement. Va, always looks for the requirement to be crystal clear, as clear as possible. So do not hesitate to ask whether whenever adequate amount is not clear. In this question, the worst-case scenario, the worst answer you can possibly provide is to ask the programmer for the clarification. This is completely against good practice. Because in this scenario, if you ask for a clarification from a programmer regarding requirement that it's not clear. You will be in fact writing and afterwards testing the understanding of the requirement and the job that the programmer has done. This is completely against any good practice because you should never test whether the application does water programmer wanted. You should always test whether the application does what business wanted. You should always be testing whether the application does what is stated in the requirements. You might also get a question about writing down a test script scenario. In that case, the recruiter expects, of course now a precise testlet scenario. So starting with prerequisites, followed by step and expected result, we can use again the example with the login screen with a positive flow afterwards, followed by negative ones. But of course, here in this interview you would literally write it down the test scripts scenarios. Next question might be about creating a defect similar as in the junior interview. We can assume that the tester is inputting correct username, password. However, the login process does not happen shared as are needed software tester. And good practice would be to look a bit deeper into the issue, meaning that of course you should create a defect, write it down on during the interview. But maybe also mentioned that you would open the Browser, Networking tab, inspect contents of the Developer Console, find potentially some network errors and also include in the defect the request and response of the faulty requests. You might also check application logs. In addition, I'm nice finger to other here would be to dig a bit deeper and include as much of a technical info as possible as well in the defect. This will really speed up the time needed for fixing this issue. Next part could involve some whiteboard writing. You could be briefly checked off your security knowledge by writing down some basic to intermediate secure queries. Nothing too fancy. Probably some basic secure queries that we have covered in the previous lecture and the end of the interview. You might also get some out-of-the-box question regarding the current technology, current markets. For example, the recruiter might ask you, what is the current version of given operating system? Have you watched some latest confidence regarding those operating systems? In general, the recruiter wants to get a feeling whether you as a tester are following the technical changes, the news, and what is happening on the market. Now let's move to the first example, an interview for a senior software tester for a candidate that has four or more years of experience. Here, the expectation is that the candidate is fluent in different methodologies. I mean, Agile, Scrum, waterfall, that candidate understands fully what each of those involves and can demonstrate the knowledge. Of course, the candidate my still get all of the questions from the previous examples. So creating a test script, executing a test script, creating a defect. All of those might be asked from the candidate. As it is a senior role. The candidate might be asked about potentially helping some new team members or maybe exploring a role with mentoring some other team members. When it comes to the security questions, all the joints, and maybe some simple functions along dropping tables. And in general, having much more advanced queries that it might be a question, how would you test an application if front-end is still in development, however, backend is ready for testing. The correct answer here would be to test using rest APIs. So for example, your soap or Postman. Another question might be about being familiar with BDD, TTD, and in general, cucumber. So even when then the candidate simply has to provide some basic knowledge on how such a test case test script looks like the candidate might be asked to demonstrate basic knowledge of the good flow. What I mean by this is simply even saying out loud the correct good flow to make a small change. In this case, it would be, of course, cloning the master repository afterwards, Git Fetch Origin, git pull origin master afterwards creating annual branch, updating the needed data, adding the changes, committing, puffing the new branch, followed by creating a pull request for review before managing to master. As it is a senior software testing position you might be asked about test automation. Test automation questions will involve in general, the fundamentals of programming. For example, easy FOR loop. So the basics of control flow, a for loop that goes through 0 to 15. And every time a number is divisible by 3, our loop prints out divisible by three. And every time a number is divisible by 5, the loop prints out divisible by 5. Another question might be to write a simple function returning a given value. Also, regarding test automation, you might be asked about testing frameworks in general. So it's a good idea to get familiar with them, even if you're not using them, the current position. Another question you might receive on a senior software tester interview is a question about application diagram in general and application design. The recruiter might want to check your understanding of high-level application components. And we'll ask you to draw a mock-up of the other application on a whiteboard. So you understand how the front-end is connected to backend and of course to database and any other needed components. Another question might be about network codes that I could tell him. I just randomly throw a CIO some network codes and ask, what are the meaning and when would you expect one? Another? Critical question might be about services. So for example, put gets post secretary would ask you to explain when you would use each of those and what does each of them do? Probably the interview would also end with an open-ended out-of-the-box question. For example, by asking you, what book have you read recently in regards of software testing? And this is it for this lecture. I hope you enjoyed it. See you in the next one. 23. Common interview mistakes: Welcome In our next lecture, common interview mistakes and how to avoid them. In this lecture, we will not be dividing our examples into junior, meet other senior software tester levels. However, we will be talking about mistakes that can happen in general during an interview. For a software tester. Many of those points will also involve sub-skills, meaning modal personnel points. However, please trust me, they can be not that technical, but they are still really important to the general interview outcome. In my career, I have been either conducting or assisting as are taking her reviewer on many interviews. During those interviews, I have observed several mistakes that with proper preparation should not really happen. Let me share it with you. Let's start with mistake number 1. Being late for an interview. I know how silly it sounds. However, you would be surprised. How much does this happen? Actually in real life, many candidates, often in the last minutes try to either residual or simply are late for their own interview. Naturally, there may be many reasons why this happens as a social to mistake number 1 in general, please, as a candidate tried to be 15 minutes in advance of an interview and I've to the office, sit down, relax yourself, calling yourself and prepare for the interview. Being like for an interview. Regardless, the reason is never a good first impression. Mistake number 2, negative attitude. Please remember that an interview in general is always an opportunity for both the candidate to start a new and exciting role, as well as for the company to source a new and great employee. Both parties should respect each other at the interview. However, I have been conducting several interviews with experienced software testers with several years of experience. And during this interview, they were shocked when we came to a part where writing down an exam was needed. Writing down at test was needed. Many of those people were not only shot, but also offended that I was suggesting writing down some tests, some exam they came for an interview with the expectation of well, yes, talking but only verbally without writing down anything. And after the war, following with the paperwork. Please. Whenever you come to an interview, be ready to write some tests down, right? Some exams down, or maybe write on the whiteboard. This is an interview mistake number 3, or in this case maybe a hint pointer. Prepare yourself when it comes to the job expectation. Especially the key points that are required from a candidate. Even if you see on the list are technology that you are not familiar with, that you are currently not using in your regular workplace. And great thing to do would be to maybe use one weekend, one of your free time weekends to study this particular technology, put in some effort and just learn the very, very basic of it. Just to have an idea of what this is about during the interview. Tell the truth that you are not using this technology at your current or place GAS. You do not have years of experience using this. However, you know a little bit about this. You have UCR the weekend to learn about this. This will show the recruiter that not only you are too full. Well, because you said that you don't really use this as your current workplace, but also that you are dedicated hardworking because you use your own personal time to prepare for this particular skill on the job list for this interview. But also that you are open-minded and eager to learn. Those are very good trace and recruiters really do look forward for open-minded candidates. Mistake number 4 would be, do not be arrogant. Trust me, it does not matter how good of a software tester you are or how many years of experience you have. If you come out of an interview as an arrogant candidate, the chances are you are not getting the job. Please remember, software testing is only a small part of the whole application development lifecycle. There are many other people working for the end success of the application development. Whether it's a BA with whom you need to talk about some requirement, or maybe a PM with whom you need to clarify the test cycle deadlines. Or maybe backend programmer to whom you need to clarify some details about your recent defect report. There is no way to do this alone. So an important point is to demonstrate on an interview that you are a team player. Now, mistake number five, a very popular one. Please do not lie on your resume. I know this is an obvious one. However, many, many people still decide to write it down on their resume. Points. Skills that are simply not true while lying cannot resume, can in fact get you into some best of the best IT companies interview. However, a good recruiter will immediately see through it. And sometimes the lice are completely obnoxious. Let me give you an example. Many companies nowadays, before an interview stars will give you a small piece of paper on which you will grade yourself, grade your skills. You will write, for example, from one to 61 being the lowest, six being the best. Your particular skills, for example, defect creation, test case writing, requirements, analysis, secure queries, et cetera. And you will create yourself. I was conducting an interview for a senior software tester and had a candidate that on his resume, had three years of experience working with Python, as well as graded himself four out of six when it comes to Python knowledge, Python skills. However, once asked about fundamentals, basic Python, Basic programming questions, the candidates literally could not answer n of those. Me and my colleague, to be honest, we were puzzled. We were not sure what is going on here. Fortunately, the candidate clarified that what he meant by three years of experience with Python and four out of six, remember, on the self grading skill level. Using Python was that the application the candidate was testing in the previous company has been written in Python. And the candidate was testing it for three years. Does the candidate have followed 06 python skills backed up by three years of experience? Yeah, don't do this really. If you make such a lie on a resume, It's basically over again. Simply request, please just put the trough on your resume. Otherwise, the recruiter trust me, we'll see right through it. We have come down to our last point. And this is a difficult one to not apply to companies and foreign job offers that you are completely not qualified for. This might be a difficult point for your, because nowadays we hear everywhere that sky is the limit and everyone can achieve anything. My best advice would be kind of in the middle. So of course, be ambitious, be hungry, apply for new exciting, challenging clause. However, please be realistic. Again, let's use some example. If you are unexperienced QA tester, a software tester, you have been working for a few years in a company X, let's call it your testlet, maybe is on holiday and has asked you to lead the team during his absence for, let's say, one month. For the last month, you have been leading the team successfully and you really are drawing this being a teammate. Now you see an opportunity and job opening for testimony it in another company. Applying to this company, despite you having one month of testlet experience is ambitious and also upgrade idea. This might be something for you and I'm great. Next step in your career. However, if the same candidate sees an ad advertisement, job opening for a senior test automation, we're in the description. It clearly states that the candidate should have around five years of experience, test automation experience while using Java and selenium. And our test date candidate has never in the entire life created a single automated tests, nor knows anything about programming. Well, this will be a complete waste of time for both the recruiter as well as our candidate. However, we see people doing this mistake and often being discouraged by the negative result of job interview often goes really wrong without the candidates answering any of the technical questions. So again, the message here, I fully encourage everyone to seek out new and exciting job opportunities. However, just please be realistic when it comes to the job description and expectations from a candidate. And this is the end of our lecture, as well as the end of our current section of the course. I invite you to the next one, and I will see you there. Bye. 24. Introduction to section #3: Hello and welcome to our next section. First of all, let me congratulate you on completing the introduction, as well as the testing Fundamentals sections. By completing both of those sections, you now should have a better understanding of what being a software tester is like. What are the prerequisites, what a typical day looks like, as well as have the basic knowledge of what are the fundamentals of software testing. I'm happy to invite you to our next section in which we are going to be looking into more technical testing, both when it comes to API Jason, as well as good flow. We're also going to look more into theoretical topics related to being a more senior tester from a perspective of an already more experienced tester, those topics will be a little bit more complex. However, they are also crucial when it comes to your next steps as a software tester. So without further ado, let me invite you to our next lectures. See you then. 25. Team leading in Software testing: Hello and welcome to our next lecture. Before we dive in into more technical lectures, I would like to discuss interesting topic when you will be working as a software tester for several years in an IT company. There will probably come a moment when you will be ready to take the next step in your career. Or maybe you will be getting some small pushes from your manager. Even if the careers step up is not initiated by you but suggested by a manager, it can be in order to keep your best interests at heart. Working at the same company may be an assigned team in the same project can be kind of tiring. If for example, for a few years, every day you are doing the same work. So you start a new project, you set a timeline, and then you join Agile team. So of course, all the ceremonies begin your start sprint planning. You start working on tickets. Afterwards. It's the retrospective, and so on and so on. Everyone can get tired of this, especially if we are talking about years of doing the same thing. That is why nowadays, more and more employers will often start our one-on-one discussions with, in general employees. But during your one-on-one, as a more experienced employee, you might come to a point of your next steps. What possibilities are there for you when it comes to growing as a software tester, as an experienced software tester. Let's look into this. Of course, it will vary from company to company, as well as individual cases. But in general, I have observed two patterns that often repeat and repeat. The first step up, the first choice of a step-up of our career step up, would it be to become a senior software tester or a test engineer here, another example is to become our test automation engineer. For example, a full-time test automation engineer and exemple mentioned before. So becoming a full-time test automation engineer would mean that you will be basically letting go of all the manual testing you have been doing so far. So normal credit test scripts scenarios, normal reviewing, normal executing tests, flips scenarios. But instead, now you would focus, for example, on taking their already passed already completed tests and looking at automating them into an automated regression. As an example, by letting go of Manuel daily activities, you can now focus on either creating or updating the current automated framework, as well as mentioned, automating already passed test script scenarios in order to create an automated regression sets. Of course, for you as a new automation engineer, this would mean learning programming language. So for example, Java, Python, or a swift. Of course, there are many, many others, like C-sharp also being used in a test automation. Those are just examples of programming languages being used in test automation. But of course, there are others. Apart from learning programming language, you of course, need to get familiar with our test automation framework. For example, maven, seller new espresso, troubled framework, or exit test. The framework you choose will mostly depend on the type of application that you are testing. As different frameworks have some kind of different limitations. And also the programming language that you are, your automated team will most likely be using, of course, as an automated tests. You will also be doing the full length development pipeline. So this will involve, of course they get flow as well as managing the repository of the code. Often automated tests are of course, being triggered automatically. So you will be able to also assist with the maintenance or some changes when it comes to the client that is being used to both three-year and monitor automated tests. For example, Team City or Ann Jenkins. Naturally, test automation with Castro digression will not be your only task as a technical tester. You will continue to expand your knowledge and also focus on other type of tests. For example, performance tests, our API tests, integration tests. They are all strictly technical. They can all be automated as well as placed in a shared repository for the whole team to use. This was the first example of a potential career path for a more experienced software tester. Now let's move to the second example. The second common career path for experienced software tester is to become a team leader or team manager. When it comes to software testing, often there will be possibility to accept such a role either by the current, the current expenditure changing positions or maybe changing companies. So such possibilities will arise if you are working for an extended period of time, same company. So what would involve accepting such a new opportunity of becoming testing it or maybe test manager. Well, similar to our example number 1, in such a case, you will also stop executing or creating an Manoa, the scripts, it will no longer be part of an Agile team and you will no longer be basically involved into creation or test execution in any way. You will be no longer reporting defects, no longer be testing defects. Basically stop doing what you have been doing for several years now. Instead, you will now be responsible for overseeing several projects when it comes to deadlines, but also the general test approach, as well as creating detailed test plans. This will be only your job. Additionally, whenever there is a release, you will be responsible for gathering the current as well as updating the ongoing tests progress, for example, of regression tests ran, as well as new feature test cycles. Creating reports may be creating spreadsheets and reporting back senior managers and stakeholders. You will be joining more and more senior management level meetings and reporting for the test team in general. If there is a leadership question or maybe a problem with arrays when it comes to testing all of those people who will becoming directly to your for advice as well as problem resolution. The same way whenever there is a problem on a project or maybe with some release when it comes to testing, other testers, people that you basically manage now will be also coming to your for some advice and for potential problem resolution. So in our example number 2, you will be basically the go-to person when it comes to both the software testers having any kind of issues, problems, as well as stakeholders or senior management, having any kind of problems that needs resolution. As you can clearly see, this role requires some soft skills. As you will often need to deal with a complex and difficult situation that needs to be resolved in a timely manner. They're all we'll also require from you people management skills as you will be having the regular employee evaluation as well as employee one-on-one meetings with other software testers that are on your projects, on your Teams. Of course, as a test team lead or test manager, you will most likely be involved in the hiring process. Which means you will be reviewing candidates resumes. You will be selecting a smaller group to meet in person, as well as be present on the intervals along probably technical tester in order to work together to assess the candidate in person. Also, I would like to stress that this role probably involves a lot of problem-solving as well as a lot of time spent delegating and not actually working on issues, understand this and be ready that whenever there is a problem, whenever there is a back, whenever something needs to be done. Apart from 0 to 100 watts you have been doing for the last several years. Now. It's not your turn. Now you're turning to delegate. And other software testers will be executing the task in hand. Please keep this in mind as this can be a difficult thing to overcome for some people that like to be involved, like to be in the middle of the action and not sit back on the site and just wait for some status update on where we are, whether it has been a successful or unsuccessful test. So there you have it. Those are my two examples of the next career step up for a software tester. For an experienced software tester. As you can see, they are hugely different. Both exciting, both interesting, yet requiring completely different skills, as well as offering completely indifferent new challenges. My final thought is to recommend you. If you have the possibility, may be down the line, try both career paths. As in my work experience, I have met plenty of successful test managers with a technical background. For example, as an automation tester, as well as full-time automation testers that we're more than happy to help with the coordination of some manual software testers and really enjoyed it later on, moving to full manager position, only managing people. So to recap, none of these changes is better. Both are great. It requires for you to leave behind all the manual tester activities that you have been doing now for several years. However, in exchange, it offers a lot of new challenges, a lot of new activities to do in order to let you grow as an employee. Final decision, of course, will be yours. Chose. Whichever one makes you feel better. Whichever one gives you more satisfaction and feels more natural. This is the end of our today's lecture. In the next lecture, we are going to start looking at some more technical aspects. More technical lectures. I will see you there. 26. API testing introduction: Hello and welcome to our next lecture. In this lecture, I will briefly introduce the topic of API testing. In the next lectures, we are going to be looking at API testing. The same as with our secure lecture. I strongly encourage you to also try to participate, tried to recreate on your own local machines. The lecture, as well as the lecture exercises. Having a hands-on experience is crucial to both understanding as well as getting the feeling of the new technology. In that case, API testing. You can even try doing similar exercises daily. And you will be astonished that from day to day, doing the same challenge, the same exercise, will feel more naturally, more easy as you will have better understanding of the tool, better understanding of the technology, making the task easier. So let's begin the introduction with shortly describing what API testing is. So from our beloved Wikipedia, API testing is the type of testing that involves testing Application Programming Interfaces, our APIs. So API or application programming interface API testing. We're testing of the application programming interfaces. So again from Wikipedia, touristic application programming interfaces directly enters a part of integration testing to determine if they meet expectations for functionality, reliability, performance, and security. And this one is very important. Since APIs, like a GUI, API testing is performed and the message layer. This is a crucial information when it comes to API testing. I will read it again, since APIs lack GUI, GUI, graphical user interface, API testing is performed and the message layer. This means that whenever we are testing APIs, we will not have a graphical user interface. It doesn't matter what our application is. It can be a back-end application, for example, stock trading engine for trader company, but also it can be diary or Notepad application like automobile, hotel booking up. So of course, the final product will have a graphical user interface. However, this is crucial to understand. It doesn't matter. In regards of API testing. While testing APIs, we will not be using graphical user interface. We will focus on the message layer. As mentioned on Wikipedia. We will be testing applicant the application, meaning of course, we will be performing some steps and validating whether the result meets our expected result or not. So in general, as mentioned before, in the previous section, the fundamentals of testing have not changed. We read the requirement afterwards, recreate some tests, some steps to execute, and we validate the result, whether it meets our expectations, whether it meets the expectation from the documentation, from the requirements. So as you can see, when you understand and learn the testing fundamentals, they are going to be used in other more advanced types of testing as well. This is why I stated in the previous section the fundamentals was so important to learn, to understand how we create a test, how we implement this test, what is needed, what is the action and what is the result? Also what we validate in this result. Also, this is a good moments in our IP addressing introduction to mention HTTP status codes. Here are some basic ones to remember, some, most common ones. So for example, 200, status code means, okay, 201 created 20 to accept it. Free or one moved permanently if you free or free, see other three or four, not modified, three or seven temporarily redirected for a 100, but request for a one unauthorized for all three, Forbidden. 44 not found for 10, gone, 500, internal server error, 50, free service unavailable. Those are very common network codes. There are both codes that relay positive message, a successful message, as well as error codes are often met. Error codes like follow four or 503404, 0, 3, 500. Those are very common error codes that not only software testers, but an end-user's see in their favor is applications from time to time when things go wrong, where those status codes are being returned, and where do we validate them? And what exactly do they mean? All of those things I will try to explain in our hands-on practical lectures in the next few lectures. So for now, please just make a note of those common network calls. This is the end of our introduction lectures into APA testing. I will see you in the next hands-on lecture. See you there. 27. Postman part #1: Welcome to our screen-sharing session. As mentioned before. In this lecture, we will focus on the very beginning of our journey when it comes to introducing API testing. As mentioned before, APA testing will be done in the back-end. So we will be sending requests, receiving responses. However, we will not see the front-end of the application. This lecture will be from the beginning. So I will try to explain all the basics and not just jump into action immediately writing a new request. This lecture, we'll show you that even in everyday work. And Manuel cluster can use simple API calls to make everyday task easier. We will be using an application called Postman in order to use the requests. However, let me start by describing where API testing can be useful for software testing. Let's imagine we have a software tester testing web application, browser application. It doesn't really matter if it's casino application or maybe some email application, blog application, Facebook kind of social application. It does not matter. This software tester will still be able to test our number one test, new customer creation. And of course, such a software tester will be able to test scenario number 2. So login in many, many companies, the new customer on-boarding, new customer creation and login are one of the most crucial tests to perform on an application. Because of course, whenever new customers cannot Join, cannot register to a service or a company, this is a huge loss for a company, meaning always, this kind of tests will have critical priority. The same goes with the login process. Of course, if you have a customer, probably they would like to from time to time login to your application. So again, new customer registration and login should be tested as much as possible. Of course, this can be best covered by automatic tests that are executed every hour. However, you will find still many companies that do not have even those crucial puffs, meaning number one, the nucleus, my registration number to login covered by automatic tests. It will impossible that if you are on such a project and you are responsible for quality assurance for testing the software. It might be required of you to test this every day, for example, in the morning, to test whether this has not been compromised by maybe previous evening code deploy, as you probably can imagine, if you are, would be requested to test a new customer registration and login every single day. Let's say that it takes. Five minutes. If you do it every single Workday, it will quickly become a burden. Even if it takes five minutes doing this every day, it is still a burden. Okay, so let's move forward with our lecture. As you can see, we are using the application named Postman. I am using macOS operating system. However, you can easily find this postman both on Windows and on Mac OS. I encourage you to download this application for free and install it so you can practice on your own so that you can get better results from this and the next lectures when it comes to API testing. Important to mention that there are other applications with which you will be able to test requests and responses as well, for example. So now let's move on forward with our introduction. The websites I'm using is a request, and you can see the address in my address bar. During this lecture, I will be using this website to create a sandbox environments so that you can practice our requests. As you can see, after one click, we have our sandbox environments being created. Before we move on, I would like to go over the network codes. In the next steps we will take, understanding network codes is crucial. You need to be able to understand at least the basic codes. So here is a high-level look at the basic code when it comes to a Coke numbers starting from one to five. So informational number 1, number 2, success three, redirection for client Eran and 57 Adam. You've probably often found some pages displaying the 40 for error codes or maybe the 500 sediment error codes, number 200 are displayed in the background. So for example, number 200 means, okay, if application works as designed, it mean, it means basically past success. And here are the very popular codes that you might have seen without any specific testing. So of course, the 40 for not found page not found. If someone creates maybe redirection link page or deletes some other sub page. We are welcomed with their fellow for error. Internal server error number of 505 or to buy the getaway. If a server is overloaded, we will often see those arrows as well. So again, I encourage you to study the network, cause the main coast to remember for this lecture will be 200, okay? Few of the 400 codes, so 40, 45 example, and 500. Seven AD or aswell dose network calls will be useful for us to check them in an assertion. Okay, coming back from the request codes to our sandbox environment creation, as you remember, we left off when our sandbox and vitamins endpoint has been created. This will basically be displaying the communication from postman to the application. This is kind of like a simulation to our application. First of all, let's even check the application works. We start by copying the end point. Now that the endpoint is copied, let's head on to the postman. Click the plus button to open a new request. Paste the end point to the request URL. Below you can see some other windows. The main view is the end point. On the left are available methods to the end point. Below you can find the parameters for the request. You can insert custom headers, custom body, but we will move to this later on. And of course, on the right side, you can send the request and save the request for later use. So again, please paste the end point leaf to get as a method and send the request by pressing the send button. You have successfully sent your fans requested and received your first response. For now we have no tests, however, do not worry, this will change in a minute. For now. I'm just trying to show you that we have successfully communicated with our application using a request. As you can see in our sandbox, we have a conformation, that application received our communication. The most important thing for this first step is that we ensured that the communication is successful between our Postman application and the test endpoint that we sent to our request. The endpoint is responding in a real life work. Before you start writing a huge request, we've test assertions. It's important to basically just check that the endpoint is working. So in real life, you would also start by this very, very quick test. Please remember that end point is not the website address. And point 3 directs to a specific service. If your website is, this will not be the name of your end point. So the question is, where do you find the endpoints? Well, number one would be to find a technical documentation with the end points clearly written down. However, of course, if such documentation is not present on your project, the best thing to do is to approach your company programmers directly. You approach the programmer and explain that you'd like to test. For example, some requests regarding new customer registration or login. And Well, as the programmers created those services, they will gladly essential some documentation they might have saved in their local machines when it comes to the end point addresses, as well as what to put in a request. Different requests will require different requests when it comes to the headers or the boundary. Coming back to her introduction, now that we made sure that we have successful communication, we have also two requests opened. After only one click, you can see that the request works successfully. Their communication works just fine. Even in such a quick tests, you can already see that the endpoint is working. So for example, if you have two tabs as we do now, and you would have from your technical documentation or programmers, the direct endpoints of a new customer registration and our login screen. You could put those end points in two separate tabs. And with one press of a button, you could instantly check that at least the endpoints are up, aren't working. So immediately you can see that instead of opening our web browser and manually typing in the registration website address and login screen address to even validate that they are up. You can do this instantly with a press of a button from the postman using requests. It's a very, very quick and easy tests. Of course, let's go one step further. You do not want to press this button every single day, every morning. So the best thing is to automate this process. We can do this by accessing the tests tamber, here, we will be writing our tests. And big help, especially for new testers, are snippets located on the right-hand side of the screen. Upon pressing, syntax will be filled. And this will make things much easier when it comes to writing first tests. As you can see, we have already snippet provided to us with exactly the thing that we want to test. Meaning that the service, the endpoint, is up and running. Died point returns success through body. In other words, if you access the endpoint via a web browser, the websites should load just fine. Upon pressing the snippet, Postman already filled the template of our code that normally we would have to write it down. For now, maybe let's not focus too much on the syntax. However, you can see that the response is validated to have a particular status code. Again, this is the network codes that we discussed at the beginning, and in this case it will be 200. So, okay. Now we have the fattest test to our request. For our lecture purposes, let's create another request with a new sandbox end point, same as before. Let's copy the endpoint. Pasted. Of course, at the beginning tested and writes this exact same test as for our previous sandbox. Okay, I pasted the wrong one. However, now we have simply two steps in our test. As you can see now, both tests are successful, both tests are passed. We have also additionally by my miss click, tested, that the response time is below 200 milliseconds, So even better. Now, our request has two tests. We double-check. The previous sandbox is working as well, and the test result is as expected. Now that we have two different requests and both working with tests, we have reached the previous topic that I wanted to mention with your tests automation. Of course, both tests are fairly simple. In the first one, simply we are asserting that the response is 200 and in our second, that the response time is below 200 milliseconds, and then the status code is 200. Oh, as you can see now there was some bottleneck on our sandbox application. Of course it's completely for free, so we do not need to expect always the fastest performance. However, it was a very nice example of our tests being functional. Coming back to our test automation, of course, instead of opening our browser, having those two requests with tests is already a step up. However, please imagine that every morning you need to test 100 endpoints. Well, opening 100 tarps and pressing the send button is not a great idea. Here is when collections come in hand, press the Create Collection button, endless, name it your name and normally with the name of your application that you are testing. In order to group those tests. However, let's name it for now, registration and login plus the Create button. And you have created your first collection. Next step will be to save our requests because for now they are unsaved. So let's save our first request with our request name registration and put it immediately in our collection. Let's do the same with the second one. So that saved us login and added to the our registration login collection. It is automatically filled. However, of course you could select a different one. Both requests are saved and aswell added in our collection, registration login collection. They're present and under it. Due to this, we have reached the point I wanted to show you in this first step, simply checking whether the two end points work as expected and whether the tests and in success in this case, let's imagine that, as you can see, that has a fairly quick TO create and you have added many, many different endpoints and many tests. Of course, we will not be pressing on each single one of them Send button. But as you can see, we have our beautiful Play button next to our collection. The Play button executes all the requests, but of course they contain tests. Press the Run button and the runner will open up. You can set up additional parameters, for example, iterations, number of how many times this will get executed. Let's leave it at one. You can also input delay and other options. However, for now, please, let's just focus on the execution. You can also modify which requests will be tested. You can check them uncheck. You control the population. So now let's run it. And the runner has succeeded. And already you can see that the tests are working. The report is very clear. You can see how many tests have passed and how many tests have failed. Below, you can see more precise, more specified description. Along with tests, we end their assertions. Here is the assertion, meaning the status code to retirement will be 200. And indeed it happened. However, our failed step had an assertion that the response time is less than 200 milliseconds. And on the red, on the right-hand side, you can see the error that caused this particular fail. And well, assertion error expected 1750 to be below 200. So this test received a response time equal to 750 milliseconds, while it expected to hundreds or below milliseconds. The next test, of course passed because the Phaedrus code was in fact equal to 200 million. Okay, the endpoint was functional, just working slowly. Now, let's touch upon Y. Using this outer manner. Using this approach is such a great way. Why are we even mentioning this at the beginning of our introduction to the end point testing. This is a great tool because it requires you to work many different tests and test them, of course, for example, for one day. However, once you do this, once you save those requests and added them into the collection every single day that follows, you will be able to only open this runner and press the Execute button, go for a coffee. Return and you will, for example, have a clear report from running 150, 200 requests with clear assertions. In just a few minutes in the morning, you are able to have a clear view of how your application looks like. What is the status of many, many endpoints? As mentioned, for example, you can add many different endpoints, many different requests, of course, to each request you can connect many different, many more complex tests. You can as well every morning, share the results with your team. For example, to share doubts, all the endpoints are working as expected. You can send an e-mail. I would like to emphasize again that if our status code is different than 200, because the server is down in a few seconds, you will be able to know about this. And doing this manually can take some time because for example, it can be a service that is triggered somewhere in the middle of a new customer registration. So as you can see in this first lecture, I would really emphasize the importance of sitting down and writing a few fairly easy and straightforward tests when it comes to requests, really do not need to worry for now about the fail we are getting for the response above 200 milliseconds. Normally your application will be running fast. And even if, if you include this assertion, this should not be a problem. Second of all, if our test environment is running slowly than simply, we will just remove this assertion and let the application run a bit slower. But this is not really the main assertion that we want to have. This is just something that I wanted to mention on the site. Of course, this is just an introduction. So for example, now you know how to create a new request, paste points to this request, check that the endpoint is responding to our requests. And afterwards at a very simple assertion, a very simple test to our request. For example, testing that the status code in your response is equal to 200. Afterwards you know how to save such a request. Create a new collection, and add a request to our collection. Afterwards. Running collection and seeing a clear report after the collection run. One more thing I forgot to mention before. However, please bear with me as it is a very important one. It is also good practice when it comes to testing requests. Whenever you are writing tests with any kind of assertion like we are seeing here, I move on too quickly before, of course we run a test. As you can see, it is successful test. I know that this test makes sense. However, you should not do the same as I did. I did a mistake. I did not follow good practices, for which I apologize and I would like to rectify it right now. So again, whenever you are writing a test, like we did here, and you execute this test. See our result, pass. This is not the end of writing this test. I moved on too quickly. You cannot at this stage move forward saying that, yes, the test is working. You need to intentionally tinker some settings in order to trigger fail tests status. Otherwise, you are not really sure that the test is in fact working. This is very, very important good practice when it comes to writing tests in requests testing. Whenever we are writing a new test, please. First, okay. Make sure that it passes. However later on, verify the condition is correctly being checked. So intentionally trigger our fail to this particular assertion, to this particular part of the test. In our example, let's intentionally change the end point in order to get a different response code. Then 200. In our case, we are asserting whether the endpoint, in our case, our sandbox, returns a status code of 200. So we are checking if the communication between Postman and our newly created sandbox is in fact working. So now let's add some texts, some numbers to our endpoint address and assume of course that there is no such endpoint existing. In this case, testing if our assertion in the test is working properly, I assume that upon ending the request, the response will not be 200 and does a validating that our test is working correctly by reporting the test status as failed. And as you can see, this is exactly what I meant. Before you can move on saying that, yes, my tests are written and correct, you need to intentionally current application changed something in your request to trigger our test error. This is an assertion error. As you can see, the expected response was supposed to be 200, but we instead we got the fluorophore. Again, as mentioned before, the status codes for a four means not found as expected. This means that there is no such as sandbox endpoint at this time. Thus, the end point is 4, 0, 4. Now we roll back our changes and we see that again, the test is now passed. Only at this stage when you have both tested that the test fails and passes whenever there is an assertion error, only now, whenever you have checked that the assertion fails. Whenever. It makes sense, whenever there is a different response than 200 and passes when the response is equal to a 100. Only now you can move on with other tests. Only now you can say that you have successfully created and tested new point annual Request test. So again, when you regarding this lecture, please try to follow this lecture by creating a sandbox after the war to those requests, adding a simple test validating the status code is 200. Afterwards creating annual collection, adding the requests to the collection, and using the automated runner to test whether the requests work as designed and also analyzing that the parts do not forget to test the assertion when creating meaning to test both the positive, the past results of a test, as well as the fail result of a newly created test. Please focus on this task. Practice, re, watch the lecture whenever needed. And once you have mastered this section, I will see you in the next lecture where we continue our work on requests, testing and testing. 28. Postman part #2: Welcome back to our second lecture regarding endpoint testing using requests and postman. In order to summarize the previous lecture, we created basic sandbox environment and point to which we connected our requests and roll basic tests. One asserted whether the response status code is equal to 200, and we created one additional, whether the elapsed time is belonged to a 100 milliseconds. We added the requests to the collection and started the automated around of the collection requests. Basically, the tests were simply checking whether the endpoint is alive, but we are not testing any more advanced functions. We simply check whether the endpoint is responsive and active. However, this is still a good test. If, as mentioned before, you'd have more requests targeting more endpoints. For example, 2030. It is still a good collection and a good test to check whether the endpoint is up and running. I also hope that you had a moment to practice yourself everything that was mentioned in part number 1. And now Ali's clear when it comes to actions that we executed in part number 1. Let's move to today's tests, basically picking up where we left off in previous lecture, postman number 1. Now let's try to test whether a specific function of the application works as designed. For example, if it's a calendar application that you in fact can add a new calendar event. Or maybe if it's a music application that you can add a new song, this will require updating our requests. For example, in headers. Request in login would expect, of course, their username and password, at least the same for a new customer registration request, we would probably need to input name, surname, username, desired password of us feels that will be required for a new customer registration. I would like to go with you over the new customer application. However, of course, the sandbox that we use previously is not designed to allow us such a test. And any kind of life. Websites should not be used for such kind of testing. Should not be used really for any kind of testing. Because many life applications will have some additional verification tool specifically prevent such kinds of requests. A common one is capture containing letters and numbers that need to be input into the field. Of course, using a request, we will not be seeing the image or another popular method of verification is used by Google. The tool click for example, the image of a car from the provided list of images. Of course, again, we would not be able to run such a request from postman because this would prevent us from successfully. Inputting the text on selecting the correct images. In order to practice some more advanced requests, we will be using the application thread or the application trello allows you to register Sina completely for free. Of course, I am already logged in. However, if you would like to practice as well, you just need to sign up for a new account. The main thing with Trello is that it fully supports API usage. Whenever you are signed up, you can totally use APIs and turned off fully supports it. So we are not breaching any terms of fuels and regulations. Trello fully allows an officially supports its users using directly endpoints, direct API calls by using requests. This is why for this lecture we will be using Trello. Again, this is important note. Of course, you can use many other websites to practice your skills when it comes to endpoint testing. However, please do it responsibly, read the terms and conditions, double-check that the website allows you to execute a particular request, that you are not breaching any code of conduct and a the rules of the website. The next point that you need to focus on when selecting websites to test or enhance your skills when it comes to endpoint, request testing is the documentation. The more advanced the request you want to make, the more information you will need when it comes to what the request should consist of and what the service expects from your request. Without a good documentation, you will simply not know what to put into the request, okay, now I am logged in to Trello. I have created some simple board. Trello is an application where you can create different boards, comment, et cetera. During this lecture, I will try to focus on executing requests that will basically do the same thing as we could do from front-end from this screen. As I mentioned before, while testing the endpoint, while testing the API using requests, you will not be manually operating your application via front-end, meaning via graphical user interface like this one, however, your actions will be exactly the same as you would operate graphical user interface. Thus, for example, if you had a comment, you fully expect these comments to be visible in the graphical user interface once the request is completed. However, more about this in a moment, Let's go through some basic use cases. In Trello, for example, you can add a new card and more and so on and so on. So of course, testing manually, you could be adding. The cars and assessing whether they have been added, if you can edit them. Now, coming to the documentation, as mentioned before, you should always look for a technical documentation when you start testing endpoints, you cannot simply copy the address bar we are seeing in the browser. You should either find it in a technical documentation or as mentioned before, ask a developer programmer for it. Right now, I am going to find the Trello developer's website, which will contain our technical documentation. As you can see, there is a lot of quick start guides and the box on the left will be the most relevant for us. As you can see on the top there is the IPA dogs link API, of course stands for application programming interface and consists a documentation of what the application expects, what an endpoint expects in order to work. So without any unnecessary weight, Let's go forward with our first exercise. Let's add a new cart using requests instead of writing manually cartoon in the graphical user interface, we can do this via Postman. Let's find the appropriate section. Of course, hours will be carts. As you can see, there is a lot, a lot of different endpoints when it comes to simple commands. Here you can see different metals. You have, get, put, post, and even delete, which will test some. Okay, Before we begin to make things clear, let's not use this board. Let's create a new one. We have a default border. Let's create a new board and after all, adds new cards. Let's switch to the Boards section of the API documentation. You select post boards, post method of the boards. And here you see the parameters. Name consists of the asterisk, which means that it is mandatory. You need to provide this value in the request. However, all the other parameters are not mandatory. As you can see on the right-hand side, they have a default value that will be assigned in our requests if we not specify a different value for it, however, name is mandatory and we need to specify it before sending the request. First of all, let's copy our endpoint. Again, this is a post-mitotic case. Remember this? Let's go back to our postman and let's close the request from a previous exercise and create a new one. Let's paste the endpoint address and do not forget that the method was passed, not get. As you can see, the parameters were automatically downloaded by postman from the endpoint address. Of course, the value of name should be different. One it can be anything you want. It has to be a string. And this is it. All the other parameters are optional. And let's send our request. As you can see, we have an error, invalid key. What has happened? Well, of course, everything is just fine. We are trying to create a new board. And we copied the end point from the documentation. However, we have not authenticated in any kind of way. Of course, we have created a new account and we would like to create a new bot for our new account. But the postman and point does not understand what our account is. So as you can see, we need to go back to our documentation. And you can see in the documentation you can get your API key by logging to turmoil and visiting fellow up key. If you will be following my steps. Just a note here. This is developer Trello website. So actually you need to create another account to access this API key as the developer website is separated from the television production website. It might be weird to just create a new account, regardless. A few clicks, and here it is, you have generated your own private key. Now let's pause the key. The parameter name is key and less positive value we just copied, sent again. Now we have moved further. However, there is a new arrowed unauthorized permission requested. So our key is now recognized. However, as you can read in the API description, you're still need to generate a token. A token will be additional layer connecting our developer API key to the precise Trello user that you created at the beginning of this lecture, but press the token button. And now as you can see, this is requesting our production Trello account to be linked with this particular API key and has been generated, we need to copy it. And of course, pass this token into our request. Now let's send it again. And the request has completed successfully. This is response from Trello. No error was returned. The name was the one that we provided before in the request. And when we refresh the Trello board, we should see a new one. And as you can see, our board has been created only through a request. We have not done any step manually and annual bought has been created. You could have done the same thing manually by creating a new board. However, we have done it fully through the backend, fully automatically via backend requests, API. Okay, so now let's stay a little bit in our board. Of course, there are other scenarios that we can use not only to create a new board, but also perform other actions using API calls. Now, let's look at our request and imagine how we could use this request to create some tests, automated API endpoint tests. Let's create a second request that will be validating that our board is present. We need to get a board. So again, Let's go back to our documentation. We will be looking of course, at the get method of the box. Get, as the name suggests, gets the data. Put and posts provides the data to the application and Delete Of course, materials and the kind of data. So again, in this case, if we want to validate that something is present in the Trello application, we are looking at the get method and in this case, boards, as before, copy the endpoint. Now that we have generated the token and application key, it will be much quicker crosses it is the getMethod, okay? And as you can see, there is only one mandatory parameter ID. And in our previous requests, the idea is the first returned parameter. You can as well copy the endpoint at the top without any parameters. The only difference is that this endpoint will not solve any parameters. You will need to input them manually. Of course, we need to authenticate. So let's copy the key as well as the token and paste it into our new request. Endless tried to send it. Our request has worked. Let's trace back our steps in the request on the left, in the post request, we created a new board. And in the second request, GET using a different endpoint, we validated that indeed the boat is present. If the board would be not present, which will test in a moment, the request would fail. However, now it is successful as the board exists. Now let's add more tests. Let's add the very basic tests, mandating the constitute six to a 100, as well as a test validating that the request response texts contains a specific string. In our case, the name of the bar. Please remember that even if you are copying the tests to the second two requests, the still make sense because each request looks at those same tests as a separate tests. Let's send our request and as you can see, the test was successful. However, now, as before, let's modify our parameters in order to test that the test is failing whenever the assertion is not met. Let's change our birth name to a different one. As you can see, I made a mistake. Assumption expects a different board name. However, the TLC successful. Our bot name is different than the assertion. However, the test result is us past. And here you see will always need to test our test cases assertion. As you can see, I made a mistake and I selected the wrong one. I selected that contains one and not e is equal to, of course, it contains the name of the board. However, it is a different one, not equal. So it's sort of course be equal to the second name. So as you can see, it is extremely important to test the test cases before you assume they are just working. Now it is a bit more complicated as the second test, checking our birth name is, as you can see, validating the whole name. It is not only validating whether the name of the board is equal to our board name. It is checking the whole output. This means that before asserting the birth name, we need to handle the JSON output. Let's handle the JSON response. The first step is to convert the postman response into our JSON 1. Now the only thing left to change is to use our previously created response from line number 6. Let's use our response. And here, due to parsing JSON, we can precisely indicate which field we are validation. In this case, it will be the field name. And as you can see, there is an assertion error that makes no sense. Our birth name is different. Number 1, Let's check the status code. And now when we want to validate a particular part of the text, we need to convert the response into JSON. Of course, the response name is just my name of a constant. It can be any other name. It can be Test1, test one, it can be your response. Your name is just a constant name. However, the important thing is here's that we are converting it to a JSON format, which allows us to delete this one. However, of course, it allows us to specify the field name. And now it will be validating only the output, the value of the JSON field name. Now let's change the expected value again. And as you can see, now, it works just fine. We can add, test for another value. Let's validate. Okay, maybe another exercise. How would you validate item that is one level below? So in this case, we are looking at price and insights prefs permission level. So this will be one level below what we validated previously. Let's edit our test again. So let's try it again. Expect a response that, and look where we want to get prefs because we want to access this particular section of JSON and we want to dive in even farther. So in this case it will be permission level value, in which case we just need to write dot permission level. We will be talking more about parsing JSON. However, I hope that it is even at this stage, clear how we are accessing one element below another. We validate again that the value is equal to private. Let's intentionally validate our test by writing the wrong value. The test has correctly failed. Let's validate the assertion exactly. It expected our private value. However, it got private tomb. And now it should work just fine. As you can see. Now, we have a test that tests an endpoint to create a new board. And as well tests after the board has been created, it validates whether it has been created with a correct board name and validates whether additional parameter is private. Due to this, we have a much better request, not only creating a new board, but also testing that the endpoint is of course alive and responding. But also at the same time, parsing the JSON and validating the birth name is equal to the one being posed in the request, as well as additional parameter is equal to private, in this case permission level. This is a much more detailed tests then we used before. Another interesting flow to test would be to test parameters. For example, that in this case we are saving the name of the board as a parameter. And in another request, we are validating whether the name of the board here is equal to the parameter from the previous request. However, this is also a more extensive topic which we will be covering in yet another lecture. For now, in this lecture, let's focus on those tests we have been doing so far, and also on additional methods. We will live parameters for the next lecture. Still. This lecture will give you plenty to practice on. In the meantime, I would fully encourage you to dive deep into this lecture, investigate parameters, try on your own, providing different parameters, acquiring an API key, acquiring our token, creating various different tests, as well as parsing a simple JSON. Okay, let's copy our existing tests and pasted in the getMethod. Again, please remember that we're testing two different requests, meaning that it is completely okay to copy and paste those tests between two requests. Remember there are two different endpoints, meaning you are not, in fact. Cloud, meaning you are not duplicating the tests because in fact, each test being the same, it is testing are completely different endpoints. Thus, each test is in fact unique and not duplicate despite looking exactly the same between one and another end point. As you can see, our tests created kind of a mess. However, despite the same name, each block has a unique ID. From the front-end you cannot see of course, the ID. However, each one is individual. As you can see that the tests are failing, which of course makes sense because this is our old ID. The first one, we need to copy a new ID, which I need to copy from the endpoint. And as you can see, with the most up-to-date ID, the tests of course, are working and now are successful. This is also important. All the parameters are visible in the end point as you will be entering them into a graphical user interface of postman, but they will be sent to our API in the end point until S bar. So now, due to this quick copy paste, we have two different requests, post and get covered by modern enhanced tests. Of course, please remember that you might create many, many, many different tests for each particular JSON element. It is a good practice, so I encourage you to write additional tests for different elements. You can of course, check in the API doc how to add labels. I really encourage you to go through the documentation and try various different methods and play with the documentation as well as endpoints. For now to end, let's use another method, and now let's use the delete method. Let's delete one of our box. Again, we need to return to our documentation, select Boards section, and delete method related to Bart. As you can see, the request only expects from us the ID of the board. Now let's copy the ID into the end points. So in order to test it beforehand, we expect for now the GED test toward because the board is present. But once we deleted, the previous gets short, of course fail because the bolt will no longer be present. Of course, we need to authenticate before we are able to execute this request so that not everyone can delete our bones and token as well. Now we are ready to send our delete board request. We are authenticated and the board ID has been entered into the endpoint address. The method is selected as Delete and lead centered. Now our previous request fails, and this is completely as expected. The delete method has in fact deleted our board. This is completely as expected. In our next lecture, we will create a more automated flow. For example, to create a new board. Set a parameter with the board ID. Afterwards, check whether the body is present. We will be validating assertion by the name and the last step will be to delete it and check that it has been deleted. We will try to automate such a flow. However, this will be in our next lecture. For this lecture, I fully encourage you to access Trello, sign up and create your own API key as well as talkin, connect, and try out many, many different end points. As you can see in the documentation, there is a lot of different endpoints. So I encourage you to try different methods. Post, get, delete, put some time into the soft tissue, feel more comfortable when dealing with first of all, technical documentation and second of all, with more complex when it comes to real life application, as Trello is in our case. Practice a little bit about parsing JSON, how to access the lower level of JSON. Of course, again, we will still talk about parsing the JSON in our next lectures. However, this is a simple one and I fully encourage you to try it out. Write some additional tests, and play with it. Of course, if you add all of those three tests right now as it is into a new collection? Well, it will not really work as they are not yet fully automated. Bots will be created, but the next one is expecting our board ID to be passed to it and you'll have to manually paste it here. So as you can see, at current stage, this is not yet fully automated solution. Those three different requests are not connected one to another. At this point, the outer and the collection runner will not work for you automatically. It will not copy automatically the ID from one requests into another. However, this is what will be our goal in the next lecture. So at this point, again, please practice a lot what we have covered in this section. And once you are ready, please join me in the next lecture. I will see you then. Bye. 29. Postman part #3: Welcome back to our next lecture regarding Postman and in general testing using requests when it comes to an end points. I hope that shoe reviewed and worked a lot on the previous lectures. And now all the topics mentioned in the previous lectures are familiar to you and do not pose any questions. Please remember as tos might be fairly new and technical lectures to you to spend the adequate amount of time after each lecture working on what you have learned. Do not hesitate to spend a few hours reviewing and also trying different other requests at your own, as well as writing other tests regarding these requests that she will be creating. Any kind of technical testing requires a lot of practice, as well as basically any other skill. So never hesitate to practice extensively, either secured queries or as we are covering now requests using Postman. Today we are moving forward and we will be picking up right where we left off at the end of the previous lecture. Lecture number 20 comes to API testing and we will try to automate the flow. As you remember, we left off having created three different requests using three different methods as well. So we created one using the post method, one using gets methods, and one using lead metals. They were all related to a similar topic, similar functionality to the Trello boards. Post requests created a new board, GET request validated using a board ID, whether such a board exists or not. And the delete after using both ID tries to delete a given board. Of course, each of those requests tested as well, some small functionality. We also converted the postman output to a JSON and afterwards into small tests, passed the JSON to validate the value of a specific field. In the meantime, I also added all of those three requests to our Trello collection that I previously created. You should be fully able to create a new collection, as well as at those three saved requests to the newly created collection. So please go ahead. Of course, at this time, the collection will not be fully functional because as we just discussed, their posts will create a new board. However, the get and delete methods will be expecting a given specified both ID and of course, after deleting the board, the next iteration will not find the board with a hard-coded board, board ID, as well as the delete will not find a board to delete. So let's go back to our requests. We have previously written tests when it comes to two of the requests. So pause and get atlas also add some tests to our delete test requests. For now these are only the basic one to 100. And now let's move on to the very important topic of global variables. In a nutshell, variables are references, references to a string, to a number, or Boolean, Let's say true-false, maybe two alleles. The essence here is to understand that not hardcoded when it comes to the value, is just something that really directs our attention to another place. And also very important, can be overwritten, can be updated, or maybe let's say the value can change. This is a very important concept to understand, as well as a very useful one, which you will see in just a moment. As you can see, we have some hard-coded values, key and stoke, and are values that are hard-coded and present in all three of our requests. We need two each time, copy the value and paste it manually on to each new request in order to Antarctica. But for now, let's try to change this. On the right-hand side, you will see variables panel. We can already start by copying the value of our key trends, the environment quick lookup icon. And you will see global variables, press Edit. And we have opened the managed environments with our global variables. Let's create a variable key and paste the value of the key. And carrying value was filled automatically. We have our first global variable. Now let's do the same with the token. So again, plus the variable icon. As you can see, you immediately see that you already have a global variable key, which is good. Now let's create another global variable, this time for a token. Press Save, and we have our first two global variables. So now let's make use of this. We no longer need to manually hardcode the key and token values in each single new request. Now, let's use our newly created variables in Postman. In order to use our variable has a value. You're simply input double braces containing the name of the variable. As you can see, we have already some suggestions when it comes to variables. And at the bottom we can see our two variables. As you can see now, our key field will be using the value defined in the key variable. Let's do the same with the field token. Let's make it use our token global variable. Of course, what is one of the most obvious benefits when using the variables? Well, let's see at our example, we are having the key end token variable. And let's imagine that we used it in 50 different requests, hardcoded it, and suddenly we have a change and the key is now different. Well, in such case, you would need to update it manually in 50 different requests. However, if you use variable u is simply to update it in only one single place in the variables many, it will be automatically propagated to all 50 requests. Okay, now let's only test again our request in order to make sure that nothing broke, that the variables are working as expected. Let's do the same for our two other requests. Let's replace the hard-coded values from key and the token top parameters. Okay, Let's save and go back to our first request. As you can see, we have just created two global variables, key and token. Now let's go back to our flow. The free requests are not yet connected. They cannot be executed one after another without manually copying the board ID. We have manually input and also the birth name as well as boric ID. Due to this, due to hardcoded values, we cannot automated, we cannot executed time after time because of course, once we create abort, it will get deleted by our last request. And at the same time, running those tests will create a new world with annual board ID. So now let's create a new variable to save the board ID value. And in the following two requests, let's use our board ID variable in order to validate the results. This could potentially already mean that we will be able to run all three of the tests one after another, multiple times, having the board ID variable update automatically. We are trying to create our variable, saving each time the value of the boat ID. This step will be a little bit different from the previous ones, as it'll require us to be written in our test section. On the right-hand side, as you can see, there are different snippets that suggests ready-to-use templates. There is one that will be really useful for us in this situation. There is a snippet set, a global variable. The first part is the variable name. So let's say board ID will be our variable name. The value part will not be necessarily hard-coded. We do not want to hard-code. Pacific value we want to use and dynamic value. So the board ID global variable will be updated every time this request is returning, of course, and your board ID value. As you can see on the top, we already used are similar approach. First of all, we need a key and the key will be the ID as well as name. So now let's use the same approach. Let's write down response dot ID, same as before, parsing the JSON by writing down the response dot name. I, in the name of the part to be asserted in our tests. Here, we will be writing response dot ID, which will provide the value of the board ID into our global variable named Bart underscore ID. Let's test it out by sending the request. As you can see, everything works just fine. However, now, after such request has been sent, we have a new variable we can use in our utter requests, both underscore ID. Let's use our newly created global variable to remove the hard-coded values. In our next requests, we simply remove the hard-coded text and as before, right, in double braces, the name of the variable, in this case both ID. Let's test it out and the test is successful. As you can see, we already see that the flow is working. The first request creates a new board and saves the board ID value into the bolt IV global variable. Second request checks whether the board ID is present and succeeded, meaning it correctly got the board ID value from our variable and verified that. In fact, as such, such a board has been created and is present. Now, let's try to delete this board. Again. It should be automatically sourced from the board ID global variable value, and it has been deleted successfully. Now let's validate that is no longer present. And as you can see, it has been deleted correctly. Let's try to create yet another board with another unique board ID. And now the global variable should be updated. We are expecting the request number 2 will work just fine as the board ID value for the global variable has been updated in the previous request. As you can see, newborn is present. The global variable has been updated by executing request number 1 and will be updated each time the request number 1 is executed. Before we trigger our automated tests to test the whole flow, meaning posts get and delete fully automatically by using our board ID global variable to updates the board ID value each time we need to do one more thing. If we would like to run our outer honor and set a few iterations, it's a good idea to create a local variable instead of global one, we will be creating and fight and vulnerable. As you can see, the syntax is extremely similar. And let's convert our global variable into our environment variable. Let's delete the global variable. As in this set of test cases, we will not be needing such a high level of exposure. The environment variable will be enough. Now, let's finally run our three tests automatically in order to validate that in fact, our environmental variable board ID is being updated. The value of it is being updated on every single around. Let's run a few iterations. Let's send the iterations perform and start the RAM. As you can see, that restaurant has been successfully executed. All the steps have been passed. We have 0 fails. What does it mean? We have four different iterations. This means that in the first iteration, we have created a new board, checked that is present and deleted it. In the second iteration we have created a different board with different port ID, check that it exists and delete. And apart from iteration number two, in iteration number three, we have created, of course, the third unique board. We've bought IT. Of course, it's a different one because the previous one has been deleted. In the last step of iteration two, we have checked again that is present. We have deleted it and repeating the same steps for Thomas. Of course, it's a very simple example. However, I would like you to take home and to understand how in this case, the variable works. Each iteration basically uses a different board ID, updating the value of the environmental variable board ID, deleting the previous one from the previous iteration and updating it with the current one from current iteration after executing the post request. This will be the end of our example. As I do not want to over-complicate it, I would really, really like you to take a moment and work on this concept to fully understand the environmental or global variables, please try to add a different variable. Maybe tried to create a variable for another element instead of hard-coding it. And also remember to start our collection around having few iterations in order to validate that the variable, in fact, is working as expected and the value of your variable is being updated accordingly. Please remember that practice makes perfect. Hello gives huge amount of different endpoints to work on. So you can test really different scenarios, different environment variables, as well as different tests. So please take a moment and really work on these concepts. And as this is our last lecture, please also work on older items mentioned in the previous two lectures regarding Postman. Whenever you have any kind of question, please feel free to post it. This will be the end of our lectures when it comes to using Postman and API testing, using requests and endpoints. As you can see, it is not that difficult once we get going. Once we have the technical documentation, once we have the keys and token generated, postman as an app is really friendly. You can use even ready snippets when it comes to tests. So I fully encourage you to use postman or any other API testing tool, even if you are using mostly manual tests in your everyday job. Really, as discussed before, doing simple tests in Postman can be a life changer. When you automate even simple 200 tests for different end points, you can execute them almost in few seconds. And it's again changer even for everyday tasks for a manual tester, spending a few moments to add other simple tests will have even more benefits, as we've shown in the lecture number 23, when it comes to Postman and API testing. This is the end of our lecture. I really hope that you enjoyed these sessions when it comes to API testing. And I will see you in the next lecture. 30. Complex JSON: Welcome to our next lecture. In this lecture, I would like to talk a little bit more about JSON formatting and how to parse JSON output. We have touched upon this lightly in the previous lectures while parsing fairly easy and small JSON in order to create our test assertions. And in this lecture, I would like to show you how to easily sort, how to easily read more complex, a bigger JSON output, as well as give you an example on how later on we can easily create an automated tests that easily uses the JSON output. Let's begin. In our demonstration, I will be using the Postman application along free to use API endpoints provided by our city communication office, providing the geo locations, geopositioning of current public transportation, meaning buses, trams, trains in a city. I have already created beforehand unnecessary parameters in order to successfully sent a request. So without any further ado, let's send the request. As you can see, the request works. We have received our response. However, we have received such a JSON. We have received some data, however, it is not yet clear. We were looking for job positions of buses and trams and the output is, well, not easy to understand, not clear, or at least not easy to find a specific data in it. Here we've helped will come many free tools or extensions that help to arrange the Bro JSON output into a more understandable, more sorted result. As you can see, we are looking at row output of the JSON, but on the left-hand side, we can use the pretty extension, which we make things already much easier to understand, already formatted in a way, more efficient way. However, let's copy our output and use another online editor. This is the first result that I found while Googling JSON online editor or less space the row output and translated. As you can see, there is a bit of difference how the results are displayed. We cannot easily expand and collapse different levels of our JSON output. However, in this free online editor and probably many, many other, visibly understanding, the JSON output by collapsing and expanding different levels gets much easier. Remember, on the left is the row output through JSON, output from a municipal public transportation containing the buses, trams, along their real-life location. On the right-hand sides, legs expand and see how the JSON is structured. Of course it starts with an object and then the results, we have a 164 results. Now let's expand foreigner. Here we see 1990 results of course, because we are not seek all of them. However, after expanding, all of them are present because of course we start with a 0. Upon expanding given element, we can see the last level has been reached and we have five new elements. The first one is latitude, the second is longitude, time, line, and number of brigade. As you can see, we have a 164 similar outputs. Basically, each one of those is our unique bars are unique, Trump and contains the location of the vehicle at the time of the request. Of course, we will get some similar lines. However, those vehicles will be unique simply in different locations. However, let's not focus too much on how the application from the public transportation works. Let's focus on our JSON. Let's focus again on the results translated from the raw output, which looks way more arranged and is much easier to understand when you are looking at an output for the fence time. Of course, let's mark some points. The number of the results will change. It will not be constants, so you cannot have it code, for example, one hundred, one hundred and sixty four iterations. But the data provided in it itself will be constant. So we always get a latitude, longitude, time line and the number of 10 Brigade. Now that you understand how to translate, how to visually help you understand and output from a raw JSON using our free editor. Let's move a step further and let's look at a real life situation. How to use such a data upon successfully translating it and understanding what are the data contains, how to effectively use it in order to test an application using this output. As mentioned before, we have our main object and lower level consists of a 164 elements, each one containing five different fields. Of course, for example, if we would like to access the line number 6 highlighted here and see the associated latitude and longitude, we would have to select the third element of the result. Now the question is, how do we, how can we effectively, in an automated test, point out the latitude and longitude values of the third element. How do we do this? For this, I have created a small example on how we would parse such a JSON in order to retrieve specific values that can later on be used in a real-life test. I have written this in Swift, however, of course, this applies to other programming languages as well, and we'll be probably quite similar. So point number one, I am creating a constant of type JSON because of course, we need to somehow save this row JSON output. This will be created directly from the request response. Please imagine that lines JSON constant is equal to this. What you see in a row JSON output, if you print out this constant lines JSON, you will see the output as rob Jason. Next, let's look at point number three as point number 2, as you can see, relates to the function created in point number 3. In point number three, you need our function to handle the JSON parsing. As you can see, I have created a function named updates lines data of type JSON. This function contains a logo designed to handle this particular output. I'll hope will ensure in this case that regardless, if we get a 164, results are maybe 10. All of them will be handled. And of course we do not need to hard-code and a specific iterations number. Naturally, if you hard code iteration value, in this case a 164, and this value would change at some other time when there will be more or less public transportation vehicles and the time of the request and response. Well, of course the application would crash as it will be either not enough or too much results to handle. This is why I used a loop from here on now, I would like to ask you to focus mainly on the right hand side output. Once we go back to the screen, as we will be focusing more on the arranged on the sorted JSON output rather than the row on the left-hand side. So again, please focus on the right-hand side, sorted JSON output. Let's look again on the hierarchy. We have an object below our results. And the results we have a 164 different elements and each one of those contains five different parameters that we will focus on. Now let's go through the function itself. I have created three variables. They are not constant, they can change. This will be the main focus of our function and easy example on how to parse JSON to retry specific values that you are interested in. The parsing part of our function will be assigning the JSON values to our free variables. In other words, we have free temporary variables. Number of the line, latitude and longitude. And we would like to assign the latitude, longitude, and number of the line for those two values. So again, please look at the hierarchy. We have the object, the result, and we need to access the first element in this case. And only here we get the longitude, latitude, and the number of the line heirarchy in JSON and parasitic it is crucial. Next thing to understand is that you are looking at key value example here. Key will be latitude and the value will be 52. Again, key will be longitude and the value will be 21. The same goes for the lines. Lines will be the key, and 28 will be its value. I would really like you to focus on this simple example. Each of those final objects will contain a key value pair. This is how the parameters look in JSON lowest level. Let's go back to our function. Let's look closely what happens and how we parse our JSON. We use the previously declared variable, temporary line. And let's assign a value to it. Of course, we refer to our JSON that has been created previously. And our JSON is created from line JSON, meaning from the Raj's on output. And now we need to dive in deeper. So again, we go back to our variable. We prefer to our full row out JSON output. Now in go into the result. As you can see, we are here and this time, if we leave it at this stage, of course, we cannot assign a specific value because we have a 164 more elements. So the application will not understand which value we are interested in. We need to go one level, lower, one level, deeper sum. Let's do this. In this stage, we need to indicate the element we would like to go lower into. So if we have a 164 elements in this case, who'd like to go over each and everyone. Thus, we need to iterate. Iteration num will be simply the number of the iteration. So it will start with a 0. The next generation will be 1, 2, 3, and so on until we reach the end of our loop. Of course, the iterations would start with a 0 and go to the last possible iteration in our loop. So in this example, instead of looking at the iteration num, Let's imagine that we have 0, which of course, in the next iteration or changed into one, the next one into a two, and so on, so on until we reach the end of our JSON and the loop ends, we are located and the 0 hierarchy level. Now at this stage, we see five different key value pairs. However, we still cannot assign specific. Latitude, longitude, or line number 2, this single variable. And this level, we simply need to point which key are we interested in, are more likely in which value of a specific key. And we interested to assign it to our variable as our temporary variable is temp line. Of course, this is looking into the lines of value, lines key value. In this case, we simply need to pointed into the lines king. So as you can see, this is a very easy way to extract precise of variables from a large JSON output. First, we need to point the JSON row output itself and afterwards, dig in a little bit deeper. In our case, we select result. Afterwards. To make the code smoother, we select the iteration number and followed by the precise variable that we are interested in. In this case, we need to point to the lines key, which in fact will result in the temp line being assigned the value of the key lines for the number 0 result of the JSON row output. Once this line has been executed, the string value will be equal to 28. Going forward, we are assigning values to the latitude and longitude following the exact same JSON parsing method. We are looking at a 164 results. We go into the result. Then we follow with the iteration number, which will change. Of course, for example, the second iteration we will have a number one. And we point the precise key. In this case it will be latitude, meaning LET. And due to this, the precise value of this key will be assigned to our previously declared variable. The end of this function increases the iteration number by one. In general, the JSON parsing can be looked like a tree in which you need to go deeper and deeper until you have reached that precise data that you are interested in. Our last line is an example of how those variables can be used in real life application, we are using the free variables in order to create a new object. Which parameters will consist of our three variables that you have just created and passed from our old JSON. Keys do not focus too much on the object creation part as this is just an example of how you can use those parsed JSON variables. The main thing to focus on is how do we parse JSON in order to assign a specific value from JSON key. And of course, do not forget about our online editor or any other editor that you find regarding JSON. On the left-hand side, you see a raw JSON output. On the right-hand side, a much more sorted one and easier to understand output. Adjacent editor will also help you a lot when you need to write the function on how to access evidence specific JSON key value. Sorting. Row JSON editor will also help you a lot to visualize figured out how to access precisely the JSON key value that you are looking for. Afterwards, parsing JSON variable be much easier when using JSON editor. Of course, you can also use any JSON editor to simply Paris and outputs even when testing manually. When testing Manuel and you will still be dealing with JSON outputs. And you could look it up quickly in any kind of JSON three online editor. Of course again, please remember that this particular website is simply the first one that jumped out in Google when I type JSON online editor. There are plenty more, maybe better, maybe worse. This is just an example of functionality. In this example, postman has built in editorial, however, it cannot easily be expanded and collapsed. Thus, an online editor makes sometimes sorting larger JSON outputs easier. This is the end of our lecture. Let me know in the comments, how is your experience with parsing larger Jason's? And I will see you in the next lecture. 31. Useful sources: Okay, so let's begin our next lecture. In this lecture, as mentioned before, I will be sharing with you a few useful services, tools related to everyday software test and work days. My tip number one will be for Manuel software testers testing web browser based applications. And the tip will be, whenever you are executing manual tests on a web browser is to enable the developer tools, especially focusing on the console and Network tab. So whenever you are faced with a functional issue in a browser application, it is a great idea to check also what is happening in the developer tools in the console or network tab. Many times you will see a clear error in the console tab or in the Network tab, you'll see one of the HTTP error codes mentioned in our previous lectures. For example, 40, 40 or 50 free. Providing such info in a defect report, in a vacuum report, along all the other information can really speed up the time needed to resolve the issue, as well as it will get you some bonus points from the programmers, as this will be a nice thing to check and attached to the report defects making everyone's life easier. The second tip is kind of related to the first one. And it is to always have somewhere in your browser HTTP codes, cheat sheet opened. While there are many obvious and common HTTP error codes we encounter, for example, for our four 500, 500 free, there might be from Time to Climb HTTP error codes that are not that obvious and we might not be sure what it means exactly. For example, the HTTP 409 code. In such a cases, it is always important to have HTTP cause cheat sheet where you can easily and quickly find it. Of course, there are many websites that can provide such cheat sheets. For example, http status cells that come out of many other websites. My next tip is a tool, and it is a screen recording tool for tests. Evidence recording while taking screenshots on a desktop or mobile is quite easy on most of the operating system. However, screen recording can be quite more difficult. And dedicated application will often also come with built-in tools for modifying the output video and also allowing additional edit tools. An example is a tool called snag it snack. It is a kind of all in one tool that lets you capture, but also effectively added all the captures. However, of course, there are many, many other very good applications. So this is simply an example. However, I would really advocate for all software testers to have some sort of screen recording dedicated tall as it will probably prove more efficient and also more convenient to use, especially if in our daily life, we are capturing a lot of different screen recording screenshots and test evidence in general, this will speed up your everyday work. My next tip is about a very important source for a tester. And it is documentation repository. Whether it is the occlusion confluence, HP, ALM, or some other kind of repository, for example, SharePoint from Microsoft. You should, as a tester, always have in an easy to find and quick to find most up-to-date functional specification of the application that you are testing. And in general, the repository for the documentation itself. Whenever you have any kind of doubt in the application, if the application is working as expected, it is vital that in such a cases, you can quickly find the latest, most up-to-date documentation. Thus, whenever your application, your team documentation repository is located, I would always suggest to have it either pinned in your browser or opened in some kind of other application. As mentioned before, it is vital that you can access this repository quickly and easily without asking people around whether it's our documentation repository and frantically searching your emails to find this one email with the repository address. Now we're moving into a little bit more technical tips. The next tool that I would suggest that every software cluster should have installed on their desktop is our SQL client. In order to easily connect through the test application database, you need a secure client. Even if, at this point, as a monomial tester, somehow you are not using the database to validate your test results. You should, in my opinion, still have a SQL client installed on your machine. And on top of this, in my opinion, the C-Cl client should be already configured so that with just a few clicks, you can quickly connect to the specific environment database, execute some basic queries. This might come in handy when there is a crisis or maybe some kind of critical production issue. This will allow you to verify some data on the test environment that today's. Now let's move to our mobile application software testers. For a mobile application software testers, I would definitely advise to have on your local desktop machines, either Windows or Mac, installed some IDE. Ide standing for Integrated Development Environment. If you are testing an Android application, I would suggest installing the Android Studio application, Android Studio IDE. And trends todo id has a built-in device emulator which allows both to build application from source code as well as installed packages. So whether you have access to the source code of the application that you are testing, or you simply receive a package to install on the device. Both options will be available to install on the Android Studio IDE built-in device emulator. This will allow you to. Of course, run the application on the emulator on your desktop machine. However, you will have easy access to live logs. At the same time, you will be able to take screenshots is a video recordings for tests, evidence. It is very useful just as a good practice reminder, please remember that final SAT testing should not be performed on any kind of emulator. It should always be performed on the end line device. Meaning if it's an Android app, of course, it should be performed on a real device, not an emulator. However, before the SAT phase, it is fair game to use the emulators to speed up and make more easy you're testing. We have talked about Android native app testing. Now let's move to iOS native app testing. The idea of your choice will be, of course, Xcode. It also features built-in device emulator. As long as you have access to the source code of the application, there might be a possibility to your test flight. I have not tried running an emulator and downloading test application from test flight. This is something that you might try. Of course, it is also useful to quickly test some small features or maybe even do a Zoom or Skype screen-sharing with the emulated device being easily visible to the whole team on the meeting. However, again, the disclaimer, if you are testing a native iOS application, you should not be using any kind of emulators for an end user testing or SAT, official testing. For this, you should always use iOS device. Okay, So staying with this topic of mobile testing, now let's look at testing on a real life phone devices. As mentioned before, there will come a time that we will have to stop using emulators and move to testing on a real phone devices. For example, in the SAT face. In general, testing their mobile app on a real life phone device can prove a little bit more difficult when it comes to screen-sharing. For example, with the team meeting or on a sprint retrospective meeting during the demonstration session. Here, we can use applications that help us deal with this using a USB cable or a Wi-Fi connection, the phone screen will be displayed on your local desktop. In real life. The difference between this and an emulator is that such solution can be used in formal testing. Well, as we are testing on a real live device, while at the same time displaying the image on your desktop, which makes our life much easier if we want to show the application on ascribe, Zoom call, or Record Test evidence. Some applications, examples are visor for Android, iPhone screen mirroring for iOS. But naturally as before, with the screen recording, there are many, many more applications. So simply Googling around and try to find the one that suits your needs the best. Just Google iOS, Android screen mirroring desktop. And you should find several applications. We are now approaching the end of this lecture. We have just three more points to go over. The next point is about API testing. If your tests require API testing, you really need an app for this postman or soap you, I will cover those needs. 20 comes to API testing. They are complex applications and we'll provide not only a way to test single requests, but also provides a way of automating the flow and automating, testing multiple requests in a flow. Postman is application that you should already be familiar with due to previous lectures. However, QI is kind of similar application, but in my opinion, simply a little bit less user-friendly. However, as always, this is down to your personal choices, personal preferences. So why not give it a try as well when you are reviewing our API lectures, the next tip is about logs. Regardless, if you are testing our mobile application, our browser application, the application still will produce some logs. For this, you should always have an application that makes logs reading easier or maybe even visualizes the results. Kibana is one of those examples and gloves you using simple queries, find precise logs for the time went on a road, a potential error occurred. It is also a very powerful application tool that can easily visualize different components from the log as well. You can set up alerts and other kind of more advanced queries. Doing so can give you precise data on any kind of errors, as well as alert you or the whole male increased when something unexpected happens. And application logs show these accordions. And our last point that I would like to touch upon is kind of suggestion. Unfortunately, something that many testers forget about, forgets to use. And it is existing automated tests of our application or weld applications that you will be testing. Many times, new testers will join an application. Well, the team developing the application that has been in development for many years, you are either developing new features or basically maintaining the application with small updates. Often the app will have some automated tests in Jenkins or other similar tool. For example, Team City. You can trigger an automated tests, but also check, test Tran status, whether it is running or completed. And of course afterwards, check the end report to see if tests were passed or failed. What I would recommend is to make use of those tests. They are not running on our local machine. And apart from starting them, if they are not configured to stern automatically, they do not require an effort from a software tester. Signs. I really recommend to use them often. For example, every day at the start of the day, kickoff, the tests. Go for a coffee or static checking your unread emails and afterwards simply go over the automated tests, report to see whether all the tests have been successfully passed. Or there are some phase. This way we will everyday know that given set of tests passed and you can focus on testing gap without worry. Of course, the ideal way would be to expect that all the tests pass every day. This way, we will every day know that a given set of tests has been executed and also completed successfully. They are passed. And we can focus on testing the application without worrying about the given set of progression or maybe smoke tests. This will give you a peace of mind as well as provide a chance of spotting are critical error. Well, on the beginning of your day, giving to the whole day to collaborate with the team on fixing the issue. And this is the end of our lecture. I hope that you enjoyed those tips and suggestions. I will see you in the next lecture. 32. Does each tester need to start test automation?: Hello and welcome to our next lecture. In previous lectures, we have already discussed MANOVA, software tester, having one of the possibilities for a career step up, for a career promotion. Being test automation, being getting more technical. As test automation requires, also having strong fundamentals as a software tester. Thus, it is best if candidate recruiting for such positions has already some Manuel software tester experience. This makes current manual software tester, with few years of experience an ideal candidate for an automation tests that at all. Today's question might sound simple. What about Manuel software tester? With already a few years of experience and solid fundamentals, is test automation something that every experienced manual a software tester, needs to start with doing one day, even if they are perfectly happy with the current manual tasks and no not wish to change anything. Let's discuss. So of course, as always, we are going to be talking on examples. But just please keep in mind that it might vary from case to case, from one employee to another. Of course, we are talking about, UH, Manoa software tester with a few years of experience and whether it is mandatory or not to one day become a test automation testing. Of course, I know. And please keep this in mind that also someone without any testing experience but with programming skills can become a test automation software tester. As I said before. In my opinion, such candidates, we also require a lot of work of training because of the lack of testing, fundamentals of basic understanding of how a test case should look like, how a bug report is created. And many, many other skills being learned as a Manuel software tester. However, yes, of course, I acknowledged and I know that you can also start our technical software testers role right out of college, right out of the box when you have learned programming anywhere, a skilled programmer. However, for this example, let's continue with our experienced Manuel software testing. Let's assume our software tester has 34 years of experience as a manual software tester. The software tester in question is perfectly happy doing everyday tasks. So as we said before, being in an active angel is Sprint, taking part of all the ceremonies. Of course, analyzing the requirements, creating test scripts, reviewing test scripts, executing test scripts, wherever needed, reporting defects, retesting defects, and so on and so on. So again, the question in such an example, which believe me, is Something that occurs often in many companies do their years of experience for this test are kind of proof this person to becoming an automated software tester. Even if this person likes their current role and do not wish to change anything. Or maybe those are also the cases that I have personally witnessed. Maybe the tester actively dislikes test automation, actively dislikes programming, and it does not really want to have anything to do with it. What about such a case? Will be anyone for things such as software tester for test automation, or will they just continue doing what they are doing? Here? We need to take again a little sidestep and explain the current market, the current IT market. Nowadays, more and more companies are going into the test automation direction in general, of course, this might mean creating automated test smokes created, creating automated tests regressions. Not all 100% tests will be done automatically. However, more and more is being done automatically, more and more testing is being automated. This means that if you are a completely new tester joining software testing company, there is a high chance that even a junior level interview, you will be asked about test automation. For a junior tester, it is perfectly fine to not know how to write a loop or answer some other technical question. However, be prepared that nowadays, even junior tester intervals have at least one question about test automation. And the recruiter will ask you in general, what are your thoughts about test automation? Where do you stand on it and what do you see yourself in the future regarding this specific topic? So as you can see, nowadays, if you are just starting out, you're testing career test automation is something that many companies will ask you about and also try to involve you in from the beginning. Such a case is not everywhere, in every company. So even nowadays, recruiting for a first software tester job, just starting your career as a tester, you will still find many opportunities to work only as a manual tester without having to do anything with automation. Coming back to our example, we are looking at our experienced Manuel software tester. My first example of a company will be a company that is pushing hard for test automation. Test automation in general is very fruitful and makes a lot of sense. I remember in the old testing days, there used to be big, big regression teams. Testing's which only purpose was to execute a regression testing. This meant that those teams were responsible to execute a regression tests run before each major release. This meant, in other words that let's say 10, 15 people. Of course, this can scale up and down depending on the company size and application size. However, let's assume 10, 15 people were only dedicated to manually testing the same kind of tests, executing the same test scripts, let's say every two weeks or every month. Well, you can see as this can get boring quickly, as well as it sounds like a waste of money. Those testers are not analyzing any new requirements, are not actively testing any new requirements by of course writing the test scripts, executing tests, reporting defects, and so on. They are just sitting and every month executing for, let's say 12 weeks. A lot, a lot of alerts the written and already executed many times before the same test scripts. In such a cases, test automation makes completely sense and the company is going to probably push those people to start test automation. They will assign, let's say, a few experienced test automation testers, test automation candidates that will kind of introduce test automation to the whole regression team. That will oversee test automation. That will, of course, right, the most difficult parts of the code, parts of the testing framework and the rest of the team can slowly learn and learn more about test automation. And together, this whole new team can write the same tests that were being executed manually, that aggression tests into automated once once done. The same regression that has been done by 15 team members can be executed completely automatically with, let's say, 12 testers overseeing the process and maintaining the automated tests whenever needed. Because of course, you need to maintain the automated tests. It's not like you write it once and the automated tests works forever. Application changes, website change, IPA services changed. So you will need to maintain those scripts. However, 2% versus 15. Well, for the company, that makes a lot of sense, doesn't it? So this has been our example number 1. And in such example, probably even if those 15 software testers, Manoa, software testers that we're doing the regression testing want to continue doing this manually. Well, sorry, Martin, the company's approach is to completely automate integration testing. Thus, you need to learn some basic test automation. You need to put some work into learning programming. Of course, they are not going to give you one week for this, it will be a gradual change, however, in our example, number one, yes, even a software tester that is experienced, that is a manual software sister. In such an example, if the company decides to move into an automated regression, automated testing, well, if you are in such a given team, you will be kind of forest to start test automation, whether you like it or not. Let's move to our second example. And in my personal experience, this is the most common case. Our second example will be a company that wants to move to a fully automated testing. Let's say regression smoke testing. However. Well, the reality is a bit different. Also, you will get some test automation questions, do recur interval. So it looks like the company being some business, like they mean to automate tests when. It's my second example is about those companies that really kind of want to do it, but they just lack the time, like the Navy, proper plan to do so. Often those companies want to move into test automation, will want to start pushing the employees into test automation. However, the everyday reality check will make it impossible, often simply due to lack of time, deadlines and the amount of manual tests that needs to be executed and cannot be postponed due to the team learning test automation. I've seen many, many companies and teams that we're struggling with it. So the team, what kind of start teaching experienced manual software testers, test automation. So basic programming skills, how the test framework works, how a very simple automated task looks like. However, all of this takes time. And if the team is really busy, that team is really engaged into current, let's say SAT or current edge. Manuel sprints, well-done. They will have like 30 minutes, maybe one hour a day to sit down and look into this. And if you ever started programming, well, it's not allowed 30 minutes a day, one hour a day, when you are thinking about all the other stuff that needs to be done today, all the manual testing. Trust me, it's not allowed in such approach. One day turns into one week, one week turns into one month, and one month turns into one year. We are one year later. And the test automation, while the approach of the company, the test automation approach to automate all the tests. Well, in reality, it is what it is and the approach has not really worked. The manual testers are busy. Well, doing that job, working on active sprints, working on active SAT testing. They are trying to learn something during the day about test automation. However, often it will go very slowly. And in my opinion, it will just lock that push like the coordination and lack a clear plan how to introduce and change this manual testing into an automated one. And this is our example number 2. So in such a case, even experienced software tester that is currently a manual software tester. Well, even if the company says that they want to change his current role or harris current role into an automated one. Often it will take a long time, if not years, to actually do so. So if such a person is not happy with test automation, does not really want to do this, then. Well, they can remain happy in this company. As I explained, in most of the companies, there is the wheel, but they are not actively at changing to fully automated testing. So such that the study will continue to work as an experienced manual software testing. Our example number three will be companies that are not really paying any attention to test automation. Often those will be a very large old companies. Those companies have been doing software testing for years. Often any kind of change is not welcome in such a company. The budget is there, the regression team is already there. They are doing avid amount of degradation testing. So why, why change anything? Why suddenly hire a very expensive test automation lead to introduce this automation to this regression team and teach those people for, let's say six months. Often those companies will ask the question, why, why, why should we do this? Our current test approach is working just fine. First SET the year AT then that aggression and release to the production. So why change anything? And this is our example number flee the y changing, I think type of companies. Of course, in such a case, our Example software tester will continue manual testing and no one will bother this. Manuel, experienced software tester with any talk about test automation. So to sum up, as you can see, whether test automation will be forced on a manual tester will depend heavily on the type of company that you will be working for. However, in my personal opinion, more than less companies will not do this quickly with either do it very slowly or not at all. Of course, in my opinion, this is a mistake. Test automation introduced properly in places that makes sense, is perfect and makes total sense when it comes to software development. And IT in general, I would like to calm down all the people that are nervous because I met in my career, a few experienced software testers that we're actually nervous about, test automation. They really didn't want to do this. They really didn't want to live in it. They were completely fine with manual testing and they were kind of stressed about the future. In one of the companies that I worked for previously, there was even a strong management push with unofficial memo. Official note that every Manuel software tester needs to start learning programming asap. And there will be a grace period, let's say two weeks, three weeks. And after this, if there is a software tester that has not started learning programming, well, there will be no place in the company for such a tester. So either you start learning programming out of basically you're out. Well, what happened in reality was our example number two. That was an email that was a deadline. And then weeks past six months, past nine months passed, and no one was validating this. And the test automation did not really move forward in any reasonable way. Too many things to do, not enough time to do. And manual testing kept on going. People who started learning programming, started learning programming. People who didn't, didn't. There were no consequences for this. So my advice is that Indians, this is your decision. Personally, you know me, I would totally advise anyone to try starting to learn programming, starting to learn more technical skills, not technical testing. And then just see how it feels. Please just put more effort than one weekend. Then one week, I would say please try even different programming languages, even different technical testing like APIs or advanced secure for at least a few months, give it some time. And then only then if you really feel that this is Hollywood and you would never want to do something like this then, then, then just don't find a company that is fine with it and continuing doing the right Manuel software testing. However, if you enjoyed it, if you like it, then my other advice is to either talk with the company to move into an automated tester role. If you already learned program, a few programming language basics, a few testing framework basics, you are proficient in. The skills, then either electrode yourself to the same command, automation testing, or if the company is stubborn and you can see that automation testing is going nowhere. Well then change the company. This is what I did and I've never regretted it once. Of course, just an afterthought. Often, changing your role from malware software tester to automated software tester comes not only with contracts, job title change, but also with significant pay raise. Often is 50, 40% pay raise. And this is it for our today's lecture. See you in the next one. 33. Different Test specialities: Hello and welcome to our texts lecture. In this lecture, we are going to be talking about how software testing is the fact different when working in a different speciality sector company, let's begin. Through my career. I had the opportunity to work in different specialties sectors when it comes to IT, software development. This has given me the opportunity to now share with you all the insights and points on how choosing a different speciality company to work for. Make a software tester everyday look differently from one sector to another. Each different IT, software development sector will offer its own unique challenges as well as benefits. Let's start by the first, let's say especially the sector already discussed in this course. So it will be videogames testing. When we are talking about video game testing, we are talking about all the video game companies in general. So mobile phones, tablets, game consoles, PCs. We are talking about all of those companies, As stated before, this sector will, in my opinion, be the easiest one to get into as the first software testing job, you will have significantly less daily tasks when compared to desktop or browser application software testing. Most often there will not be an SAT, official test execution. The test scripts will not be as detailed. And in general, you will just have more time for exploratory testing, defects, creation, retesting defects, and getting familiar with the very, very basics, fundamentals of software testing still, as a starting place, I highly recommend this sector for new joiners. Just make sure not to work too much time in this sector, in my opinion, after one to three years, it's a very good move to move to a more challenging company, more challenging software testing around our example. Number two will be retail sector. An example would be testing mobile application, mobile written application for shopping, for example, Walmart or Tesco mobile application. This role will be more challenging than a video game tester. In this role, the tester will already have to be familiar with creating test scripts, reviewing test scripts, executing test scripts. That will be the official SAT and UAT phase. Probably that will be an Agile team, our sprint spring ceremonies. And in general, the tester will need to check more in details when it comes to the application. So, for example, network calls when it comes to reporting errors, as well as. Execute some basic security queries to find the data in the database. Apps in this sector are kind of straightforward. However, as you can already see, this is visible significant step up from a video game tester as working in a retail software testing company will require the the software tester to execute many more men in different than interviewing and testing daily activities. So this is also a nice progression of your career. Now with example number 3, we are moving into more generalization when it comes to the companies, and we will be focusing only on sectors. Sector number 3 is a startup company. I know this is a generalization, but of course, when it comes to a startup, we're talking about a small company that is trying to conquer a new marketplace. Typically those companies, of course, are small, but also often they will be quickly expanding, thus creating great hiring opportunities up examples, facebook, YouTuber, and revolute. Now, startups as a sector when it comes to software development, have our unique strategy when it comes to hiring. They are most often trying to hire the best of the best. And they not really pay that much attention. It comes to the costs when it comes to the salary. Of course, we are talking at the expansion cycle of a startup. That's why I said that these are great hiring opportunity. As during this phase, often, as mentioned, the companies will be looking at the best of the best and brightest of the brightest and any salary that you request. As long as you are meeting all the criteria in a candidate, then the startup is looking for. Well, potentially any number can be accepted by such accompany. But it comes to the companies. There are many other benefits. Often the workspace will be quite new. You will have top of the line hardware, top of the line desk, top-of-the-line chairs, lunges, whatever there is nowadays, the new and brightest startup companies, they have a lot of money and they want to make the employee feel at home, feel and create and the office. When it comes to the skills required often, well, as I said, started to be looking at the brightest of the brightest. Meaning if you are recruiting as a software tester, you need to have all the fundamentals of software testing. You need to be proficient in English. You need to understand all the processes. They will 99 percent B into agile methodology. So you need to have a strong understanding of HI or the sprint ceremonies and also. Most often those companies will not really segregate into only Manuel and only automated testers. They will probably go into a hybrid mode. So probably all the software testers will need to have some technical skills, secure programming, API testing. This will probably all be requirement when it comes to recruiting into a startup company. The next sector on our list is finance. Finance sector. Often dogs companies are huge. Banks, brokerage, loan companies, stock market companies. Here, the software tester, everyday work does not differ from any other previously mentioned specialized sectors. So of course we will be conducting SATs. Uat is maybe executing test script creating testlet, analyzing test data. However, here, the difference will be in the skills that a software tester needs to have, the knowledge required for your daily tasks. The testing tasks will differ when it comes to the previously mentioned other specialty sectors here in finance, you will already need to possess a special skills. As always, let's use an example. Let's look at a software testing role in a bank here, in comparison to the startup, there will be probably a distinction between manual and automated datasets. For a Manuel software tester, you will of course need to have all the testing fundamentals as well as some basic technical skills when it comes to, let's say, basic SQL queries, as well as understanding and reading network coats and error logs of an application. However, as a software tester, you will also need to have some finance skills. Remember, you have to think now a finance application. This means most often that the product itself is complicated. Apart from testing some very easy and very straight forward test scenarios, like login or maybe creating a new customer, new account, or maybe checking your credit count in your account. You will also need to test specific finance test scenarios. Creating a new loan, testing the loan installments, interest rates, auto maybe late fees. The interest rate. If you add to this testing stock market components, well, then it suddenly becomes quite a big deal for the even experienced software tester that unfortunately has no knowledge about finance or financial instruments. Test script execution, pretty quizzes will often require much more effort to test scenario. As an example, let's take a scenario with accustomed item that took $10 thousand loan for 36 installments and is now three weeks late on the installment number 21. The test objective here might be to check if proper e-mail proper documents have been generated and sent to this customer, as well as if they're late fees have been generated and applied to the outstanding balance of such a customer. This was a simple example, however, you can already see that while working as a software tester in finance specialty sector, the test cases in general will often be much more complex and often require a specific math or the quantity skills from a software tester. In finance sector when it comes to the application end-users, it's kind of 5050. What I mean by this is that 50 percent of the applications that software tester will be working on will end up for end-user usage. For example, on Appstore. And the customers will be your everyday users. For example, people who use banking applications, people who use stock trading applications, et cetera, et cetera. However, the other half, the 50 percent will be for internal banking, yours. As an example, we can take stock trading application that will be only available for the banking employees, or maybe an internal back-end application that will only calculate a risk for a given transactions. Last mentioned about the final specialty sector is that well financed often means big payouts. Either your regular Every month they sleep, or your yearly bonus. In finance, often, those numbers will be much higher than in other sectors, for example, in retail. Now let's move to the next specialty sector. And in my opinion, the most difficult one. And it's pharmaceutical codes. This means testing software for medical companies like Genentech or Roth. Here it's important to mention from the beginning that pharma companies develop most of its application for the in-house use. This means that the application will be later on used by these companies, employees and will not end up for general public use. For example, on an App Store or Google Play Store that will not end up there. The application will be used by laboratories or other medical research and development staff working for the same company that you are working. The next important point to remember is that in my opinion, this specialty pharma sector is the most stressful sector to work in as a software tester. Making any kind of mistake as a software tester while working on a farmer project. So for example, not testing for early enough, or maybe creating only three out of a possible five testlets scenarios. To cover a given requirement. Thus missing to test scripts, scenarios, and missing potential defects that will go into the final version of the application. Well, it can mean that real people are going to tie. An example can be drugstore machine that we'll be using your software to insert a specific drug amount for each patient into appeal. This can make working in pharma as a software tester extremely stressful and very difficult when you have a very complex diagram for a given application requirements. And you have been checking it for the 10th time in order not to miss anything. This is something to remember. Really, while working in a farmer specialty sector as a software tester, any, any kind of defect that sure. Let flow that you do not catch, do not report. Well. Most often it is a critical one. Also, many of the projects due to possible critical consequences of any kind of testing error are validated. Projects more about violated projects will be in the upcoming lectures. However, just to let you briefly now, what does it mean? It means that you as a software tester, will have a dedicated person that we'll be looking well. At your every move as a tester will be double-checking your work, but in an official way. So to recap, personally, I have been working almost two years for a pharma company and I can fully recommend it. It's a great job when it comes to work. There are many talented IT professionals working for the pharma companies, as well as it is rewarding when it comes to the salary. Many like also the feeling that it's actually one of not that many companies where at the end of the day, after a hard day at work, you can feel like you've actually done some good and some meaningful work helping someone get better. For example, if you are testing a new software for an AED machine to resuscitate people. However, do not forget that N1 thinking about joining or switching to a pharma company as a software tester needs to think about this twice or maybe even three times. As, as I said before, this for sure will mean out of stressful work. And a lot of very, very important work. Also, any kind of mistake that you make can hunch you after even several months. And we've come to our last sector example. And it's the niche, specialty sector is the uncommon speciality sector. What I mean by uncommon and special software development. For example, companies like addition or mining companies. Nowadays, all kinds of machines require software to operate them precisely. Thus, also software testers. However, the challenge here is the same as with finance. While testing speciality machine. You kind of need to understand this speciality. Let's use an example here. If you are testing our machine, may be a motor that will change the velocity of an airplane or the angle of a wink? Well, maybe it's a good thing to understand in general the aerodynamics and how our link should work upon different pressures. Same goes with our second example, mining when testing mining machine. Well, it's good to understand a little about the ground and geology in general. However, if you ever find a company looking for a software tester with speciality that you are familiar with. This will be a great opportunity as this will also put you at the top for a very shortlist of candidates. As well as it will be obviously something that you are already interested in. To some of those were just a few of the speciality sectors. You can see now how working as a software tester for all of those companies can pose different daily activities as well as very different challenges in everyday software tester life. Software testing, as you can see, it does not mean the same thing simply based on speciality sector company that you work for. And this is the end of our lecture. See you in the next one. 34. Validated projects: Hello and welcome to our next lecture. In this lecture, I will go over project validation scene from a testing perspective. So project validation, we will talk over what it is, what it involves, and how everyday software tester day looks like while working on a validated project. Let's begin clustering validation. What is it? Well, in simple words, project validation is an additional layer of security, is an additional layer of making sure that the end result, the end application Is and the highest standard is of the highest quality. Product validation will most often be observed in applications that directly impact human life. Whether it will be a software for a hospital machine, may be a direct machine at the drugstore or something with directly human life involved. For example, our first innovator. And a defect caused by such an application can have huge consequences for the company. Thus, the company prefers to pay more money to hire an additional person or team that will be checking that various things on the projects are according and up to the highest standards. Now it is important to understand that a validator or the validation team on a project is not only dedicated to checking the quality of software tester job of Europe. Basically, everyday tests. We are going to be talking about violated projects seen from the perspective of a software tester. However, please remember that a validator or validation team does not only focus on your other software testing. Of course, they will focus a lot on software testing. However, they will also pay the same attention to the programmers as well as, um, business analysts. So in general, to understand the role of this person of a validator, it's not only limited to validating software testing. It's as well validating programmers work as well as a new functional specification, for example, document. So BAs work and business analysts work. So from now on, we are looking at a validated project from a only software tested perspective at all. The overall concept seems to be very simple and straightforward. We have a software tester who is being closely watched by validator in order to make sure that the test scripts, thus the final product, is of most high of quality. Now let's dive into more details to fully understand. How are validated project impacts our software tester. From a software tester perspective from the validator will contact you whenever there is any problem with the work that you do. You are not waiting for any kind of green light to start war contest scripts. You do your everyday job as you would do on any other projects. So of course, you analyze the functional specification on the requirements and just start writing down the necessary test scripts scenario. Here are a few things that validator will be checking in your test scripts scenario, your SAT test scripts scenario on a validated project. Number one, and this is not in a particular order. Number 1, validator will be making sure that your test scripts scenario has clearly marked test evidence. Steps where you need to take tests evidence if you have a whole test scripts scenario. But it's not clearly marked when and where do you need to take a test evidence, for example, screenshot or a video? Well, this will be picked up. My validator has an issue. A validator. We also do a little bit of requirements analysis and we'll check, at least on a high level, that all the requirements are being covered by your test scripts. There are applications that make this process easier. For example, in HP ALM, the validator will set up a project in such way that you as a tester will be forced to link requirements that are already in the system with exact test scripts, making it very easy for a validator to check whether all the requirements have at least one test scripts associated with it. The next thing that a validator will be checking is whether your test script is detailed enough. They will be literally reading your test script, checking if the steps are detailed, the expected results are detailed as well. Another thing that a validator will check is whether your test scripts have been properly peer reviewed. So whether peer review has been completed and if you have either applied or commented and comments that reviewer might have posted to you. The next thing divided by two will be checking is the actual test script execution phase, the validate, or we'll be looking at an active SAT, test cycle, whether all the test scripts are being marked properly when it comes to statuses. So either unexecuted in progress, pass fail whether we are updating those statuses in real life. Well, if you fail any kind of test scripts. The validator will double-check if you have created and linked defects with this test script. A failed test script must be connected, linked to an existing defect. So those are the most common examples of what a validator on a validated project we'll be looking when it comes to validating or double-checking our software tester work. Now what happens when a validator finds something that needs to be changed? First of all, it's not the end of the world. I have been working for almost 20 years on validators projects. And yes, it is common that a validator will write to you, will write an email to you and maybe other team members specifying things that well that the validator or the validation team is concerned with. First of all, getting such an information is not the end of the world. They are just doing their job. The next thing to do is to analyze all the mentioned remarks and well, reply to each one of them. Some of them will make sense. Maybe you copy-pasted selfing then doesn't make sense. In this case, you would update the test scenario. Maybe you forgot somewhere to mark test evidence as mandatory. Again, you would just correct this mistake. But a validator can also be wrong. And if there is a remark that doesn't make sense from your perspective, you are certain that this point doesn't make sense. Of course, you are also free to confront in applied to a validator and in an email reply that this, this and this points have been fixed. However, this and this and this doesn't make sense because blablabla, you have applied all the good practices. It is already detailed enough out or whatever it might be the case. So in general, whenever there are any issues reported by a validator or validation team is essential that you're immediately analyze them and reply to continue the conversation. Finally, let's talk about what happens if you are maybe another team member. Well, does not comply, does not apply. All the remarks that the validation team has and what can be the end result of not working group, the validation team, not listening today remarks, what happens then? Well, why should we even bother with validation team? Well, then the result might be the lack of a sign-off from the validation team. And the end of the project, the validate or other validation team must sign of the project. In other words, they must sign off saying that, yes. They have checked all the points and they are satisfied that the project has been developed due to higher standards. And they are guaranteeing that the highest standards have been met during the development of the project. However, if they are dissatisfied with any face or component of the software development, this can be even analysis, documentation, programming, testing, any of those. Well, they will not provide the sign-off. And in fact, due to this, they will block the product release. The application will not get released. Naturally. This has never happened when I was working. So this is a very, very rare case. Before this happens, the validator or the validation team will reached out to you a million times. They will write emails, they were right, your instant messages. They will call you. This is the last step, last resort, and no one wants this to happen. So you out another team member will have plenty of time to address all the concerns and avoid this situation. Still. Just remember, a validator is a person that needs to be listened to and you need to engage into our conversation. If a validator has some remarks, this is the end of our lecture and see you in the next one. 35. Prepare as manual for automated tester role: Hello and welcome to our next lecture. In this lecture, I would like to share a few tips for Minoans, software testers who would like to change their role to an automated tester, has began, as discussed before. One of the possibilities for our manual tester for a career promotion is to become a fully automated testing. Here are my tips on how you can prepare for a career change to a fully automated tester. If maybe you are working at a fully Manuel software tester everyday job. And we would like to prepare by yourself for an automation tests that are all. In this example, we are looking at our software tester that is working only manually during everyday work. And the company is not really pushing for software automation. Thus, unfortunately, you as a software tester, as a mano, a software tester do not have the opportunity to learn programming and test automation during your working hours and the company. Beware. Most of those points will involve a lot of self-study in your own free time. Many times, working our everyday job as a software tester. We will be too busy doing our everyday tasks to even attempt to Latin automation at work, for example, by shadowing and automation test engineer often will just not have any free time at work to do so. Focusing only on Manuel software testing. Okay. So how can you prepare for a career change while working as a manual tester at work, my tip number one would be to have in general, a very strong testing fundamentals when it comes to Testing, overall. Testing in general, creating scripts scenario, reading test scripts scenario understanding, reviewing test scripts scenario. In test automation, you will often receive at least of already existing Manoa test scripts scenarios that you will need to automate, making it your everyday work to be reading through many already existing test scripts scenarios. It will be in your best interests to know and be able to quickly assess whether the scripts you received are of high-quality, precise. Maybe they are missing steps and you need to send them back to our tester that created them. Often, working in test automation, you will not be familiar with the application. Thus, test scripts need to be as precise as possible. And you need to often assessed them before you start working on them. Because of course it doesn't make sense to put a few hours of work. And then in the middle, realize that the scripts are no good and you need to send them back. Again. Test script review. Well, not the official one, but reviewing the test scripts that you receive. Be also an essential part of your everyday job as a test automation software tester. My next tip or the next skill that will be useful for your knowledge of our programming language. Of course, we are talking about a programming language that supports popular testing framework. So this will be, for example, Java, python, Swift. This point, this tip with probably take you the most of your time while preparing for this carrier change. As there is no skipping around, this are an easy way becoming this automation engineer, developer software, whatever you call it, a person that creates automated tests. Well, again, there is no ongoing confounded. It requires from your knowledge of our programming language, you will need to be familiar and comfortable with the given programming language, depending on your background. Learning programming language from 0 can be quite a challenge and as well time-consuming. My advice would be to make a plan, join some courses, and in general, keep at it. Trust me, for most of us, it will be difficult, tiresome, and frustrating process overall, but self-motivation and perseverance is what you need. Here. Again, trust me, this is the key skill. If you are looking to changing your vocabulary to AMA automation tests, then there is no going around programming. You need to be familiar and comfortable with it. My advice is to take it one day at a time, one programming lesson at a time, or maybe one coding challenge at a time. Go slowly, but keep at it. As days go by, you will notice a difference. You will be more familiar everyday and the things will start to make sense. However, beware them. This process is not a quick one and can easily take months before you are comfortable enough to go on a job interview and write a solution to a problem on a blackboard. Do not try to rush this process. Do not try to cut coordinators. Trust me, this is something that show fully need to learn and also understand Latin regularly and you will see progress next point, next tip. While learning. And also later on, working as an automation testing or programmer in general, never hesitate to look for a programming question and answer online. There are many websites like StackOverflow that have already posted millions of questions that were raised. By other people, learning programming, always feel free to look for an answer there, as well as posture on questions. One side-note, please use this website as a learning opportunity and try to understand every answer to your question, rather than just copying the code from the website to your application. Copying the code that you do not understand is a terrible idea. And please do not do this. Next point. Once you already feel comfortable with a given programming language, start looking at testing frameworks that are different. Test frameworks depending on the programming language. Just get yourself familiar with the basic ones are maybe just one selected. Go over the documentation, watch some tutorials on YouTube, join some online course afterwards, start using the framework by yourself. Create some very basic tests just in order to get the feeling of a framework and see that the framework is actually working for you. Next step, and again, we can be talking months in here, is to start working on more advanced automated tests. This is again, something that you need to do in your own free time. However, this is designed for you to get even more comfortable with the code, more comfortable with the test framework. My advice would be to write tests for API testing, back-end testing, front-end testing, and hybrid combining both back-end and front-end. In order to get familiar with automated tests writing, my next step would be to read technical testing. Websites may be magazines in general, to get familiar with other types of technical testing. For example, penetration testing. Even if you do not want yet to try those, it's a good idea to know that such tests exist and be familiar of what they involve in general. My next tip would be to practice in general other skills as well. I am talking about SQL queries or maybe API testing using Postman. So POI, while working hard on a programming language, do not forget to practice your other technical skills. My last tip would be to stay active in the community. As mentioned before, there are millions and millions of people learning, programming every day. Stay active, collaborate, maybe arrived some very simple application posted, contribute to someone else's application. In general, I would strongly suggest to stay active in the programming community. And this is the end of our lecture. I hope you enjoyed those tips. See you in the next lecture. 36. Tester, PM, BA, PO...: Hello and welcome to our next lecture. In this lecture, I would like to follow up on the previous topic of a Scrum team, of an agile team by describing what people are involved into Agile development team. What do their names mean and what are their responsibilities within the team? Understanding each role can not only help you identify the correct person that may be, you need to talk about potential problem you are facing as a software tester during an active sprint. This will also give you a great opportunity. In the previous lectures, we have discussed several opportunities for our software tester, for a carrier promotion. We have discussed the possibility of becoming testlet test manager. Oughta may be an automation testing. However, simply by working in a company that supports agile teams gives you another great chance. Another great opportunity may be different. Scrum team project for all will sound appealing to your sodded. Apart from being a software tester, you might look at a different career opportunity all within the same company. Automate be issued in the same project you are working on. In order to be able to even consider a potential change from a software tester to a different role within the same company and a Scrum team. You first need to understand, at least on a high level, what each of those roles consists of and require from a candidate. Let's begin. We have in our scrum team, Agile team present testers, software testers. I will not be going over water and the responsibilities as you should already be familiar with it. However, of course, software testers are a key part of an agile squad member, Agile team. The next roll present in a Scrum, agile team is a project manager. Shortly PM for project manager. Project managing. What does it mean? So in this case, your job will require you to work closely with the management in order to, for example, get funding for hiring new people to your team. You will be the person who will be negotiating on how many team members you can hire auto, maybe how much you can spend on their salary. So you will be actively managing the finances when it comes to the project expenses every single month. Project manager will also. Take care of other expenses. For example, software that needs to be purchased in order to enable some development, as well as additional services and any other kind of costs related to the project. The next thing that project manager will look into is the timelines. One of the headaches for a project manager will be constant. Delivery of on-time. Project manager will always be focused on what needs to be delivered. At what time. Project manager will be creating detailed roadmaps. So for example, putting on a clear roadmap when it comes to the timeline where specific feature needs to be delivered in order to make the whole application work. This will be a headache for a project manager as well. Depending on accompany project manager can be aswell heavily involved into the sprint ceremonies, preparing the meetings, reading their meetings. So in general, a project manager will be involved in many different things that happen in the background of an active project. Next role is BA, business analysts. I have already explained a bit of what it involves being a business analyst. So of course, you will be meeting with the business. You will be later on translating the business requirements into more technical and detailed language, creating documentation. However, in an Agile team, being a business analyst will involve working closely with our product owner, our next at all PEO for shortcut. So product owner is, as the name suggests, an owner of a product, of a final product. In this example, we can use, for example, a banking application. As a product. The product owner will take the whole responsibility of making sure that the end result then the application is Festival on-time. Second of all, and the highest quality and first of all, compliant to all the business requirements. Product owner, as mentioned before, we'll often meet with the business in order to discuss what the application should be doing. What are the requirements? So you can say food, it sounds awfully like a business analyst. And yes, indeed, depending on a team structure, sometimes the business analysts will even not be present at all in a active DR team. However, product owner will be basically taking the business analyst role as well and writing down the business requirements into a more detailed technical level. However, I have been working in agile teams that had both a product owner as well as a business analyst. This can happen simply to the fact that product owner will be too busy, will have too much on their plate in order to be efficient. In Writing down all the requirements, preparing all the tickets in the backlog, as detailed as they shouldn't be. In this situation, our business analysts will join the Agile team in order to support, to help an active product owner in everyday activities. Basically helping with cracking down and expanding on some of those requirements. While the product owner will be able to meet more often with the business. In general, product owner role works very closely with the business. This is something that you need to keep in mind. Product owner works very closely with the business, is often on the calls, often on the meetings with the business. And finally, also as a responsibility for a product owner. Often, as of course, this person is an owner of an application. They are responsible for an application. Product owner will often test the application as well. So of course, we have software testers being present in an Agile team. However, often a product owner will take a look at the application as well during an active sprint. So for example, you might be done testing specific feature, a specific ticket, and afterwards appeal. We'll take a look as well, depending again on the team and on the workflows. Often even Jira workflow will consist of status change from testing successful, too, ready for peer approval. And there will be a hard-coded step that every single ticket that is test, test successfully by a software tester still requires a product owner to double-check, to verify. Of course, we are talking about a very strict Workflow making basically product owner test, every single test that the tester is executing. However, this is also a great approach because while it kind of makes a ticket to be double verified, as well as the PO, acting kind of other business user. So such workflow is also a great workflow despite taking more time. Other team members in an Agile team, we have programmers, front-end programmers, backends programmers, front-end programmers who he'll focus on developing the front-end and connecting it to the back-end. So everything you can see either on an application or on our website. All the graphical user interface. This will be done by a front end developer. On the opposite side, a back-end developer will be working only on the cold front and back-end perspective. So everything that happens in the background, such a programmer will not be actively working on anything that is connected to our graphical user interface. This will be the job for a front-end developer, sometimes depending on the project, there is also a spot for an dedicated test automation engineer, for a dedicated automation tester to join the Agile team as well. In such cases, the main role of this tester would be to alternate either at first the smoke tests and afterwards, probably the regression tests in order to take away some of the burden from the regular Manuel software testers. So they can focus more on testing the active tickets and not really worried about either smoke tests or regression tests as those will get automated and run in the background automatically. This is the end of our lecture. I hope that you enjoyed it and now have a better understanding of what roles does an agile team involve and what are their responsibilities. See you in the next lecture.