 Right, so are you guys ready? Take it away. Hello, Mecha. I've been working with Red Red for the last 40 years now. I'm a quality engineer at Red Red. And I'm an A.C. conference testing director at Red Red. But this was something of my interest as a conference course, main program in my free time. So how many of you are developers? Do you guys sometimes do things? Production. And so far, how are you all enjoying the work? Take away from my presentation, that even if you are a tester, if you are a user or you are a programmer, testing should be part of everybody's job. And it can be done by a paper. So by saying that, I'd like to start with my agenda which will cover how you can contribute in improving the quality of the product you are using, any operating system you are using, any activation you are using, how you can continue in improving the quality of that product. And then, why do you create a test harness for your application? How to alter your software development that will focus on the developer side or the coding part, how you can alter your techniques so that you can make your product less work-thru. And then, you can talk about the burden of reporting, how you can price the bar, how can you fight the bar, and how should you report the bar. And then, ask the troubleshooting part. So this is the question from many people that I don't know the programming. I'm just a user. How can I contribute in open source projects? So there are many ways, like designing or spreading it around the world as a user you are using, but the definite good thing when you are not a programmer and you want to learn something about the product than the answer is testing, which is the best thing and easiest thing you can do to start with. I would like to ask new people why the testing is the best thing. If you think it is a way of contributing, I would like your influence to make it a little more interactive. Because I can see the faces you are almost like, this is about the finishing. You go around Singapore. You can try out phone and see the output instead of trying to understand how it reduces that output. You don't need to go into the depth of the functionality or you do need to be an expert who can do the tool. Anybody of your friends? Basically, I'm just going to start from you. So you can read the lines. So it is the best way to learn the new things. If you are a programmer you can do the automation testing. You can develop an automation framework for the testing, but even if you are not a programmer, you are a user, you can do a manual testing. This is a very simple example to use. If I give you a pen, for example, and I would say, how do you test it? What will be the test case for it? For a pen. Can anybody tell me? Write it. See, how many of you are testing a world service? So quickly. Not professional testers. Except you. So that is how. Testing is so easy to learn. The application, the operating system, or anything you would like to test, it should be worked as expected. So this is the primary test case you come up with for a pen. What else? You can test for a pen. It should open, it should have a cap, and if it is a ticket pen, doesn't it look like a cap? Yeah. Yeah, definitely. But for the professional testers, there should be some quarter test cases, some ticket cases, blah, blah, blah, this and that, just to make the term complex, and just to show that, yes, we are doing something good. So anybody of you can easily participate in testing. That is the class of the session. You can download the test cases, test plans, for example, I would like to take an example of Fedora. If you are using any product, in Fedora, or Fedora operating system, and you find that something is not working, for example, whenever I change the background of my system, it starts playing in Fedora 19, and I just open the box against it, and that's how it got fixed. So the quality of the product has improved. Even if I am not tested, this is a very previous thing to do for me, and that is how everybody can contribute in improving the quality of the product. Other things depend on us. Whenever there is a new release coming, just upgrade yourself. Just upgrade your system. One person was there, I asked him, what are you using Fedora? Very confidently. Which version? 16. Wow, 21 has released. So try to upgrade. That's true. But then you need to make the other versions the latest version more stable. Why it is stable? Can you tell me, why it is more stable? Because there are plenty of users of Fedora. Oh, because I have been using it for a couple of years. Couple of years? Why? Why a couple of years visibility of that particular version made it more stable? Because people have not problems against it. They found issues against it, and of course, they fixed those issues. That's why it is more stable. So there are generally these ways, you can continue towards testing. Now, what is the test hardness? Can you tell me, what is the test hardness? Don't read the answers first. She is not a good reader. Yeah. So test hardness is more fun than the medical test. For example, this guy got married, newly married, already married. So he must have that experience. Okay. He has completed all his work in a week. He is a tester, for example. This is an example. He does everything so nicely in that one week, and we went to his wife and told her that will go to the movie. I finished my work today very fast because there are all tests that have been done. And today we will go to the movie. She is very excited as we go at this feminine quality that even if the movie is short time, it is at 7 p.m. we will start our make-up at 4 p.m. So, she was already and just very cool friends to come down and meet her back. This fellow went to the office, went to the manager cabin. Okay. All testing is done. Today I can leave in time. And then the surprise, new wait has come. New wait of the product or for the application which he needs to test again. So, it means if the product is releasing, the application is releasing next day, he has to compile for all the test cases he has to make for the past one week. So, if he go and do it generally, it means he is going to take another one week and he cannot complete his work. And you can test the reaction of his wife. Who is putting make-up for two months? Are you saying that if you are a tester, you cannot take your wife out for a week? If you don't believe in test harness, then yes. So, test harness is automation developing tests using test automation tools. So, it is very important the things which are which can be automated So, it is a step towards becoming a deaf people at the theatre a step towards. There are so many languages open languages which you can use like 500 there which is very famous which provides so many frameworks to use for testing that is fight your testers there noses there. So, all these things takes your life easy and you can take your wife to the movie. Right? What if you don't know? I don't know I should ask this question to your wife. Okay. So, for the developers include testing in your development. How you can do that? Can someone give me the examples quickly? How a tester can focus on testing part also by developing things because I feel you are a developer. Include testing in development. How you can do that? Write test cases while you are writing the code. Yeah, that is what you can do. Anybody else? Follow me, maybe the tester. Can you tell that in little detail that you write your test and the application code afterwards. Which is an approach towards development. Which nobody follows. People follow. It is an approach if you take that approach then you follow that approach. It depends how successful it is and how you include it in your product. In your project. We should do it. We should do it. Pick up the testing along with the development. Don't you think that development and testing should be eliminated of each other? No. They both should be developed on the same requirement. They should follow. They should be integrated. I agree. They should be integrated. But coding for some test cases don't you think that is not the idea here? Not coding for some test cases. You should code for the requirements. Yeah. Or you should follow some standards. We ordered over its box. Some standard test cases I can have which I would test immediately. It is not just right. That is my very good point to having test cases by the development team also. But that is not the only way to do it. There are other guidelines. The developer should always follow to avoid the error-prone mode. Lesson the burden of investor also. So, what are these things are? Objectively oriented languages which have error handling which have exception handling. So that in the first year only you have handled some failures already. You have to understand that point. And then you should avoid a background code. What is a background code? You understand that? No indentation, no proper spacing. It is not readable at all. Even if you are, you can read the code. You want to troubleshoot where is the box. You cannot do that. Because if you open the code it is like a pre-structured or some structure which the developer may have like that. So, that is the one thing. Other than that include unit testing which is very good point. And it has put down that test cases should be written along with your developer. Some starting test cases. If you have tested that build if you deliver that build without any unit testing it may possible that it will crash. Or it will not get installed. In fact, it is not getting installed itself. So, these are some cases you can avoid. And then the most important thing is continuous integration. Along with the development you should have the testing family going on. Like for any product release or application release you have cases alpha, beta and the final release. So, there should be a coordination between the development and between the testing team. This alpha is released you should test this box. Now beta is released this should be tested finally. If there are some box get it fixed finally you shift the final GA merger and then you test it. So, this is the continuation integration which can lead to a very quality product. Ok. So, these are some things that are expected from developers. So, avoid box. Now, you may ask this question if developers will test everything what testers will do. So, obviously this cannot be answered. There are many types of testing which a user and a developer may not be able to do. For example, we have white box, black box and a grey box testing. How many of you know about what is black box testing? Do you want to answer the question? Yes. Ok, let's start with white box. White box testing is like looking at code really important. Testing is like you just test the final product on the router as well. That's a river. So, the white box testing is when you know the functionality know the code in ternary troubleshoot very well. But the black box testing is that you don't know the details of the application. You just put the inputs, get the output and you don't do the troubleshooting at all. Anybody know the grey box testing? Ok, so it is a mix of the white and black that you know you may know some of the functionality but you don't know all the functionality of the application. Now, anybody know about the blue box? Yeah. Neither do I. Ok. So, other than that we have here my two three testing which is also the job of the tester. I am going to give the details about it. This is just to tell you how important testers are and even if there are people to cover the testing, these are the detailed testing which a tester have to cover. Acceptance, learn duration, stretch reliability, this and that and what not. This is another important job that we are going to find in the box in the application and the product. Little bit about the box. Here application is not working as expected. So, it is called the box. But there is always a difference between an error of failure and offer. You have to understand what is the problem here. Sometimes our environment, our setup is not proper. Sometimes our configuration is not proper and then for each and every thing you are doing, not working. Go to the developer, not working. Try small things, not working. Go to the developer, not working. This is not the thing. So, you have to make sure that the product you are reporting as a box has a prevention problem but not the other things going wrong at your site. So, there are many good bug testing tools. For example, there is a there is Baxila which is used for Red Hat, Baxila bug reporting tool as well as Fedora bug reporting tool as well. Which provides there are so many other bug reporting tools as well. And there are so many sections in that which you need to fill. Sometimes you go there feeling lazy. I am testing this issue we should report. We go to the bug reporting tool and see how many things you need to fill. And you said give it now. I don't give it now. I don't want to take the efforts to fill all those things. That should not be the case because I tell you why all those things are important. A bug should have a description. A crash report it is a crash bug. Everything else in the place in which version you have gone wrong when you face a bug. This all information is important for the developer. From the developer's perspective who is going to fix that bug. He obviously needs all those information. So that is why it is important. And if you feel you are lazy you can use the bug reporting tools. For example, ADRT which is automatically bug reporting tool. If you are have encountered some crash or something like that if you have configured that ADRT it will go to your bug tracking tool it will put all the fields and plus the crash report in it for yourself. I don't think we have much time so I will just go through this quickly. Last thing is troubleshooting. So if a good tester always troubleshoot this problem you remember I told you just to understand that there should be a definitely a difference between an error failure and transmission error and repeat a bug. So troubleshooting is really very important in the part of the tester. If you know more about your application you should be able to troubleshoot that. And the best way to troubleshoot a problem is more. Look at the case folder where your logs are getting accumulated read it and you will get to know where is the problem. Read your code and use the tools which will pin down the problem area like volume. But then being a tester even I am a tester I will accept this thing that nothing is 100% bug free. But a good tester will make sure that the applications will qualify at least the requirements and it is working fine. Any questions? Can you tell me about it so that I can answer how you got it? Yes sir. Continuous integration which is very important. So I wonder if it is also nice to have automated tests behind that stage. So what happens when you have first build of the product you may not have the automated test cases for that. But for the same product if you are getting second build or third build even if the operating system is coming along you obviously have tons of test cases which are already automated. So that is accepted testing. The moment the build comes there are open source tools like Jenkins where you can have your job configured in a way that build is coming the moment it comes even if the tester doesn't know about it the accepted test in place will get executed and you can work that. And you have like robot framework to integrate some terms I am kind of confused about smoke test performance test stress testing and regression testing Yeah these are the steps to make sure that the test results are important. I appreciate how we are I appreciate how people practice jobs apart. Jobs apart definitely these are the things which a tester need to do mentally sometimes. But that's what I said within the time, within the mobile progresses we have few things getting accumulated in our automation plan. Any other questions? If you have any questions you can meet me outside on the right hand side also you can thank you. Thank you.