Hello friends and greetings for the day welcome back to another tutorial on istqb Foundation certification tutorials we are getting started with chapter one and as a part of the chapter one which is fundamentals of testing we shall be talking about the very first topic of this chapter today that is what is testing and as part of this particular segment we shall cover more about the basic introduction to what is testing [Music] well in order to talk about the fundamental of testing Concepts testing is there from a long time it's just that like we did not
recognize it probably much earlier but it's just that it was a part of our day-to-day life activities in fact when you do something you do taste it right for example when you cooking something new you would love to make a taste of it to make sure that it is tasting as you expected or not and exactly that particular way of concept is being applied into the segment of any product or any applications testing so being A tes engineer our responsibilities are to validate whether a product is working as expected or not now here I'm using
the word product it does not mean that it is only limited to an appliances or any hardcore product which you might be using in your day-to-day world we are also talking about any such application or software which we build today right so a bit history of what testing is and how does it come into the market of course initially we did not have anyone called as testing genius but of course testing is existed long back when the development was done by the developers and the developers were also responsible to do testing too but of course
due to the you know same person performing these activities that led to a lot of defect leakage and it's a very common understanding right at the beginning which I would like to share with you that we understood based on the analysis of this that why are we leaking so many defects to the market we understood that it's a very hum very common human tendency and psychology that you cannot find all your mistakes now there are a few things about human psychology which are very simple and straightforward to understand number one human is error prone which
you will agree to it second that human cannot find all their mistakes of course they can find some of them but not all the mistakes what they make every single day or in every single book and third humans are equally good at finding mistakes in somebody's else work now that could be a little funny to talk about but I think I'm pretty much making sense to all of you now that's where we thought testing let it happen of course it has to happen we cannot excuse it but let let's have someone else do it even
if I relate this to your graduation examination and I'm I'm not sure how many of you really got some time to revise your paper before submission but one once you know the teacher looked at it uh they could very well find out the mistake no matter how many times you revised it before submission you were not capable of finding all your mistakes now that certainly justifies that what's the need of being a tester and at the same time was the need of having someone else as a test engineer not the person who developed it so
many people assume that hey that sounds a very simple thing and can anybody just do that answer is no not at all testing is just not limited to writing test cases and executions many people think about that testing is just a set of activity which involves writing test cases and executing them another misconception about testing is that testing focuses entirely on the verifying the test object whereas it's not just Dynamic that means it's just not about interacting with the system and Performing the test it also deals with statically reviewing the work products which we right
so the Journey of testing starts right from the requirement Gathering and we as a tester get involved in reviewing the requirements in other words we are actually understanding the requirement for writing our test cases but as a return of that or as a byproduct we do find anomalies in the written documentations too similarly a tester do get involved in design review does get involved in the test case review test plan review project plan review code review today and everywhere no matter what kind of effect what kind of work product we are talking about we do
have a review happening for such products which are critical to have any anomalies at the beginning of the day also testing is not only the technical activity it also needs to be properly planned managed estimated monitored and controlled which of course is a responsibility of the manager and the management takes care of it but uh testing is just not limited to writing test cases and executing them so people who are thinking at this point of time that hey testing can be done by anyone or if there's someone who told you that testing is the most
easiest job in technology and someone who doesn't have anything to do can become a tester let me tell you it's not that simple you need to learn things you need to understand things and need to make things happen according to the expectation and for that you need skills and Technical knowledge well the next topic importantly what we are talking about is test objectives that means what are the key objectives of testing as a part of the process and of course many people think that testing is mainly from the perspective of validating the product finding the
defects meeting the expected requirement meeting the user needs and sometime they do get confused or sometime they do conclude things together stating that is it uh the combination of all the things and answer is absolutely yes testing has multiple objectives and a tester is responsible to meet all of them but yeah there would be some of the things which may not be applicable to your product depending on your organization depending on your product characteristics or maybe your project characteristics so it is very important to just keep those things in mind which your project or product
or organization deals with but at in a nutshell all these on the screen are basically your key objectives of testing and being a test engineer you are responsible to meet them so the objectives include mainly that is the evaluation of the work products the journey starts right from there as we talk about about different work products being written now work product here are documentations including the diagrams like uh you can say business models or flowcharts algorithms every single thing is a work product for me to get evaluated so V testers are responsible to review them
and raise any kind of anomalies and queries and doubts or clarification related to that second triggering the failures and finding defects of course uh our in overall intention and objective is to conduct as many fa failures as possible as a part of the life cycle or test activities and to make sure that we identify the potential defects and let the developer know about it so that they can fix it of course when we talk about ensuring required coverage of a test object object which means writing the number of test cases which are desirable to cover
the required expectation has to be written so the coverage measurement is equally important it's not that for a particular requirement I can just write few test cases whatever I think like and that would enough now you need to write appropriate number of test cases which gives you the required coverage for that particular functionality or feature or test object reducing the level of risk of inadequate software quality now of course the risk also is getting covered and again these words will be discussed in detail in chapter 5 so just stay calm and we will be talking
about it in more detail but as a part of testing our responsibility is also to reduce the level of risk because sometime we just can't blindly mitigated risk also verifying whether specified requirement have been fulfilled which is key expectation of testing we assure that the user needs and expectations are met verifying what a test object complies with contractual legal and Regulatory requirement uh this is what I was referring to when I said that it's not necessary every organization every single product has to go through the standards the contracts or legal requirements but there are many
products in the market today for for example if you talk about embedded systems you talk about automotive aviations and banking they do get involved with many standards legals and other contractual requirements of course contractual could be for anyone but legal and uh standards are specifically driven by some of the products also verifying that test object uh complies with that and then providing information to stakeholder to allow them to make inform uh make informed decisions that means our key respon responsibility is to consistently let other stakeholders know that what are we doing at this point of
Time how are we progressing so that they can make appropriate decisions about the progress and releases building confidence in the product quality which is of course one of our key responsibility if we as a tester do not have the confidence of releasing the product to the market then we cannot let the organization do that so as a tester until unless you have the confidence of you know letting the product go into the market nobody else would do that so your sign off is very important it's just like until unless as a ground staff you don't
show a thumbs up to the pilot the pilot cannot move the aircraft so that's your value at this point of time and also validating whether the test object is complete and works as expected by the stakeholder so completeness check should also be performed that means uh some of the requirements can be under tested or some of the requirements may be missed out with uh as a part of the testing so so we must keep assuring at every single point that all our requirements have been covered completed and they are behaving as per the stakeholder needs
well another important thing here we talking about is testing and debugging quite often people think a lot different about testing and debugging and uh sometime people who are not from the testing background they think testing and debugging are almost similar why because testing is all about finding defects and debugging as a term also says bug bugs D debug so it's about removing defects so isn't that testing and debugging are somewhat or almost similar and that's where testing team wants to or istqb wants you to learn about this at this point of time that testing and
debugging are not same testing and debugging are different a testing team or test engineer is someone who is responsible only to find defects they don't have any kind of contribution in terms of fixing a defect where whereas debugging is something as a process which deals with analyzing the defect being reported getting into the root cause of that because it's not necessary what you see is only the problem sometime there could be something else as an element contributing to the failure so a developer has to go through the root cause analysis to find out the exact
reason behind that failure or the defect and then fix it so fixing that is certainly not something which just you know can be done by a test engineer so in key differences testing is only responsible for finding out a defect or finding a defect whereas debugging deals with uh the analysis of the defect that means understanding what is the defect all about getting into the root cause analysis finding the root cause and another important thing is fixing the def so it's very very crucial that we understand the difference between this so testing and debugging are
separate activities and uh does deal with important things which are related to uh performing these activities so another important question what I quite often quite often hear from people is that hey when it comes to automation testing do we call it as testing the script or debugging the script so sometime is it possible that we can also do debugging answer is of course yes it's not about the role or the designation in your organization it's about the process right the process says what exactly you are doing so if you are just finding defs you are
doing testing no matter who you are a developer also does testing T in in terms of unit testing a tester also performs testing when it comes to system testing when it comes to code a developer performs debugging we don't do anything but when it comes to automation script which we have written so we are the developer of the code right in that context we are the people who are also responsible to fix our automation script ourself and that time when we are analyzing the script and fixing any kind of syntax errors or any kind of
other anomalies in the script we call call it as debugging so execution is called as automation testing but fixing the script is debugging so in that regards it's just not limited to developer it can be done by tester also given that they are responsible for writing and maintaining automation test so I think that was all we had from this particular tutorial team and you have got a good understanding of the same should you have anything else we can talk if you can just let me know by dropping a comment so that's all from this particular
tutorial team should you have anything else feel free to comment below I'm always there to address your queries answer them well till then keep learning keep exploring keep understanding the context thanks for watching the video team and happy [Music] learning
