what's going on this is Alex USA days uh so today we're going to talk about shift left and shift right development methodologies this is actually uh the last uh video in the section for the development methodologies after that we will move from section two into section three where we will talk about types of testing tests plans test creation and overall I'll give you my methods on creating test plans test cases test matrixes and approach to managing testing overall in general I will mostly focus on what I've been using from my experience and types of tests are that are the most popular ones even though I'll probably list all of them or whatever is out there but mostly going to focus on what is really Hands-On and being used uh in different places okay so uh but on the today's topic we're going to talk about shift left and shift right so uh essentially if you take a look at this coverage test coverage based on the approach was shift left methodology you just tend to move everything or shift everything to the left in terms of testing and you want to start test testing as early as possible that's why you see its spikes here in the development stage starting from the design spikes into development um goes a little bit down in the test environment overall and even less in deployment and maintenance stage right this is with a shift left so shift left is moving tests and activities closer to development and emphasis on problem prevention this is what is shift left all about and then there is shift right and this is another concept where you actually uh move testing closer to production so you focus on controlled production testing so this way you see there's still some tests happen in test environment but a lot of testing happen in on deployment after deployment in production uh during the maintenance stage so that's the the core idea uh and that's the core difference between shift left and shift right now if we're going to talk about tools and the approaches and what is actually been used so in shift left we want to focus uh and work on early test planning so QA and overall team is actually participating in uh customer well not not exactly customer emitting or client meeting but during groomings uh you will talk with product owners or product manager depending who's running in the team running the whole uh the process of the you know moving forward all the features and everything that was on the plate for stakeholders but essentially you want to work early with the team and plan test accordingly based on the requirements as the requirements being created so there is this story or this feature we're going to work on what kind of testing can we do on it like uh what kind of tests and activities we can build in into the story right so it had the creation of the documentation goes hand in hand with the ideas how it's going to be verified how it's going to be testing so this is why it is Shifting left a lot right so work early on test planning then there's a lot of coverage that should be done with unit testing by the developers so a lot of tests that nuclear test Atomic tests very small tests that tests just the functionality on the core level should be covered with unit tests so a lot of emphasis here on actually development taking charge of a big chunk of testing here with unit tests and with integration test so if they have uh different microservices communicating with one another or they have different components of the system coming together all the integration testing also should be done with shift left early on during the development by the developer so it covers a lot in you know the idea to prevent bugs right so it covers a lot of the functionality early on before the code is actually ready or it's in test environment uh then there's also focus on a lower level testing on API testing um could be here also like database testing and back-end testing so before there's actual UI uh there's still some API and some other ways to interact with the system uh not just through the user interface so that type of testing also uh you know prioritize and shift lab so essentially you want to cover as much as possible uh to make sure you prevent issues before they happen before they're discovered uh in the user environment right was it was in the user interface and UI uh so with shift left quality is at the center of product planning design and architecture a couple things that are popular the framework developments that are popular in shift left is tdd and bdd uh so tdd is test driven development where you write your tests first and then you build code for those tests and bdd is a behavior driven development which is uh came from tdd but it's about putting the functionality in plain English how systems should behave using like gherkin language and then essentially building the functionality around that uh bdd Behavior driven approach right I will leave links in the description for shift left for tdd and PDD so you can read about them and learn about them understand them a little bit better but in a nutshell this is what is shift left about so testing early a lot of tests and activities happening and planning happening uh before it actually goes into test environment I'm not even talking about production or maintenance stages but even before test even in development right in Dev environment so what is shift right here well shift right on the other hand is actually uh tends to focus more on production post-production and maintenance so what that means well for example you can do Canary releases so you do smaller batch releases and monitor system how the the system behaves with the new code so for example you will start using only five percent of the users with the new deployment and you will see you will monitor logs and uh whatever transactions are happening in the production to make sure there's nothing going wrong with a smaller batch and if everything's confirmed okay there are no regressions everything looks good then you're going to increase the percentage of users using the new production new system your deployment and essentially you will increase until you have the 100 there so this is one of the approaches into testing and prod right the other approach you can actually feature flag your code so feature flag and code means a the feature that you release you can essentially turn it off immediately so if something's broken in prod and the feature is giving you trouble and normally it is done again if you're doing CI CD approach so you're releasing smaller batches you're not waiting 3 three months to release like a huge build now you ideally release every every week or so then you can feature flag and if something's again if something's not working and product is expected you immediately turn this feature off without even user noticing that okay something was there that was breaking the system right also idea of shift right is monitoring production logs for errors response times uh how's the production handling load and creating automated regression suits in production so large automated regression suits in production end-to-end testing after deployment so it runs through ideally the scenarios should create data and then remove the data so you you're creating tests that are clean and they're not adding any extra data into production aside from you know the test phase while they're executing um shift left and shift right are mostly uh devops terms and a lot of talk about uh shift left and shift right in agile and devops but it is also you know it is also part of QA so if you work specifically in a team that try to implement one of those approaches uh as a q engineer you'll have to participate and you'll have to bring testing either more to the left or more to the right again all of this is more or less based on my experience might be different explanation in the place where you're going to work or implement it differently this is fine I mean a lot of companies just uh Implement things as they wish as they design desire right they just kind of take the core ideas and bend them also shift and left or shift and right doesn't really mean that there's no testing in test environment uh there's still going to be regression end-to-end tests acceptance testing on the UI side uh in the actual test environment but the focus is shifted my personal thought on either shift and left and right I think you have to implement a little bit of everything so you do want to shift left you definitely want to have a lot of coverage early on on the functionality you won't have unit test integration tests you want to have API covered in order to prevent bugs getting into test environment you want to rule out all the bugs before they get to test so the test testing goes smoothly and you don't have to open tons of bugs and send the uh tickets back for the developers to fix them uh but you also want to make sure that your prod is stable and there are no issues in production after the release there's you definitely if your production is testable you definitely want to do a regression in production you definitely want to make sure your release is not breaking you think so I think the the ideal approach is somewhere in between uh of course everything depends on the resources and time frame for the testing that is allowed but uh the best case scenario where you actually have both shift left testing and design and approach implemented some of the shift right as well and also you have uh you know confidence and good coverage in the test environment so whenever you're pushing something through the pipeline you're you're confident that you know you this build uh is not going to break anything in the the features the code is everything's gonna work as expected okay so I will live uh some links to all of those terminologies in the description so you can do some more research and read about them uh yeah leave a like if you like the video subscribe uh to my channel I will post a lot more and again we're moving into more like actual test test cases test creation and uh different tools and so on so we're getting there we're getting into the uh becoming QA professional from pretty much from the scratch okay thanks everyone for watching this was Alex USA days and bye bye