Page object model is a design pattern used in test automation where test script and locators are defined in separate classes. In this design pattern each web page( screen in case of mobile application) is represented as a class and each element on the page is represented as an object. All the locators of the web page and actions on those locators are defined on the corresponding page created in the test automation.Advantages of POM: Maintainability: Modification in the UI pages often happens and so there are chances that test cases may fail due to locator change. So it’s easy to update the locator at one place and thus fixing the test cases failing due to locator change Reusability : Having locators at one place, It becomes easy to reuse throughout the test framework wherever it’s required. We need not define it in each test class. Readability: With the locator defined in other class using POM, it gives clear and readable code at the test layer making it more clean

Grey box testing is a combination of black box and white box testing which involves partial knowledge of coding structure. Grey box testing is best suited for integration testing, security testing, session management, API testing etc. Unlike Black box testing which focuses on top layer or white box testing which focuses on coding layer, here we mainly focus on all layers of the software or in other terms business logic is considered for Grey box testing.Few examples:API TestingIf we want to test Role based software like access for Admin user and Normal user. Apart from doing black box testing, We need to know the APIs being called for each kind of user. Authorising a Normal user and trying to hit the API for an admin user should result in 401 (Unauthorised) or 403(Forbidden). Session Management:For every login we have a session maintained for a particular duration. As part of black box we do logout and check if the user is logged out. As part of Grey box testing, if we know where the session details are stored at client or server end then we can play around with those ensuring that it works properly

Chaos engineering is about purposely setting the system to fail in order to test how our system behaves. Consider following scenario:  Network is interrupted/gone while a video call is going on.  Another one, what if user is redirected to 3rd party for payment after he purchases but the payment server is not responding What if user tries to upgrade our app but he don’t have sufficient space on his handset What if user tries to register but due to high volume registration is not able to complete or dies in between For these kinds of scenarios which may not occur on a day-to-day basis but can happen once a while for a few sets of users, we need to ensure that our system behaves well. For above cases, how to test these: This scenario can be tested by switching off wi-fi or data plan while a video call is on to see how the system behaves. Or can go to the area which is out of reach of wi-fi This scenario can be tested by disconnecting the API call which is responsible for redirecting to 3rd party This definitely involves consuming the handset’s space first and then try to upgrade  This scenario can be tested by purposely killing the query from backend to test it These are few examples which may not happen for all the users but need to be tested to ensure nothing is breaking.  

Test Bash event organised by MoT is amazing and the biggest event I attended so far. It provides the platform to meet like-minded people, and the opportunity to meet QA professionals, software testers and Quality coaches coming from various places around the world. The 2 days of test bash program is full of Great speakers talking about topics full of rich content which gives exposure about the latest testing trends. The sessions are interactive and quite engaging which keeps the space full of energy. Apart from this, various workshops including practical hands-on and fun filled activities arranged there keep the momentum high. It is the best event where we get a chance to learn together, connect to each other and grow our network. 

Shift-left testing is a approach in which testing activities are started during early phases of software development life cycle. Unlike traditional approach where testing phase used to be last phase of SDLC, Shift-left testing activities are performed alongside during design and development phases to help reduce costly bugs caught at later stages.Advantages of Shift-left testing :1. Involving testing team during the design phase - they can provide their valuable feedback based on their domain knowledge, experience and existing or legacy system by testing the requirement. As a result, any issues found can be fixed at this stage rather than finding them in later stages2. Invovling testing team during development phase - test document, test cases created and shared with developers help them to develop the software for those test cases which developer might have missed to implement. Unit and Integration testing can be well shaped and implemented at this stage3. Post development(Traditional Testing Phase) - By this time most of the testing is done. Feedback is shared at each stage and is implemented. Testing team get a refined version of software where they need not to be trapped in small bugs. They are already fixed. More focus and concentration is on how user is going to use the software and at this stage testers can penetrate and deep dive to ensure no major issues are there.