 Hello, everyone. Hi, can you hear that? Yes. Okay. Hello, everyone. Thank you all for attending this session. My name is Chen Fuwen. I'm from the LightHeart company. Today I want to share one topic about lessons learned shift left testing. So it is a quick overview about me. I have more than 17 years of testing and automation experience. Now I'm based in Beijing of China. My prior work experience including Oracle, Motorola, and Siemens. I'm enthusiastic in open source software. Let's jump into our agenda today. First of all, I will introduce some basics about shift left testing. Then followed by why we need shift left testing. Finally, I will show some basic practice from our team. So what is shift left testing? So in order to have a clear understanding about shift left testing, we need to put it into comparison with the typical quality model. As shown in this diagram in the typical quality model both activities are sequential order starting from requirement, design, code, test, list, and maintenance. And the requirement design are given small attention. Code and testing are given much more attention. But which happen in the late, very late in the project life circle. So the issue our defense are found very late which is very expensive to fix that. It also designed failure soft well-delivered on time and poor production quality. Compared with the typical model in the shift left model we try to create one culture where test can be involved earlier in the face earlier face. Even test can begin at the very beginning of this project life circle. Since testing activity start very earlier, so issue or defects can be found earlier and fixed. Therefore testing become effective and better quality product can be achieved. After we learn some basic about shift left testing we know that shift left testing is the idea knowledge is just test machine knowledge. For particular organization for example in Red Hat it has its own way or approach to improvement shift left practice. In Red Hat for real product release or Red Hat enterprise Linux release we adopt DevTouch doc workflow in the shift left. Hello. This song that's video playing is really cool. I apologize for that. Is this a good point? Yeah. I'm so sorry. I'm not sure why the audio is different. Okay. Is now good? For particular organization for example in Red Hat it has its own way or approach to improvement shift left practice. In Red Hat for particular for real product release or Red Hat enterprise Linux release we adopt DevTouch doc workflow in the shift left practice. In the past we used 0.4 model by Elata workflow when we release real product which showing in on the top this page. As we can see testing and docs activities are down to late. After we learn some experience we change it to real shift left workflow showing on the bottom of this page. We shift Dev, we shift test and doc activities to the left as early as possible. In this way issue or defect can be found earlier and less expensive to fix that. Eventually guarantee our product qualities in Red Hat not particular to the real product for any product or service delivered by Red Hat we lay all share the same quality standard. So let me just bring you to the Red Hat quality vision. Red Hat quality vision is the Red Hat quality commitment to the customer about his product and the service. Describe how Red Hat treat quality about his product and the service. Here is the statement to elevate the quality of Red Hat products and the service. In showing water class enterprise great software and service at the speed that meets our customer needs for excellent high-grade cloud experience. Just now I show the quality reading statement. It give customer the quality preview about Red Hat product and service. But they say important that how can we achieve this quality vision. What focus we should have from the QE perspective. There are a few key points worth knowing here. First testing with the portfolio mindset. In Red Hat we deliver open high-grade cloud solution to customer. Which in integrating many multi-product service by applying by applying portfolio mindset. Testing multi-product along the platform at the early at early test faces at the early phase. It will definitely create a better quality solution. Customer driving testing. Customer joint testing apply customer use case into earlier testing. Customer pain points are found at the early phase. A solution with easy, smooth patterned customer experience can be delivered. The third point as earlier test often feeling fast. These are typical philosophy of shift left testing. By inviting shift left practice into software development life circle. Fast quality solid software release can be achieved as well. Final point, automation automation automation always play very critical role in powering shift left testing practice. If your team are going changing from traditional model to shift left calling model, this is a big transition. Perhaps you need to think about how that can be ready. So I suggest there are several key elements you need to care about. Because these elements play a very huge impact on the tradition. First is process. Your team process needed to be optimized for any stakeholders including developers quality engineering, PO or doc letters to do real contributions easily. The cross team interaction is empowered as well. People any stakeholders in the team need to change the mindset. They need to work more closely need to work with each other more collaboratively and also need provide fast feedback to each other. Final is technology. New tools need to be adopted in the whole life cycle management. New skills or knowledge also need to be learned. So now we enter the second part why we need adopt shift left testing practice. In red hearts when we drive towards shift left testing we get a few obvious benefits from that. First is we get a better quality product. In shift left testing practice we execute testing continuously and the test case are executed again and again. In the end it will reduce the fast and eventually we get a better quality product. Second, reduce cost. Since test activity are executed at the early phase so issue or device are found and less is expensive to fix that. So it will reduce project cost. Speed up time to market. We automate everything in the shift left testing practice. So it will increase time to market find a benefit lower the risk since more in shift left testing practice issue or device much more issue or device are prevented rather than detected. That's largely lower the project risk particularly in left heart organization. Another thought when we move forward shift left testing practice is that it help promote our customer-centric plan. Many developers I work with in the past they develop their feature based on their understanding about the comment and the business. However our customer use the software differently from what you assume. So in order to delight the customer and increase customer satisfaction in left heart we transfer from feature view to customer orientation view. We are driving customer strategic strategy. So from QE perspective in applying shift left testing practice QE can completely force on customer use case and customer expectation and apply customer use case into the only testing. This in turn will enable developers to develop a feature which to meet customer real need furthermore after customer file ticket or use case QE can close loop the use case by adding test automate it and execute that in the early phase. Now we end the final part of what is best practice from our team. So what we are doing from our team our team is the quality engineer quality engineer we focus on testing the board component in the product. So what is the board is a library that allowed application to conveniently manage machine it is an upstream project. So how we do testing before QE we have an idea of test pyramid we categorize test into tier different level like tier pyramid as showing in the background starting from the bottom tier one test typically presenting unit test for the bottom to the top tier five test typical represent UI or export test in the past all the tier test almost all the tier test will be executed in the test phase which is very late position in the software development left circle we notice the issue and the defects of found in the test phase and nearby the cost is passive after we recognize shift left test practice value we change it so how we test now in label QE we recognize shift left testing equal to upstream first testing as I mentioned previously the board is upstream project we try to move more tier test or level test to the upstream so workflow is quite simple as showing in the in this page it is started by a patch post to upstream code then it will notify tester tester will prepare one test environment and build one compute the label component with patch applied then certain type cases are selected and executed like finally results will be sent out in assembly particular to label QE team all shift left practice is more many more test cases into the upstream and execute that on the upstream code finally I want to give some summary about practice first plan non-functional test earlier even as requirement review you can plan your performance or security is such a testing pair with developers QE and developer need more work closely they need to share their understanding about requirement upstream first approach particular to deeply remote QE team we find issue or defense as upstream code we also pour much more cases executed upstream the final practice is automate anything you can automate test case pipeline eventually automation help you a lot so with that I think I finish my slides presentation part presentation part thank you so much for that presentation and now it looks like we have a number of questions that have come in for you Chen Fu so let's start with the very first one Lenny asks what have you found helpful in reducing testing fatigue when design requirements change a lot see the question I try to understand more so there in testing practice we we made a mid-sign situation that design or recommend subject to constant changes so issue live testing we encourage that college engineering can be earlier involve a requirement and design the view and it shows a common understanding about design or requirements so by doing that because by doing that we have more opportunity to discuss and show common understanding so QE can have more early upon the test cases and even automation script for that so I think that can be one way to reduce test theoretical sense like this okay I guess one of the questions that Lenny wanted to ask as well is how do you implement shift test shift web testing in a way that would be adaptable with design requirements change in response to customer feedback yes we are to adopt customer feedback into the loop in the shift web testing the first way is that when we test QE engineering to participate in the earlier requirement or design review like to know customer use cases so when the review they can contribute the idea and submit comments about the requirement or the design the second way is that QE can close one loop for example if customer files and tickets or files and use cases so QE can learn the same thing and after that they can bring that to their test case and automate that and in the next loop they can execute that as well okay if the feature engineer may feel that we're testing a rough draft as opposed to testing in the waterfall style when we test after the feature is done I'm sorry that was just an example of the previous question and then the next question is how do you suggest that we test things like requirements and design specs yes we we know that if QE can be involved to earlier to review with the requirement the there are different way can be a test slide one way is that they can just mention that they can put in some about use case so they can be contribute question the requirement and when the requirement is not meet customer need they can suggestion testing requirement doesn't mean that need to write a script or code standard is the review and contribution from the customer use point of view so in that way when developer implementation they can really meet the customer need at the design phase or after design phase implementation can really delight the customer yes well thank you so much for this talk this is really awesome if anyone would like to talk with Chen Fu after this we do have a breakout room I just posted the link in the chat and Chen Fu will be there and everyone can talk and ask more questions