QAOps - The Latest Trend in QA & Software Delivery
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
State, Marcela
Quality expectations are increasing day by day, market demand is changing rapidly and digital technologies are influencing QA practices. How do we adapt? QA plays a strategic role, it is a connection point between development and operations. DevOps can speed up the development, but what can you expect without a robust QA strategy? Continuous development and continuous delivery is impossible without a comprehensive QA strategy. How can we accelerate software delivery without sacrificing quality? Join this presentation and you will find out why QA and Ops have a complimentary mindset, how you can implement a QAOps framework and why it matters.
 you Hello, everybody. Thanks all so much for joining this session today. I am blessed to virtually be here. I know this is the last talk of the day, so hang in there. I am Marcella, a QA with more than 11 years experience currently working at Cochrane's and Sobison. I'm an open source fan. I've contributed to a lot of open source projects so we can talk about community and contributions all day long, but that's not the point for today. My expertise is around web applications, but I've been involved in a lot of projects, so I like to say that I can easily adapt. For today's presentation, I will try to point out how QROL has changed in the last couple of years, let's say. We see a live and evolution in the role of QA, which becomes more strategic within the team and close to business, let's say, and product issues, while still running the tests. Programming skills for creating automated tests and shift left testing approaches also enter in this evolution package. So quality expectations are increasing day by day. Until a few years ago, if you remember, the QA was the one who just planned and performed manual tests based on documentation and requirements, and that only happened on the testing phase. I like to say that we were just like some monkeys that we were testing, we were clicking here and here, and that was it. We are now releasing products either, let's say, every week or two, and in some cases we are doing this every two hours as part of a continuous delivery process. And the next logic question is what triggered this evolution? And I do have a few answers here. Of course, this is in my opinion, so I think that manual tests that are focusing on validating requirements, finding bugs, and ensuring that nothing has been broken became more expensive. And demotivating more expensive because like I said before that monkey word that we were doing that regression tests that we are currently performed repeatedly for each delivery, meaning, and ensuring that nothing breaks the existing systems. This kind of test is usually time concerning, and we all know that time is funny, right? And I say that it might be demotivating because doing the same things, that's all the time, always in the same phase, it can generate some sort of discomfort. Another thing that I can think of is the next question, what does every business need? I mean, well, it needs innovation, right, with more and more experimentation, which assures higher return of refacement and profitability. And I say that by adopting new tools and testing platforms or methodologies, QA is able to evolve, right, and keep reinventing its strategy. QA must also bring some sort of scalability to its process to test different and bring sustainability that is powered by innovation. And how do we adapt is the question that I'm asking right now. And I do believe that apart from the technical knowledge, which I think it's really important soft skills also play an important role for a QA career. And I say that adaptability is one of those. I don't think, and I'm pretty sure there is no definitive way in which QA teams can assure success. And it's obvious that only with constant growth and evolution of processes, it can steadily bring conviction on its approach and extend the same for businesses as they go out and serve their end users. QA is now on mindset mindset. I know this is a big word, maybe a buzzword these days. But I do believe it is the key to digital transformation that we are all talking about these days. And more, I dare say it's a culture that your team, and maybe your entire company should be involved in. Being involved in the early stages of development or design of the product on the activities varying from, let's say involvement in estimates, technical discussions, or requirements reviews, and so on. QA definitely plays a strategic role. It is a connection between development and operation. In my experience, product teams are often pushed to build and release faster. This is nothing new, I think I already mentioned before, but sometimes accelerated software comes at the expense of quality. So, sacrificing quality is just a short sighted delivery strategy that almost always ends up causing more damage in the long run. DevOps can speed up the development, but what about the QA strategy. And I think that this brings a new flavor to DevOps, known as a QA OPS framework. I dare say that the main focus of QA these days is not in finding bugs, but in preventing them from happening. And if they still do in a controlled time and environment, and before it causes negative impact. So, I think in the exercise and just think about eight or maybe more years back when there were not any mentions about DevOps, no one knew what DevOps meant, right. And I highlighted here the definition of DevOps saying that is the delivery of application changes at the speed of the business. And QA OPS takes the core ideas from continuous testing in DevOps, such as CI CD, and bringing together the teams to work on this pipeline. So yes, QA OPS is something similar to DevOps. Like I said before, because this framework uses the basic approach and mindset already defined in DevOps. But I say it's more complex than that, and I will try to explain this in the following minutes. Why I think so. This role QA OPS role is already present right in the IT industry, and it will be more and more present and required by the companies in the years that the tool follows. Let's clarify first what CI CD means. I will just do a quick description here. CI stands for continuous integration and CD stands for continuous delivery continuous development. Continuous integration is a development practice that requires developers to march their changes back to the main branch as often as possible. Each check-in is then verified by an automated build, allowing teams to detect problems early. Continuous delivery is an extension of continuous integration to make sure that we can release new changes to our customers quickly and in a sustainable way. In theory, with continuous delivery, you can decide to release daily, weekly or whatever suits for your business requirements. However, I said that if you truly want to get the benefits of continuous delivery, you should deploy to production as early as possible to make sure that you release small batches that are easy to trouble shoot in case of a problem. We don't like bugs, right? And for sure we don't like bugs in production. Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes all stages of your production pipeline is released to your customers. There is no human intervention here and only a failed test will prevent a new change to be deployed to production. So, after we do this CI CD introduction going forward, let's see how we can implement QAOPS framework. And there are four main ways to approach the implementation of QAOPS. First is automation by adding automated tests in between continuous integration and continuous delivery. This is one way to approach QAOPS. And then there are three ways here before building an automation framework. QMS study the product in detail to better understand its goals, specifications and functionality, right? And once this analysis has been performed, QA can decide which tests can be automated first, depending on the stage of the product they're working on. The second way is parallel testing. This is used to test multiple parts or components of the application at the same time. The testing process for each component should be independent of the others. You can use different tools that provides parallel testing features or you can use a concept of that to achieve parallel testing where you will write your tests in your favorite programming language so that they run multiple processes at the same time. And of course here parallel testing has hardware dependencies. You will need a high performance system with fast CPUs to implement it, but there is always an alternative, which might be cloud, right? Another way is scalability testing. You will know and I believe that we agree that business growth is good for the company. When you develop a product and people's style start liking it, you have to scale it. Scaling the product includes adding more features and making maybe the existing features better. Last but not least, the integration with DevOps and QA. And here we are talking about a strong collaboration between those teams. You would probably wonder why this QAOps matters and where it can be used. This is especially useful when specific types of testing are needed. Let's say for localization QAOps is almost non-negotiable. QAOps can be extremely useful in regression testing. If you have some previously developed software and you need to quickly release a software enhancement, a patch or a configuration change, QAOps can help in this manner. There are a lot of companies that use QAOps framework. And I want to refer to Facebook for example. I know it's a giant company. I don't work for Facebook. This is something I read for. But Facebook login features enable users to login into millions of apps and websites with their already created Facebook identity and privacy controls. A few years ago, Facebook decided to migrate to Facebook Graph API version 2, ending for login review for all the apps. To ensure that this migration went smoothly, Facebook wanted to test out the new version on the 5,000 larger apps. Unfortunately in the house, they could not do that. I mean, it was basically impossible to do that. But they chose to outsource. And by outsourcing testing, they had all 5,000 apps tested in a month and were able to identify and address critical problems with more than 900 apps. That's why I said that it wouldn't be possible to do that in-house. So QAOps can scale up or down to fit any business size. And next, I want to share with you, let's say one success story where I've been involved. In the project a few years ago, it was a web-based application. And of course, we created an automation framework. We had around 500 tests, if I remember well, written in QCombo. So we've used the BDD approach. If you are wondering why BDD, well, it was because they need this approach for business analysts. And yes, gherkin syntax was the right approach for them at that time. Anyway, we all know that when it comes to BDD, parallel testing is a challenge. So what we did, we used Selenium. For those of you who are not familiar with this tool, Selenium is a Docker-based Selenium grid. Maybe you are wondering and you are thinking that setting up your own Selenium grid might not be hard. But the challenge comes when you start using it to run a lot of tests on it. And this sometimes causes environment issues and stability, right? And this is, and here comes this tool called Selenium. The interesting part here is that we can scale on demand. So we were able to create several Selenium nodes. So the test running time was reduced from eight hours to two hours. So this was a really nice achievement for us at that time. Just to do a briefly, let's say, conclusion here, QAOPS framework is a process, right? That the QA team should be practicing on a daily basis. Of course, not every QA team can do QAOPS, but we try to train our QA to achieve this. And saying this, I do believe that the implementation of the QAOPS framework is defined as an infinite process of learning and putting in use the best QA practices throughout the following phases. And I want to highlight here those phases. First is plan. All the initial things starts with the plan, right? At this point, we come up with a document known as a test plan. The test plan will include and describe the strategy and the objectives that we want to achieve. Second phase is test development. Our main activity and our biggest challenge as QA engineers is test development. In this phase, we perform most of the activities that were defined in the previous phase of planning. And here our testing activities are divided by, let's say, automation testing. And this means writing an execution of automated test scripts according to the test plan, like I said before, in order to meet the client's requirements. So, for this, as you know, we are using the software tools like, let's say, Selenium with all the programming languages like Java, JavaScript, Python, and so on. Robot framework, Cucumber, TestNG and so on. And for format testing, we can use Gmeter, low GI or any other tools for mobile testing. There are plenty of frameworks like APM and for API testing, SOPIOI or Postman can be the right tools. But of course, there are a lot more. The next phase is automate. In order to meet the criteria of higher efficiency, we need to find a way to automate all previously created QA related job. Also, this is the first phase that makes QAOPS framework different from the other traditional approaches in software testing. So, we are using tools like, about Jenkins, Azure DevOps, Maven, and so on. Next phase is trigger. Automating the job with the previously mentioned tools is not the only important thing. And I say that triggering the right tests at the right time is also super important. In this phase of QAOPS framework, from a business aspect, is important to mark and to select the right tests that will be part of the execution in the current CI CD pipeline. Next phase is execute. The objective of this phase is to perform a real time validation before the code goes to production. In this phase, the automated test scripts from different types of testing are executing. In order to increase the efficiency and let's say to reduce the cost, we have combined different ways of testing. For example, execution of automated tests combined with manual testing for verifying the final results in end-to-end testing. And here we have tools like Jenkins and Azure to make this possible from anywhere and from any device. Next phase is release. It's important to keep different versions from software. It's the same with keeping versions from automated tests. For this purpose, we are using tools like SVN or Git in order to have better management and control on the automated test scripts. Last but not least is report. These steps happens in all previous phases somehow. Because for example, when we open a bug ticket that we have found an issue during our testing, what we do, we actually report some anomaly in the system. We have to provide. However, from client's perspective, it's very, very important to have an overall picture of everything that happened previously. For this purpose, of course, we have tools like Jira to generate and to create reports and they are really, really useful. Here I have another example, let's say another success story that we had a while ago. And we, by adopting automation, we managed to reduce time. So our success story here is that after some time, we reduce the sprint from four weeks to two weeks. And again, this might not be a super nice success story that it's, you know, very important, but for us at that time, it was a nice achievement. So, I say that by implementing QAOPS framework as one of our main strategies. We continue to seek out challenges. This is really important in improving our knowledge and work in order to bring the best values for our clients on a daily basis. The main purpose of DevOps is to ensure the software is deployable at any point in time with new features in place. And the collaboration is mainly between the development and operations. In QAOPS, the main purpose is to ensure the quality of the application in terms of its performance or scalability, functionality, security, or even though usability among others. In QAOPS, the operations team mainly communicates and collaborates with the QA team to ensure the continuous delivery of products. And I highlighted here what are why it matters and what are the advantages of using the QAOPS framework. And I say that the most important thing is that using QAOPS framework, we are delivering a higher level of quality and reliability. Thank you. That was all. If you do have questions, I'm pleased to answer you. Okay. Hello, everyone. We are live for questions and answers. There were quite a lot of questions and discussions during your presentation, Marcella, and this is exactly why we chose it. We wanted to generate a discussion. So let me start. I will start randomly. Anna is interested if people are using the QAOPS term before or now, and so far the answer seems to be no. I think the buzzword is for sure. I think it's for sure. Thank you.
 you  Hello, everybody. Thanks all so much for joining this session today. I am blessed to virtually be here. I know this is the last talk of the day, so hang in there.  I am Marcella, a QA with more than 11 years experience currently working at Cochrane's and Sobison. I'm an open source fan. I've contributed to a lot of open source projects so we can talk about community and contributions all day long, but that's not the point for today.  My expertise is around web applications, but I've been involved in a lot of projects, so I like to say that I can easily adapt.  For today's presentation, I will try to point out how QROL has changed in the last couple of years, let's say.  We see a live and evolution in the role of QA, which becomes more strategic within the team and close to business, let's say, and product issues, while still running the tests.  Programming skills for creating automated tests and shift left testing approaches also enter in this evolution package.  So quality expectations are increasing day by day. Until a few years ago, if you remember, the QA was the one who just planned and performed manual tests based on documentation and requirements, and that only happened on the testing phase.  I like to say that we were just like some monkeys that we were testing, we were clicking here and here, and that was it.  We are now releasing products either, let's say, every week or two, and in some cases we are doing this every two hours as part of a continuous delivery process.  And the next logic question is what triggered this evolution?  And I do have a few answers here.  Of course, this is in my opinion, so I think that manual tests that are focusing on validating requirements, finding bugs, and ensuring that nothing has been broken became more expensive.  And demotivating more expensive because like I said before that monkey word that we were doing that regression tests that we are currently performed repeatedly for each delivery, meaning, and ensuring that nothing breaks the existing systems.  This kind of test is usually time concerning, and we all know that time is funny, right?  And I say that it might be demotivating because doing the same things, that's all the time, always in the same phase, it can generate some sort of discomfort.  Another thing that I can think of is the next question, what does every business need?  I mean, well, it needs innovation, right, with more and more experimentation, which assures higher return of refacement and profitability.  And I say that by adopting new tools and testing platforms or methodologies, QA is able to evolve, right, and keep reinventing its strategy.  QA must also bring some sort of scalability to its process to test different and bring sustainability that is powered by innovation.  And how do we adapt is the question that I'm asking right now.  And I do believe that apart from the technical knowledge, which I think it's really important soft skills also play an important role for a QA career.  And I say that adaptability is one of those.  I don't think, and I'm pretty sure there is no definitive way in which QA teams can assure success.  And it's obvious that only with constant growth and evolution of processes, it can steadily bring conviction on its approach and extend the same for businesses as they go out and serve their end users.  QA is now on mindset mindset. I know this is a big word, maybe a buzzword these days.  But I do believe it is the key to digital transformation that we are all talking about these days.  And more, I dare say it's a culture that your team, and maybe your entire company should be involved in.  Being involved in the early stages of development or design of the product on the activities varying from, let's say involvement in estimates, technical discussions, or requirements reviews, and so on.  QA definitely plays a strategic role.  It is a connection between development and operation.  In my experience, product teams are often pushed to build and release faster. This is nothing new, I think I already mentioned before, but sometimes accelerated software comes at the expense of quality.  So, sacrificing quality is just a short sighted delivery strategy that almost always ends up causing more damage in the long run.  DevOps can speed up the development, but what about the QA strategy.  And I think that this brings a new flavor to DevOps, known as a QA OPS framework.  I dare say that the main focus of QA these days is not in finding bugs, but in preventing them from happening.  And if they still do in a controlled time and environment, and before it causes negative impact.  So, I think in the exercise and just think about eight or maybe more years back when there were not any mentions about DevOps, no one knew what DevOps meant, right.  And I highlighted here the definition of DevOps saying that is the delivery of application changes at the speed of the business.  And QA OPS takes the core ideas from continuous testing in DevOps, such as CI CD, and bringing together the teams to work on this pipeline.  So yes, QA OPS is something similar to DevOps.  Like I said before, because this framework uses the basic approach and mindset already defined in DevOps.  But I say it's more complex than that, and I will try to explain this in the following minutes.  Why I think so.  This role QA OPS role is already present right in the IT industry, and it will be more and more present and required by the companies in the years that the tool follows.  Let's clarify first what CI CD means.  I will just do a quick description here. CI stands for continuous integration and CD stands for continuous delivery continuous development.  Continuous integration is a development practice that requires developers to march their changes back to the main branch as often as possible.  Each check-in is then verified by an automated build, allowing teams to detect problems early.  Continuous delivery is an extension of continuous integration to make sure that we can release new changes to our customers quickly and in a sustainable way.  In theory, with continuous delivery, you can decide to release daily, weekly or whatever suits for your business requirements.  However, I said that if you truly want to get the benefits of continuous delivery, you should deploy to production as early as possible to make sure that you release small batches that are easy to trouble shoot in case of a problem.  We don't like bugs, right? And for sure we don't like bugs in production.  Continuous deployment goes one step further than continuous delivery.  With this practice, every change that passes all stages of your production pipeline is released to your customers.  There is no human intervention here and only a failed test will prevent a new change to be deployed to production.  So, after we do this CI CD introduction going forward, let's see how we can implement QAOPS framework.  And there are four main ways to approach the implementation of QAOPS.  First is automation by adding automated tests in between continuous integration and continuous delivery. This is one way to approach QAOPS.  And then there are three ways here before building an automation framework. QMS study the product in detail to better understand its goals, specifications and functionality, right?  And once this analysis has been performed, QA can decide which tests can be automated first, depending on the stage of the product they're working on.  The second way is parallel testing. This is used to test multiple parts or components of the application at the same time.  The testing process for each component should be independent of the others.  You can use different tools that provides parallel testing features or you can use a concept of that to achieve parallel testing where you will write your tests in your favorite programming language so that they run multiple processes at the same time.  And of course here parallel testing has hardware dependencies.  You will need a high performance system with fast CPUs to implement it, but there is always an alternative, which might be cloud, right?  Another way is scalability testing.  You will know and I believe that we agree that business growth is good for the company.  When you develop a product and people's style start liking it, you have to scale it.  Scaling the product includes adding more features and making maybe the existing features better.  Last but not least, the integration with DevOps and QA. And here we are talking about a strong collaboration between those teams.  You would probably wonder why this QAOps matters and where it can be used.  This is especially useful when specific types of testing are needed.  Let's say for localization QAOps is almost non-negotiable. QAOps can be extremely useful in regression testing.  If you have some previously developed software and you need to quickly release a software enhancement, a patch or a configuration change, QAOps can help in this manner.  There are a lot of companies that use QAOps framework.  And I want to refer to Facebook for example.  I know it's a giant company. I don't work for Facebook. This is something I read for.  But Facebook login features enable users to login into millions of apps and websites with their already created Facebook identity and privacy controls.  A few years ago, Facebook decided to migrate to Facebook Graph API version 2, ending for login review for all the apps.  To ensure that this migration went smoothly, Facebook wanted to test out the new version on the 5,000 larger apps.  Unfortunately in the house, they could not do that. I mean, it was basically impossible to do that.  But they chose to outsource.  And by outsourcing testing, they had all 5,000 apps tested in a month and were able to identify and address critical problems with more than 900 apps.  That's why I said that it wouldn't be possible to do that in-house.  So QAOps can scale up or down to fit any business size.  And next, I want to share with you, let's say one success story where I've been involved.  In the project a few years ago, it was a web-based application.  And of course, we created an automation framework.  We had around 500 tests, if I remember well, written in QCombo.  So we've used the BDD approach.  If you are wondering why BDD, well, it was because they need this approach for business analysts.  And yes, gherkin syntax was the right approach for them at that time.  Anyway, we all know that when it comes to BDD, parallel testing is a challenge.  So what we did, we used Selenium.  For those of you who are not familiar with this tool, Selenium is a Docker-based Selenium grid.  Maybe you are wondering and you are thinking that setting up your own Selenium grid might not be hard.  But the challenge comes when you start using it to run a lot of tests on it.  And this sometimes causes environment issues and stability, right?  And this is, and here comes this tool called Selenium.  The interesting part here is that we can scale on demand. So we were able to create several Selenium nodes.  So the test running time was reduced from eight hours to two hours.  So this was a really nice achievement for us at that time.  Just to do a briefly, let's say, conclusion here, QAOPS framework is a process, right?  That the QA team should be practicing on a daily basis.  Of course, not every QA team can do QAOPS, but we try to train our QA to achieve this.  And saying this, I do believe that the implementation of the QAOPS framework is defined as an infinite process of learning and putting in use the best QA practices throughout the following phases.  And I want to highlight here those phases.  First is plan.  All the initial things starts with the plan, right?  At this point, we come up with a document known as a test plan.  The test plan will include and describe the strategy and the objectives that we want to achieve.  Second phase is test development.  Our main activity and our biggest challenge as QA engineers is test development.  In this phase, we perform most of the activities that were defined in the previous phase of planning.  And here our testing activities are divided by, let's say, automation testing.  And this means writing an execution of automated test scripts according to the test plan, like I said before, in order to meet the client's requirements.  So, for this, as you know, we are using the software tools like, let's say, Selenium with all the programming languages like Java, JavaScript, Python, and so on.  Robot framework, Cucumber, TestNG and so on.  And for format testing, we can use Gmeter, low GI or any other tools for mobile testing. There are plenty of frameworks like APM and for API testing, SOPIOI or Postman can be the right tools.  But of course, there are a lot more.  The next phase is automate. In order to meet the criteria of higher efficiency, we need to find a way to automate all previously created QA related job.  Also, this is the first phase that makes QAOPS framework different from the other traditional approaches in software testing.  So, we are using tools like, about Jenkins, Azure DevOps, Maven, and so on.  Next phase is trigger.  Automating the job with the previously mentioned tools is not the only important thing. And I say that triggering the right tests at the right time is also super important.  In this phase of QAOPS framework, from a business aspect, is important to mark and to select the right tests that will be part of the execution in the current CI CD pipeline.  Next phase is execute. The objective of this phase is to perform a real time validation before the code goes to production.  In this phase, the automated test scripts from different types of testing are executing.  In order to increase the efficiency and let's say to reduce the cost, we have combined different ways of testing.  For example, execution of automated tests combined with manual testing for verifying the final results in end-to-end testing.  And here we have tools like Jenkins and Azure to make this possible from anywhere and from any device.  Next phase is release.  It's important to keep different versions from software.  It's the same with keeping versions from automated tests.  For this purpose, we are using tools like SVN or Git in order to have better management and control on the automated test scripts.  Last but not least is report.  These steps happens in all previous phases somehow.  Because for example, when we open a bug ticket that we have found an issue during our testing, what we do, we actually report some anomaly in the system.  We have to provide. However, from client's perspective, it's very, very important to have an overall picture of everything that happened previously.  For this purpose, of course, we have tools like Jira to generate and to create reports and they are really, really useful.  Here I have another example, let's say another success story that we had a while ago.  And we, by adopting automation, we managed to reduce time.  So our success story here is that after some time, we reduce the sprint from four weeks to two weeks.  And again, this might not be a super nice success story that it's, you know, very important, but for us at that time, it was a nice achievement.  So, I say that by implementing QAOPS framework as one of our main strategies.  We continue to seek out challenges. This is really important in improving our knowledge and work in order to bring the best values for our clients on a daily basis.  The main purpose of DevOps is to ensure the software is deployable at any point in time with new features in place.  And the collaboration is mainly between the development and operations.  In QAOPS, the main purpose is to ensure the quality of the application in terms of its performance or scalability, functionality, security, or even though usability among others.  In QAOPS, the operations team mainly communicates and collaborates with the QA team to ensure the continuous delivery of products.  And I highlighted here what are why it matters and what are the advantages of using the QAOPS framework.  And I say that the most important thing is that using QAOPS framework, we are delivering a higher level of quality and reliability.  Thank you. That was all.  If you do have questions, I'm pleased to answer you.  Okay. Hello, everyone. We are live for questions and answers.  There were quite a lot of questions and discussions during your presentation, Marcella, and this is exactly why we chose it.  We wanted to generate a discussion.  So let me start.  I will start randomly.  Anna is interested if people are using the QAOPS term before or now, and so far the answer seems to be no.  I think the buzzword is for sure.  I think it's for sure.  Thank you.
qaops_0_167.png qaops_168_947.png qaops_948_1355.png qaops_1356_2267.png qaops_2268_11579.png qaops_11580_12839.png qaops_12840_14603.png qaops_14604_17843.png qaops_17844_20783.png qaops_20784_25943.png qaops_25944_38267.png qaops_38268_39419.png qaops_39420_41951.png qaops_41952_42203.png qaops_42204_42479.png qaops_42480_42539.png qaops_42540_42599.png qaops_42600_42647.png qaops_42648_42755.png qaops_42756_42803.png qaops_42804_42971.png qaops_42972_43019.png qaops_43020_43067.png qaops_43068_43235.png qaops_43236_43295.png qaops_43296_43343.png qaops_43344_43391.png qaops_43392_43439.png qaops_43440_43715.png qaops_43716_43979.png qaops_43980_44063.png qaops_44064_44111.png qaops_44112_44159.png qaops_44160_44219.png qaops_44220_44267.png qaops_44268_45143.png qaops_45144_45261.png