 Hi everyone, I am Anisha Narang and I work at Red Hat. I've been in a QE job role for almost five years now. I worked with a couple of test automation tools, like Selenium Python, what a cucumber, and off lately I started working with Protractor. And other than that, I like traveling and meeting new people. Was any of you here in the morning for my talk? Okay, all right. Thanks for coming again though. So before I get started, so this is mainly a discussion. Are there enough learning opportunities for a QE? I will quickly run through a few slides and then we will be open for discussion. So we often, as we are talking about and coming up with new and faster technologies each day, we often forget about important things like testing and people have different opinions and thoughts about it. So first I'm gonna quickly break a few myths about testing that we have and then go ahead and share some of the learning opportunities that we have. First, manual versus automation. So whenever you tell somebody that you're in a QE job role, the first question that comes to you is that, do you do manual testing or you do automation testing? This thought has created a divide between the QE community itself. Automated testing can accelerate the overall testing effort, but can not eliminate the need for manual testing. And efficient testing is achieved from both the combination of manual and automated testing. Quality is solely QE's responsibility. Whenever a defect is identified, a QE is surely to be blamed, but most of the times what happens is that often other phases like development take a lot of time and the QE's hardly get enough time to do enough testing just because we are running for the release. And quality is not solely the responsibility of a QE. It's everyone's responsibility on the team. Developers need to be accountable for the quality of the code that they write. And testing provides information about the quality. And testing cannot improve quality until and unless the bugs reported are fixed. Upman versus testing. A lot of people think that development is often a superior career option than testing. So even if you go to a college student and ask them what do they want to do in the future, all they come up with and say, they want to become a developer because they have an assumption in the mind that testing might be boring. So QE's are mostly undervalued and underestimated by people who do not understand what value they bring to a project. But QE's bring a bigger perspective to a project based on the deep understanding of both the development process and the business requirements. Test coverage and 100% automation. So whenever you talk about automation, the first thing that comes to you is what is the test coverage? How many tests are automated? Do we have 100% automation? Can we achieve that? But people often forget why automation exists. Automation is for critical test cases, faster feedback, and to reduce regression. It is acceptable to not involve QE's. Most of the times QE's are left out whenever we are debugging a critical issue, maybe planning a release, or discussing some code development issue. But QE's should be involved at every stage in the software development life cycle. QE's maybe at the planning stage, they can help you by telling you which are the scenarios that are testable or not, or maybe help you with coming up with some of the more scenarios to a particular application which you might miss. Okay. So the last is testing is easy and requires no logic. This is the most annoying one. So people think that testing is just about following a sheet of documents, writing a certain set of tests, and maybe just reporting bugs, but in reality it is actually much more than that. The QE actually needs to get into the shoes of the user to understand the application, and that user can be in any part of the world. So that's where the QE needs to use its analytical brain to come up with different testable scenarios for the application. And when it comes to automation, equivalent programming skills as that of a developer are required. Any disagreements in the room until now? Okay. So now we come down to Sherry. I'll share some of the learning opportunities that we have. We have a lot of learning opportunities. Test automation is the key to learning. So now you cannot expect a human to keep performing the same steps at the same speed and accuracy over and over again, and that's where automation comes into picture. To reduce the regression time, we need automation. There are plenty of open source test automation tools that one can choose to learn. One of the most widely used tools is Selenium. Selenium automates browsers. So whenever somebody is stepping into the world of web UI automation, the first tool that they might learn is Selenium. Initially, I started working with Selenium with Python and using the Selenium Python APIs, it allows you to use all the functionalities of the Selenium. Then it was water. Water is nothing but web application testing in Ruby. It is again an open source automation library built in Ruby. It's again powered by Selenium. And off lately, I started working with Protractor, which is an end-to-end test framework for Angular and AngularJS applications. So Protractor is again based on WebDriver.js. So it's all powered by Selenium. So one of the advantages that Selenium provides you with is that it allows you to choose the programming language of your choice. So initially, when I was working with Selenium Python, the application was based in Python. So I chose Selenium Python. And later, when the application that I was, the project that I was working with was in Waldron Ruby. So I moved to using water, where I got an exposure to use Ruby. So it's always better to choose the same programming language in which your application is, but you're free to choose any programming language to write your tests in. So the advantages that come with it when you're choosing the same language that the developers might take a little interest in the test that you're writing, and you might get some help around in building your test automation suit. And it can be integrated well with the application and other tests that already exist. Now, moving from Ruby and Python to JavaScript was another challenge because I was moving from a world of no brackets to a world of brackets. So when I wrote my first test, I took the entire day to figure out why is the test not running and how I figured, and at the end of the day, it was just a bracket that was missing. So it was kind of tricky, but I learned a lot on the way and it was also a couple of new concepts that came on while I was learning JavaScript and using Protractor for Angular application that I was testing. A few other things, behavior-driven testing. Behavior-driven testing allows you to write your tests in a human-readable language. So Cucumber is one of the most widely used tools for behavior-driven testing. You can use the Gherkin syntax of given, when, and then. It allows you to write your feature files and have the test in human-readable format. API testing. Next is API testing. API testing is very critical to automated testing because API is usually at the core of the application logic. So you can always use, you can always make calls to an API functions or the API endpoints and verify the JSON responses and the status code that you're getting. You can use any HTTP request modules to verify and this will again help you in getting more knowledge and understanding about your application in a better way. It will give you an exposure to understanding how the API of your application works. So it's a good area to explore and there are a couple of other tools that you can use to API testing. Next is continuous integration. It's another interesting area for you to have a look at and so Jenkins is the most widely used continuous integration tool. You can always integrate your test as a part of the CI so that's for everyone to have a look at the test reports. You can configure and send out build reports to the entire team so that everyone on the team knows which tests are running and what's the current state of the application. If you're more interested in going deeper and have a better learning curve, you can always go ahead and say that you wanna learn how to manage and set up the Jenkins instance. This will again give you a better exposure in knowing more about how the Jenkins jobs are configured and how you can set up and manage the entire instance. GitLab CI is another similar continuous integration tool that you can use. Setting up test environments. I'm sure this is one of the most interesting areas for everyone. So five years back when I started setting up test environments used to be like setting up a VM which either used to be a desktop machine or maybe we could set up VMs using virtual box, VM ware and use libraries like LibWord. After that I started using Rev which is Red Hat Enterprise Virtualization using the Rev API. I could allow my test to SSH into a particular machine into the VM, perform the test and just terminate the connection. And after that it was, but it was still blocking some resources in Rev. Now then after that I used OpenStack using the Nova Client API, I could just spend the VMs on the fly, perform tests and destroy the VMs. So what advantage did it come? It was saving a lot of time, not being a tedious task like using virtual box and VM ware to set up VMs which took a lot of time. And moreover it was not blocking any resources. I could just spend the VMs on the fly, perform the test and destroy them. Now Docker is something that you all might have heard and Docker allows you to have your local test instance in an isolated environment. So this is another interesting area that you can learn how I have used Docker is that we have Dockerized containers and we spin the local environment of the application that we want to test again against which saves us from any dependency on any of the DevOps teams where we are saying that the QA environment is not ready. So that's how we save time with that. Okay, how many of you have heard of Ansible? And how many of you have used Ansible? That's a good number. So we often talk about Ansible which is the most widely used tools for orchestration but we hardly talk about how Ansible can help us in improving test automation as a process or improving the test automation process. So like in the previous slide, we talked about how do we set up the test VMs. We can use Ansible, we can use Ansible Playbooks to spin up the VMs for us so that we again save on time on setting up the different configurations of the VMs that we want. If we have Ansible Playbooks set up, it's pretty easy for us to spin up the VM and have a particular test environment up and running with just the Ansible commands. It is one of the most popular open source tools used for orchestration and application deployment. The Jenkins Job Builder. Jenkins Job Builder allows you to write your tests in the JSON in the YAML format so that you don't have to open your Jenkins dashboard over and over again to manage your Jenkins jobs. So this way you can again save time on Jenkins jobs management. Okay, so a couple of people also feel that if you are in a QE job role, you might not have enough opportunities to go to conferences or you might not have enough opportunities to get certifications. So there are a couple of conferences which are QE centric. So you can always go ahead and join Selenium Conv which is an annual conference based on Selenium. GTAC is Google Test Automation Conference which is conducted by Google annually. There are agile testing days, software testing conference and Vodka. Vodka is a conference that is run by ThoughtWorks. I've attended a couple of those back in Pune, India. And it is something similar to that Red Hat runs as QE camp which is an internal QE conference for us. Certification should get started with your career in being a quality engineer. You can always go ahead and take up ISTQB which is International Software Testing Qualification Board. After a few years of experience, you can go with an ISTQB advanced level. Next is RHCSA which is Red Hat Certified System Administrator. If you're more interested in having and knowing more about Linux and being able to set up your VMs in an efficient way, RHC is again a choice that you can make. That is Red Hat Certified Engineer. Demise your tests each day and keep learning. It's very important that you keep refactoring your tests each day so that and follow the best practices like keeping your code dry which is do not repeat yourself principle and using the page object pattern. If you were there in the talk that I delivered in the morning, I spoke about how to use page object pattern and how that helps. And you should always try to provide your tests as a service so that anyone on the team could run your tests as and when they want to. So yeah, thank you. And now we are open for a discussion if we have any points to discuss. I think we can have an open discussion on any topic that we might want to which relates to this. Thank you, yeah. From some of the information framework that we introduced, I guess you probably focused on like the web application testing. Can you introduce yourself a little bit and besides the web application, okay. Oh, sorry. So yeah, based on the recommendation like Selenium, Water, and... Protractor. Yeah, so they are mostly like a web application testing framework. So I guess you are expertise in this area. So can you first, can you introduce yourself a little bit and also can you recommend other framework in slightly different like level or areas? Thank you. Okay, thank you for the question. So I've been working mostly with web UI automation, but like I mentioned about the API testing, so there are a lot of other testing frameworks that you can use. So it depends on like if you're using, if you want to use Python, then maybe you can go ahead and use PyTest frameworks or Unitest. And if you're using JavaScript, then Frisbee is the one that you can use for API testing, Justman testing framework. And if you go ahead and move to the different types of testing, we can always use different tools for load testing. There's a tool called Jmeter that you can use. And you can use the same tool for performance testing as well. So there are a lot of tools that you can use. I hope that answers your question. Anybody in the room would like to add to the question, you're free to go ahead and answer. Do you want to add something? I think maybe you're asking about non-web related testing. Like maybe a desktop application. Is that right? So was your question more about a non-web related testing framework? Like let's say a desktop application for Windows or a shell automation for Linux or anything like that, right? Okay, we'll answer it, you know. No, I'm not aware of that. So I personally have used Test Partner, which was a Windows shell automation framework. So like any Windows or any EXE file which opens in Windows, like maybe made in Visual Basic or any other Delphi or the legacy programming languages. But after 2008 we, I think I personally have been working on the web only. And I think so is Anisha. What behavior-driven development called BTT and then we use robot framework and all those things for testing water I haven't used. So yes, so in addition to behavior-driven testing, Cucumber is one of the most widely used tools. Like I mentioned in one of the slides also when I was talking about BTT. And so is Robo Framework. And our spec if you've heard from, which is a Ruby framework that's again based on BTT. So there are a lot of testing frameworks that are based on BTT that allow you to write your tests in a human-readable format. Yeah, yeah, Cucumber is nice. Hello, have you heard of Avocado Testing Framework? That's a Python-based shell command-line framework. Yes. We use that extensively for virtualization testing because that's the only one where you can actually run systems on bare metal, which allows you to install a guest and which is primary for our use where because we are testing virtualization components, we need to make sure that we can install a guest, create a VM, add a disk, all of those things. And it's completely command-line based. There's no UI for that. And we use it extensively. They have developed a lot where there are plugins where if you don't want to run virtualization tests, it can be used as an external runner for tests that you might have written in Python and it can run those as well. Do you know any about any tests specific to React Framework, like you said Protractor, which you used for Angular? So can it be used for React or do you have any specific, like if you have any work done, any testing frameworks which can be used for React applications? I'm not sure about that, but Protractor should be usable for any React-based application as well. Thanks. But it's not really worked on any React chairs. Has anyone in the room worked on React or knows that? So we have an application in Inside Red Hat which is internal, which is made in React. So it was an Angular application, which was then rewritten in React. So like Angular, there is no specific end-to-end testing framework for React. So we simply use the Java with Selenium WebDriver to test React, but if you're not thinking about end-to-end, then you can probably use Jest and enzyme frameworks. Yeah, that's the same thing. Any more questions, any more topics to have a discussion on? All right, thank you so much. I hope you had a good time and that's my Twitter handle. If you might want to give any feedback. And yeah, thank you so much for participating. Thanks.