Welcome to the session from Rigidity to Resiliency and Evolutionary Tale of Selenium-Based Frameworks by Tariq King. And without further delay, over to you, Tariq. Thank you, Ankit. Let me just share my screen. All right, hello, everyone. My name is Tariq King, and I'm pretty thrilled to be here presenting this session at Selenium-Conf from Rigidity to Resiliency and Evolutionary Tale of Selenium-Based Frameworks. So, who am I really to be talking about this stuff? I'm just a guy that fell in love with software quality and testing, which is a hard problem while I was in college. When it comes to professional experience, I'd started off my career at IBM as a research fellow while I was pursuing my PhD. And after that, I decided that industry actually wasn't for me and I joined North Dakota State University as an assistant professor. So, I was there for about three years and as life would have it, I would realize that it wasn't that industry wasn't for me, it was that the company culture was more important than working for a big name. Of course, if you can work for a big name that has a great culture, that's awesome. But sometimes that doesn't always align. And so, I left academia and joined Ultimate Software as a test architect and would spend most of my career there as a test architect. And actually, the bulk of this talk is around my experiences there as a test architect, but eventually it would grow through up the ranks into eventually the head of their quality program. Most recently, I'm known as being the chief scientist at TAS AI, where a bunch of hacks there, including platform leader, head of R&D and that sort of stuff. All right, so let's get into it. So Ultimate Software, more recently, you guys may know it as UKG, the Ultimate Chronoscrew, but back then it was Ultimate Software and their tagline was People First. And this is true because they put their employees first, but also the software that we were building was all about people. It was all about the employee everywhere from recruiting to retirement, right? And so what this meant was that there was a main product, Ultipro, which was all about human capital management. And it covered all aspects of the employee, all sorts of complex domains from human resources to payroll to compliance and so on and so forth. But there weren't separate products. It was all one unified solution. So all of those domains had to come together under one umbrella, which meant that testing within each domain and across domains was of utmost importance. So in terms of the software process, there was an agile process in place and so you had cross-functional teams with stakeholders like product owners, business analysts, software engineers, quality engineers and later on ops folks. And then you had validation and verification happening throughout the lifecycle, right? At the requirements, design, unit integration, and of course the system levels. So, I was coming into a pretty established software process and a quality program that was already running. And as a test architect, it was really about enabling the teams to succeed. I wasn't assigned to any one particular team. So I worked across all the engineering teams in the company and helped them, I don't like the term best practices, but with good software engineering and testing practices and tools and frameworks. And however, I would find out really quickly after joining that I would be forming a team to work on a very specific mission. And that mission was really to replace their UI testing framework, a framework called SWOT. That was a homegrown framework. We'll talk about SWOT quite a bit and I didn't make up that logo. That's the actual logo that they came up with back then. But I needed to replace SWOT with a new framework that was functional, maintainable and sustainable. And as part of that, also go through the process of rolling out the framework and migrating what was about 200,000 test scripts and have all the teams run those continuously across all browsers, right? And so, you get a mission and a task like that. And I always have one thing that I practice whenever I'm given something new. I'm new to the organization at this point and it's a new project and a very critical one. And I always know that the task is never just the task. The task always is a little bit more than what is described because what is usually described is the now. And you always must consider the past as well as the now as well as any future considerations, right? And so, this is important not just from a technical perspective, but also from a people and change management point of view. And so, what was in the past? Well, it wasn't really in the past because it was still being used but there was the legacy product, the back office. I think we've all been there and it was tested using Mercury WinRunner. So there's all these WinRunner automation scripts and that back office was actually quite loaded in terms of functionality and features. And the features that were not any web product and so this was heavily used by customers and the very critical and important customers. And so it was not something that should just be ignored, right? So what about the current last gate, right? And if you didn't know about ultimate software from this picture, you probably then you once the big three came to Miami and we sponsored the Heat Jersey because the logo was all over there. But this was literally my face. I think when I saw what was going on at ultimate and how complex everything was, there were 19 teams, over 200 people, 100 engineers, 60 testers, talking about six million lines of code at that time and all of these tests, right? And quite a high percentage of them automated which was remarkable that you had such a good ratio but not everything was all cookies and cream, right? The framework, like I mentioned SWOT also integrated with fitness and the windrunner stuff, like there was a lot going on there that needed to be unpacked. In terms of platforms, it was a .NET shop. So we're running on Windows primarily and on Firefox and IE where the primary browsers back then. And so let's talk about SWOT. For me SWOT was the now of what everyone was just trying to kind of get rid of and get off of, right? And, you know, looking at it, there was a lot of different aspects. SWOT stands for Simple Web Automation Toolkit and really was meant to automate web application testing in multiple browsers, right? We had the .NET product on the web. SWOT had an editor with UI recording and it integrates with fitness to allow more non-technical QA folks to be able to write tests. So what do I mean by that? I mean, if you consider the C-sharp syntax for SWOT, which was really just embedded in the programming language versus the fitness kind of wiki style, it was easier in terms of technical know-how, I guess, to write. And, you know, as with any framework that's meant to do something, if you just look at a quick example of what was going on in SWOT, so these are some high level test steps like navigating to Google, searching for Agile Alliance, clicking on the manifesto and then making sure that the manifesto actually is displayed. And if we did this in SWOT, this is what the script would look like, actually a part of the script. And you start to notice some things right away. Like you start to notice that there's expressions embedded in here that really map to what we would call selectors, but they're very well ingrained using regular expressions. There's some interesting non-determinism, there's a sleep in there, there's a lot of stuff. And imagine these were very large files and so there was a lot going on. And so when you thought about SWOT, this is the picture that would come to mind. It was supposed to be simple, but it actually was not so simple at all. From the perspective of the design itself, it was a very stovepipe mode of building the framework. There was not a lot of reuse and very limited abstractions. Of course you had the fitness on top of everything, but everything was pretty limited, right? There was kind of just focus on the company's text. Which is to be expected.net, SQL Server, i.e Firefox. And then this was the hard part. The hard part was that there was really an average of like three months, right? To get anything updated in SWOT, right? And again, sometimes these were most usually over the three month mark, but anywhere between one and six months cadence for releases to the framework. And the team that was building this was really just primarily doing bug fixes. There weren't really any enhancements coming. It was just trying to kind of keep pace with things. So that was the rigidity of the kind of stovepipe nature. On the other side, then these scripts, as you saw, there was a lot of implementation coupling where the test script itself just referred to elements of the page. It was not very readable. There was the non-determinism in there. And it was very difficult. Another part of the fragility was the browsers, right? Like this was a framework that had to handle each and every browser on its own, homegrown, keeping pace with those browser releases. Very hard problem, no vendor backing from any of these things. It was all just on those engineers building the framework. And then the users as well, right? You had your technical internal, there was no kind of external contributors. So there was just a lot of kind of churn on the framework itself and not many people to kind of help, right? So the first thing that you're probably thinking at the Selenium conference is like, well, why didn't they just use Selenium, right? Well, there was no Selenium at the time, right? There was no spoon. Selenium was still in the making and I shouldn't say that there was no Selenium. There was pieces of Selenium all over the place, kind of popping up, I guess. And every company I think was working on their own version of trying to solve this problem. But in terms of what we know Selenium to be now and where the project kind of went, that wasn't there, right? And as I said, it was not just ultimate software. It was engineering teams across the globe that were dealing with this problem of testing web applications from the user interface and dealing with the pace of browser turnaround and so on and so forth. So that was the current landscape. And obviously you don't know everything in the future but one thing that we didn't know in the future and this is actually a glimpse into the future there, that mobile was coming, right? That we had a web product and then we would go mobile and if there's a mobile product then there needs to be mobile testing, right? This is our actual LT lab a few years later. So what is the kind of scenario here? Well, you start to get the team together and it wasn't a big team. It was literally two test architects and two interns but we also had a lot of support from other engineers, full-time engineers in the organization. And we actually called it the virtual team because we considered those engineers that were embedded on other teams that had a full-time day-to-day that were also working on the framework as part of the team, right? And we set out to do mission possible, right? Where we thought that, hey, you know what? This is not an impossible task. We just have to consider all these different variables but it's something that can be done. And it's interesting because the first thing that you do in a situation like this is do your research and see what is out there and what was happening. And thankfully, after I first joined the company the first conference that they sent me to I joined in January and then like a few months later they were sending me to the Selenium Conference in London. And Selenium had really picked up since SWAT had been incepted. And it was starting to get the support of a lot of the major browser companies and there was a lot of community around it. And it was one of those things where I said like, you know what? This is something that we really ought to pay attention to and this is probably where we need to go with this so that the maintenance isn't on the development team that is building the framework and that we have a community of support. Obviously like a lot of ex-unit frameworks to support different languages. And at the time BDD was also a huge kind of push towards this ubiquitous language. And so you started to see patterns arising like the page object pattern and a lot of application modeling going on and being able to separate that model and reference it so that the test didn't have to hard code those things. You had all of your support from a test driver standpoint was set up and teared down.  This was all there from the unit tests but it was now really heavily being used for all the UI testing and stuff that was going on as well. And then of course your BDD and kind of Gherkin give them and then support. So, these were kind of some of the trends that were happening in the space. And it was important to understand that like each of these things, the modeling, right? Abstracting the user interfaces and applying that in the context of a web application was something that you could look at and say like, yes, you know what? It makes sense to kind of model it like this and separate it. You talk about good design principles and then have the behaviors also embedded there with that abstraction of the user interface. It was quite natural. And then the scaffolding that comes along with it, right? That is now easy to write those tests very clean. You can document them like using a kind of fluent interface by chaining these things together. And then on top of all that support and infrastructure for driving test execution there was also things like the Selenium grid and all these other pieces that were really kind of taking off and helping to transform that landscape. And then of course, there's BDD, many different tools. This is StoryQ, but you know, I wanted to see that there was always a push even from the SWAT days to kind of bring the business user closer to the testing because they're the ones that have to accept the stories and so on and so forth. And so again, you were seeing fluent interfaces with Gherkin style and being able to execute and look at the results of tests using this kind of domain specific language at this level. All right, so what was our solution? Our solution was to build Echo. And Echo was really a middleware architecture that sat on top of Selenium and other frameworks, right? And the key thing here is that you wanted a level of abstraction above these frameworks. So that if you had to move off of any of these frameworks, you wouldn't need to necessarily get rid of the entire Echo framework. You would just need to reimplement those interfaces with the other framework. In addition, you're talking about moving towards the future and being extensible, integrating things like Opium for mobile, also thinking about the back office and being able to pull in coded UI to still test the back office and the runner scripts could go away or be converted and then other things, right? Database interactions. And so Echo was built on those principles that were good from the community, right? The application modeling and then having layers that represented, you know, levels, multiple levels of abstraction to help with this problem. First being the test abstraction layer, which is really your internal DSL. And then taking those commands from the internal DSL and translating them into something executable. But I was on top of an abstraction for the framework and then an interaction for the framework, right? So you have these multiple chains and of course there were some common and shared resources amongst these things. But now you have this kind of framework in place for integrating and translating tests from a relatively high level all the way down to the execution level and then getting the results, right? And so what does this really look like when I talk about it? How was it even different from just straight up Selenium? Well, there was a lot more modeling that we wanted to make sure we did up front. You know, the product, the app was one level. You had the whole page, but you also had different controls like the menu bar, the button bar. You had other controls that you could model. The grids were a big thing because you wanted to be sure that you could manipulate the grids, both the kind of header and footer of the grid of the grid control itself, as well as verify the roles of different things. And there was a lot of different implementations for these. And so the kind of language was this fluid interface where you could do like, okay, here's the application context, here's the product, here's the page. I can do an action like a click or a blur or an assertion, some sort of verification. And then that actually changed down into the different elements on the pages, right? And you get IntelliSense and all these good things that come along with it. So some examples of some standard commands, right?  We call them macros at the time. And then also the database interaction that we needed for not having to, if you weren't doing a end-to-end journey and you just wanted to do some direct linking and do some setup that you could actually manipulate the data stores and so on and so forth. And so this internal DSL again, nothing super special, except the key parts of the abstractions that were in place to make it very extensible. And, you know, we built all sorts of stuff for the teams, test templates. There was a lot of configuration and then, you know, documentation of course. And, you know, we had, what I would call a lot of good hits, right? Through this mission, right? The framework itself was very unified. It was quite flexible. You didn't have the rigid stove pipe nature of development. It was easy to add other things in, like we didn't put Sikoli and some of those things in there from the beginning. And it was quite scalable, heavily due to Selenium and those aspects that were happening with the Selenium grid. And then, you know, the rollout was successful. We had releases that were more of on a continuous basis. And then we became contributors and committers to the Selenium project, right? So now we were part of this community that was not only benefiting from this framework, but now contributing and giving back to the community in that respect. I would say somebody, the misses here was that even though this was better than the SWOT syntax, it was still very technical and because it was embedded in the programming language, it was very hard to kind of, you know, just think that you could get away from the technical aspect of it and have a non-technical user write test. It was still inherently fragile because of the selector problem. Even though you had it in a separate abstraction, if those selectors weren't written properly or if there was a change, you still had to go update it. It's just, it was easier to update in one place. And then there was some accidental fragility because we were an internal DSL embedded in the programming language. You found a lot of folks doing all sorts of weird and trying all sorts of weird things who weren't really programmers, but were just kind of playing around with learning to program at that point and putting those things in automation, which kind of introduced fragility. Governance and standards then became a huge thing that we didn't have immediately that we knew we needed to get to. And while we solved the problem and got it working for the company, there was kind of like this bigger or biggest picture that we missed, right? A lot of the integration with the other aspects of the business were areas of opportunity. And so, one of the first things that was easy to kind of put in place was guidance, right? Like if you don't walk on this path, you could really harm yourself. And so we started to put standards and playbooks into place. And another school that we had a lot of that guidance there for UI testing, which is an important thing to have. But then we thought, well, what if we could go further, right? Like the Japanese art of pokoyok, which is mistake-proofing, like can we build it in such a way that people actually can't go and make those mistakes but it only fits in a particular way. And that's where we started thinking about internal versus external domain specific languages, right? And, you know, internal DSL, which is embedded in the host language just opens up a lot for people to do. Whereas an external DSL, which is kind of a separate standalone language with an independent syntax is harder to build but gives you full control over what people can and cannot do because you just throw compiler errors if they're doing something that's not allowed. And so since we had like a good foundation with echo, what we did was that we extended echo with legend, right? Which was a Visual Studio plugin and a full-fledged external DSL that had its own compiler, own syntax and quite a lot of integration. So there was this DSL editor that you could write your tests in still within Visual Studio as a DS plugin. And you had like a sweet information section that could have the information about this particular test we'll dive in and see how some of these things work. You could declare your products or whatever contacts you were dealing with. You had your setup structures and then you had your test scenarios, right? And you had very high level descriptive kind of English level descriptions, but then you could actually implement those steps with automation, right? So the three lines below the given a login to ultipro are actually pulling from the commands and the page objects from echo and allowing the person to write automation at this level and it's still very readable and so on and so forth. And we integrated a lot with it, the data-driven testing, we had test tagging and so on and so forth. So we're gonna run through some of these pretty quickly. But there was now the bigger or biggest picture that I talk about, the requirements integration, right? You could actually come and create a test that was based on a user story, right? So you create a new test and you say, hey, I wanna create a test that's based on an existing user story in a system of record like G-Rail. And then once you enter in the identifier, unique identifier for that user story, then your test is automatically kind of populated with the documentation from there and it's well-structured, the story is linked already and so on and so forth. And you have kind of like the beginnings of this descriptive test that you want. And then, of course, you can navigate straight to JIRA and see the user story that was used to generate this, right? And so the process again, right? For business level users was now in place. And of course then there's automation, right? You then needed to be able to take those steps and start to refine them by adding automation, right? Which we kind of talked about how then you start to now go through and you can, you know, give your context and if you're only logging page, you'll now from that point, see all the page objects and commands that are relevant to that page. And it kind of guides the user, right? The poker yoke kind of guiding the user towards what bit is allowed and allowable in this particular, scenario.  Like we could actually hide away everything and expand. And so that we have these multiple level of abstractions even at the language level. And then while executing, you had the power of being able to actually set breakpoints at, you know, the automation level, right? Which is still very high level here. And step through your tests, right? And, you know, here you just see an example where we kind of step over the application launches and step over again and let it run. But you can certainly think about debugging your automation at this level as well. And then, you know, later on drilling into it. There is also formal parameters and the data manager. So it wasn't just these hard coded strings, right? You still wanted to be able to leverage data-driven testing. And so the syntax itself supported just adding formal parameters to your test and leveraging the data manager from within the JOS Studio, just a widget that we created that let you, you know, cycle through the different tests that were there. And if there were any parameters in the test, then you could go ahead and start populating the data-driven aspects of your tests. So very convenient for everything to kind of be there all in one spot. And then, you know, part of this was then, entire process was thinking about, well, what about the test inventory and all the documentation, right? That someone shouldn't have to open these projects to kind of get to it.  Legend can also be a source of truth to populate the test inventory because user stories will get outdated over time. It may not be revisited, but the test is something that kind of keeps, you know, the life of it as at least the automation as it lives on. And so let's sink that over to, in this case, is Microsoft test manager and all the steps kind of come over. And of course, you could think of running this task daily, nightly, but if you just updated the test, you could just push it and update that test, right? So that was pretty cool. And, you know, part of it was then also being able to share and communicate, right? So you could copy a link to the work item in the repository, share it with a colleague and say, hey, could you review this? And then they can click and go straight. All this was just the convenience of being in the same environment, but also having external stakeholders that may be in other systems like the test inventory. And then last but not least was the idea of really building on categorization and doing selective regression all from within the legend environment, right? So it was like, hey, how can we facilitate modeling the application domain and having that model available to test so that folks can leverage it, right? So if this is a test that belongs to the, you know, deductions category, or if it is also a test that is related to payroll, then you can, you know, add those things there.  We did things like house synonyms and stuff like that. And then you could go through and search by browse, by tag, by author and by project, and then actually selectively execute tests by, you know, either of those things, right? And let's run the test. So that was kind of like the crux of legend where we kind of took echo to a new level by now thinking of the end user as someone who may not be super technical, right? And that may need more guidance and was able to kind of now successfully write tests because they had all the guidance. And then in addition, think about all of the process that actually goes into collaborating to write this automation, use it and so on and so forth. All right. So, I mean, we enjoyed building these things. We shared our experiences, right? So this is us at the international symposium for software testing and analysis, ISTA 2014. From my academic background, we always try to go to industry as well as academic conferences, especially those that were joined. So we published papers, paper on Echo was at Jamaica, which is a workshop on joining academia and industry contributions in test automation. And ISTA, I just mentioned, and then my first public speaking talk in industry was actually at Star West. And I wrote a paper that outlined both of these things and talks about both Echo and legend as part of that, right? All right. So why even am I telling you about this journey and going through this evolutionary tale with you? And well, the first thing is really that the reason that we were able to do all these things with Echo and with legend was because it was built on Selenium. So, you know, to the creators of Selenium, like Kudos and thank you, Jason Huggins, Simon Stewart, Jim Evans, all the committers, the entire community, you know, it's not even specifically just about the framework, but about the problem because Jason and Simon and Jim were focusing on the big picture that Selenium now represents it had a ripple effect that teams didn't have to worry about those problems that Selenium was solving and could focus on other problems and other big pictures, right? And that was great, you know, but it also uncovered, so what Selenium did also uncovered some of the challenges that were inherent with UI automation and it's not just Selenium, right? Some of those were inherent and some of those were because of the solution, but anything that's based on the implementation and anything that's based on the DAW is going to be inherently fragile. And we are still really lacking when it comes to automation as we call this because there's still limited reuse, there's not reuse across applications, there's not much generality, there's very hard maintenance that goes into, especially if you don't do these things right and follow good practices, right? And so that gets me to like, what is the future of this stuff and where are we going, right? And you know, in my role as chief scientist, like I've seen a lot of the application of AI to software testing. One of the cool things is the use of AI for things like element detection, right? So instead of using hard-coded selectors, actually training computer vision models to recognize these elements and identify them, even chop them up on the screen and use them as training data and so on and so forth. And we're already seeing some of that integration happen into Selenium and Appium and Cypress, right? Which is great because we need to see other innovations happening in this phase. And there's this just whole area of using other aspects of AI machine learning to drive the testing process and reinforcement learning, you know, having the box explore and do trial and error is also a very resilient thing, right? Because the resiliency of the framework depends on these methods used to identify things and locate things and to navigate through the application which could change, right? And reinforcement learning and computer vision help us to deal with a lot of that and move away from, you know, the fragility, right? Because if you think about it, even legend as great as it was still suffered from those fragility issues, right? And so, you know, our path to resiliency really is to continue to invest in a lot more innovations around bringing those bigger and biggest picture problems to the forefront of engineering teams that still need to be solved. And of course, Selenium still plays a role underneath the HUD as an interaction framework and as a community and as something that helps to scale and go on and kind of build that out to the best of your ability and continue to work on these other problems, right? And what we're seeing is we're seeing AI and machine learning start to enhance portions of the testing tools that are out there in frameworks. But I think as we move on, we'll start to see it look at entire toolstacks and different dimensions of testing but still require human input. But the cool thing about this technology is that over time with that human input being used as training data, the AI can actually take over some of those tasks. So I think we're in a very exciting time for automation for Selenium and it's not these AI-driven tools versus Selenium or Selenium versus Cypress. And it's like all of these things that we use to solve problems, it doesn't matter which tool you're using. If it solves your problem, then go for it. But then also think about what other problems do you need to solve or now do you have time and space to solve? So I encourage you all to do so and have fun doing it. We had a lot of fun creating those tools and then we went on to create more tools at Ultimate that use AI and machine learning and so on and so forth. So that's my time. Thank you everyone. Feel free to connect on LinkedIn or Twitter or shoot me an email. Yeah, thank you, Tariq. That was a really great presentation.


Let us understand the concept of exiting and traversing nerves. The first nerve that comes out of the spinal cord is the semen nerve which comes out above the lateral process of semen vertebra. So the nerve which comes out from the semen to neural phramen is the C2 nerve. Similarly, the nerve which comes out from the C3 for neural phramen would be the C4 nerve. So if you remember that in cervical spine the exiting nerve which comes out from the phramen is the larger numbered nerve. So the nerve which is coming out from C67 neural phramen will be the C7 nerve. From C7 D1 neural phramen we have an addition nerve which is coming out which is the C8 nerve. So this is the C7 D1 neural phramen. The nerve which is coming out is the C8 nerve. And from D1 to neural phramen onwards the D1 nerve will come out. So in the dorsal and lumbar spine the nerve which is coming out from the neural phramen has got a smaller number. The nerve which is coming out from D1 to neural phramen will be D1. One which is coming out from the D67 phramen will be D6. Similarly, the nerve which is coming out from L45 neural phramen will be L4. So the concept of traversing nerve comes in the dorsal and lumbar spine. The nerve when exits from the spinal cord traverses down to the next level and then comes out from the neural phramen at a lower level. So this is the traversing part of the nerve. This concept comes in the dorsal spine and lumbar spine. So we have got traversing nerve and the exiting nerve in dorsal and lumbar spine. This is not the case in the cervical spine. So when we look at these exclusions, the extrusion which is paracentral cause compression of the traversing nerve in the lateral visus and when it is far lateral it is called compression of the exiting nerve in the neural phramen. So that is difference here. Coming to the anatomical plexus. So this is the color illustration showing the different compressive brachial plexus on the right side. The part here in golden color or yellow color is the roots. So these are the roots of brachial plexus. This is the C5, C6, C7, C8 and D1 roots. We know that the roots are formed by the ventricular dorsal rootlets along the dorsal rootlet there is a dorsal ganglion. So this is the pre-ganglion segment of the root and this is the post-ganglionic segment. The roots in turn join to form the trunks of brachial plexus. The C5 and C6 roots join to form the upper trunk. C7 root continues as the middle trunk and the C8 D1 roots join to form the lower trunk. So the trunks traverse between the anterior posterior scallion muscles. So after the roots we have got trunks. Trunks will be passing between the scallion muscles which are shown here. From the lateral margin of the scallion muscles to the upper margin of the clavicle we have got the divisions. So roots, trunks, divisions, each trunk will divide into anterior and posterior divisions. The divisions will join to form the cords. So the cord travels from the level of clavicle up to the outer margin of the lateral muscles. So these in pink color are the cords. And then the cords will give rise to the middle branches as the side branches which are shown in the magenta color over here. So these are the roots, these are the trunks in blue, these are the divisions intercoils for light blue color. These are the cords in pink color and these are the branches in magenta. This is a detailed anatomy now. The C5 and C6 roots join to form the upper trunk. So these are the scallion muscles. So between the scallion muscles we have got the trunks. C5 and C6 roots join to form the upper trunk. C7 root continues as the middle trunk. C8 and D1 roots join to form the lower trunk. The trunks divide into anterior and posterior divisions. These divisions join to form the cords. Now the posterior divisions of all the three trunks, upper, middle, and lower join to form the posterior cord. The anterior division of the lower trunk continues as the middle cord. And the anterior divisions of the upper and middle trunks join to form the lateral cord. So the cords extend from the level of clavicle up to the outer margin of the petrol muscles. These are named the medial lateral posterior depending on their relation to the subterran artery. So this is subterran artery here. The cord which is medial to it is a medial cord. One which is lateral is a lateral cord. And the cord behind the posterior is a posterior cord. These cords will then give rise to side branches and terminal branches. The other terminal branches show here the medial cord will give rise to a branch which joins with another branch from the lateral cord from the median nerve. The inner nerve comes solely from the medial cord. And the posterior cord divides into two terminal branches, the axillary and the radium nerves. We will not go into this part as of now. Second major is the oblique coronary T1 image which shows the components of brachial plexus. These are the roots of brachial plexus. These are the level of scallion muscles. So we have seen the trunks over here. These are the divisions from the automotive of scallion muscles at the level of clavicle. These are the divisions. The divisions then join to form the cords. This is the asterisk here, shows the subterran artery. So the cord medial cord will be the medial cord. This is lateral cord and posterior cord. So we have got sagittal images, sagittal T1 images here to show the relation of the cord to the subterran artery. So this is the oblique sagittal image here. This is the subterran artery, subterran vein. The cord which is medial to it is the medial cord. The lateral cord is lateral to it and this is the posterior cord. So this is the image obtained somewhat laterally at the level of axilla. So this is the subterran artery. So this is the plenatory. This is the cord which is medial to medial cord. This is the posterior cord and this is the lateral cord. Coming to the indications of brachial plexus imaging. The most common indication as we know are chroma. Then we have put in our comparison of the entrapment syndromes imaging of the inflammatory brachial plexopathy and neoplasms. Most importantly, chroma. From a surgical and prognostic point of view, the injuries to brachial plexus are classified into three categories. Preganglionic, postganglionic and a combination of four. So preganglionic injuries largely comprise of nerve abulsions. These require major procedure like neurotization. Postganglionic lesions are further classified into two lesions in continuity, which will require rehabilitation and neurolysis and lesions with nerve discontinuity, like nerve transaction or severe neurotomysis. These require nerve repair or drafting. The overall spectrum of injuries ranges from neuroplexia or chasing guilt, which is most common, to axonomesis, to partial neurotomesis, with neuroma in temporary formation, to complete nerve lesion of transactions, severe neurotomesis or nerve divergence. These categories here, severe neurotomesis, nerve transaction and nerve divergence will require urgent surgery. Coming to interesting case here, this is a patient who has both injury in vehicle, he has suffered a vehicle accident and he has been injured to the right arm and shoulder. He comes several weeks after the injury with complaints of right upper limb weakness and bristing. So when there is new imaging of patients with brachal plexus, suspected brachal plexus of injury, the first sequence that we take should always be a societal sequence with cervical spine. There is no point in imaging the brachal plexus for half an hour and saying that it is completely normal and then realizing that the patient has got cervical cord injury, something like a cord entusion or intramural hemorrhage which would exclude the complaints. So first and foremost, the first sequence should be a societal T2 sequence through the cervical cord. So this is societal T2 imaging from cervical spine. The cord looks perfectly fine, there is no evidence of confusion or edema or hemorrhages. But when we come slightly far laterally on the right side and see here that there are well-defined cystic lesions in the neural fermion at C67, C71 and D1 to events. So these are the existing nerves which are looking intact. But in this neural fermion, there are cystic areas which could very well be traumatic pseudomeningosemes. So when we take actual section as we just showed earlier, this is the actual 3D space sequence. We can see that the ventral and dorsal rootlets are not seen at this level, C7 and 11. They are seen on the left side. And so there is complete nervous avulsion of the right-sided C1 root here. And there is a formation of a traumatic pseudomeningosem. This is nervous avulsion. So these are 3D sequences, 3D star sequences with deformations. Clearly show the traumatic pseudomeningosemes from here at C67, C71 and D1 to events. So these are involving the roots here. And these meningosemes are then coalescing here to form a large pseudomeningosem sac. And the nerves here are retracted and it matters. So we can actually calculate the distance of retraction of the nerves from the insertion in the core. So the surgeon can have a fair amount of idea about the surgical procedure to be taken. So this is a classical case of right-sided C1 injury with traumatic nerve avulsion and a pseudomeningosem formation. These are 3D voluminated images of the same patient. We can very nicely see the pseudomeningosemes coalescing to form a big sac here. And these are the retracted, pedometer's nerves on the reticulate axis. Another patient, a young adult, again, a vehicle accident and a fracture in mid-part of a clavicle. He had a suspension of reticulate acid injury. But he didn't immediately come up with an accident. He waited for some time. Treating surgeon gave him a few weeks' time. When the patient did not recover after a few weeks, he still had a pulmonary weakness. The patient was sent for an imaging. So these are the images obtained immediately after trauma, which clearly show there is a immediate fracture here involving the mid-part of the right clavicle. These are the voluminated images. There's again a fracture here with some displaced bone pigment here. And when we did MRI scan of the brachial plexus, a few weeks later, this is what we see. Again, the first sequence that we take is a suggested T2 sequence to the cervical cord. The cervical cord here is completely fine. So we move on to the brachial plexus part. These are coronal stir images. Now this, and this level, if you see, this is the area of fracture. So these are the patterns of the bone. This is the callus formation around the fracture side. And these are the nerves of the brachial plexus. Now if you see all the components of brachial plexus, right from the trumps, divisions, cords are all edematous. And I would call this something like neuroplaxia on stretching, but then I would be wrong. If I look carefully at this level, one of the nerves here is showing breach incontinuity. When I do a volume rendering, this is what I see. So I need to evaluate this area better. And when I zoom it, this is what I see. Yes, definitely there's a transaction of nerve. This is the middle trunk of the brachial plexus, which is showing complete loss in continuity. So this is nerve transaction, severe injury involving the middle trunk of the brachial plexus, which would need a surgical repair. So from neuroplaxia, we are moving to nerve transaction. So we can see that this patient has got transaction of the middle trunk of brachial plexus. The rest of the nerves in brachial plexus are showing changes of edema or neuroplaxia. So this is definitely candidate for surgery. Sometimes CT myelography is required. A patient who has got in areas where MR is not available, or patients who have got patients who cannot be urgently taken for MRI. In such cases, CT myelography can be tried. This is a patient, again, with similar findings here. The ventral and dorsal root traits are seen on the left side, on the right side they are not seen. And we are seeing that there's contrast pooling here in a sodium myeloscis sac here. This is the nerve diversion on CT myelography. So this is the reporting format we sometimes follow. It is good to mention the report in two different parts, pre-ganglionic injury and post-ganglionic injury. So this is a patient with nerve diversion at different levels. As we said, we have to mention whether the nerve diversion was pre-ganglionic part. And in the post-ganglionic part, obviously, there will be changes of neuroplaxia and of transaction or exonormous or neurotomysis. Coming to bony impediments. Now this is an interesting case for a young student. He is a medical graduate. And he has got an intermittent brachial plexus involving the left upper limb. The x-ray here clearly shows the cervical ribs. The smaller cervical rib on the right side and larger on the left side. The left side cervical rib here is seen to articulate the mid part of the left front rib. So how does this affect the brachial plexus? Let us see. We have a set of coronal images here, oblique coronal images showing brachial plexus. These are the nerves of brachial plexus. So this would be level of the roots, the trunks and divisions of brachial plexus and this would be level of the cord, because this is the clavicle. We will just go to the next image here. Again, the nerves of brachial plexus, nicely seen. Now this is the left-sided cervical rib. And in this image, you can clearly see that the rib is articulating with the left first rib. And this articulation is very closely operating and impinging on the roots of brachial plexus. So this is the site of the articulation. And these are the level of trunks and cords of brachial plexus. The divisions and cords of brachial plexus. These are getting in pain. So when the patient has got something, abduction extrusion of the left upper limb, the nerves of brachial plexus are impinged by the cervical rib. So this patient was subjected to surgery. The cervical rib was removed and he did have improvement in the complex. Another patient presented with upper extremity pain, but he also had on further proving, he gained his clear of weight loss and a lot of peptides since few months. The media clearly shows the well-defined mass of the optical part of the left hemiphox.  And on the next media, it clearly shows that there is an invasion of the even root of the brachial plexus and maybe the lower trunk. So this is the classical case of pancostume of left limb, which is embedded in the brachial plexus. Another patient, adult female patient, is treated for sea breast. She has got nodule legions along the nerves of brachial plexus, which are classical of metastasis involving the brachial plexus. Another young adult female patient with right upper limb complaints, the image itself is very characteristic. We have got a dumbbell check region, which is coming out from the neural ferment with well-defined margins. This is where most likely a non-ship tumor involving the brachial plexus. A 38-year-old male patient who had his vehicle accident a few months back, now he has up to a few months, he has come with contents of right brachial plexopathy. This image clearly shows a well-defined region of brachial plexus with two differential intensities, the central part here. This impact is a supra-analysm involving the suplean artery, which is causing right-sided brachial plexopathy. Another elderly female patient who has received radiotherapy for sea breast seven months back presents with brachial plexopathy. Now, in this case, there are no nodules along the nerves, so we don't see any obvious metastasis, but there is increased intensity of the cause of brachial plexus here. And these might show increased enhancement. So, this is an all-likely root. Since the patient has got C.L.F. breast, she has received radiotherapy. So, this is post-brachial plexopathy of the brachial plexus. Now, she has got similar findings. As the earlier patient, there is extensive edema and hyperintensity involving the root, stumps and pores of brachial plexus. But she didn't have any previous history. She had a small episode of viral illness one or two weeks back. So, in all likelihood, this could be something like arsenish term as syndrome, inflammatory brachial plexopathy. So, we're finding, we've mentioned about some of the emerging MRI techniques that we can use for brachial prasimaging, DTI, or Diffusion Tense Imaging, which measures diffusion of water in 3D space or in milliseconds of time, and to give indication of tissue alteration, it has got high sensitivity for detecting changes in tissue anastropy. So, this is very similar to DTI that we take to ascertain the integrity of the longitudinal white matter cracks in brain. And this is still an immediate technique. This brings me to the end of the presentation. I hope you enjoyed this presentation and found it informative. Thank you.