Director-Quality, Huawei Technologies India Private Limited
Member since 5 years
Specialises In (based on submitted proposals)
Anish Cheriyan is Director in Huawei Technologies India Private Limited. His key responsibilities include Quality Assurance, Cyber Security and driving key initiatives in Agile and Lean with respect to software engineering in Huawei India.
He has led Agile Transformation Task Forces at organization level. He has worked with teams as Agile coach in the Telecom Network Management, Application Development and Core Network domain. Anish has worked with teams for lean kanban, continuous integration and delivery adoption and further deployment.
Quality Assurance in DevOps and SecOps WorldAnish CheriyanDirector-Quality, Huawei Technologies India Private LimitedHuawei Technologies
schedule 4 years agoSold Out!
I would like to give talk on How the Quality Assurance and Testing is different in DevOps and SecOps World.
Following is the flow of the talk:
- Continuous Delivery and Continuous Testing
- DevOps and SecOps
- Literature Review - A brief about some of the best practices
- System Thinking and How to build Quality and Security into the system
- Architecting for Continuous Delivery
- Build Pipeline and how to make it effective
- Static and Dynamic analysis and inputs to the testing
- Running Security in the Build Pipeline
- Bringing the Operations perspective up in the life cycle
- Continuous Deployment and Monitoring
- Upcoming /Happening Trends (Microservices, Containerization and others)
- Summary and Way forward
From Chaos to Clarity- Sustainable Test Practices for Continuous DeliveryAnish CheriyanDirector-Quality, Huawei Technologies India Private LimitedHuawei TechnologiesRajith RaveendranathVPSunTec
schedule 4 years agoSold Out!
In Agile Teams, Testing acts as a safety net and helps doing any kind of development and change seamlessly. The confidence when the Continuous delivery system give a Pass signal comes from the quality of the test . Test code lives as long as the code lives.
But strangely, though enough buzz and importance is there on the continuous delivery, deployment and devops practices but some teams don't give equal priority to the deeper testing practices.
In this presentation Anish along with Rajith will explore the anti patterns of Agile Testing and provide overview about the Onion Layered Test Practice Map (Task, Story, Sprint, Release Level). Without good test practice and quality test, continuous delivery may only give false confidence.
3 reasons some teams may take years for a good Continuous delivery system and how to overcomeAnish CheriyanDirector-Quality, Huawei Technologies India Private LimitedHuawei TechnologiesGowrishankarDirectorOracle
schedule 5 years agoSold Out!
In this presentation, I would like to present the anti patterns of continuous delivery implementation in teams. This patterns
emerges time and again in various forms in various teams. These anti patterns may become bottlenecks to realize the goal of
a good system and having a strong continuous delivery system may just remain a dream. I would also provide some key solutions about how to overcome this in a systematic way.
I would cover the anti patterns related to Core System Engineering - Requirement Analysis, System amd Continuous Delivery Architecture , Deployment pipeline. I would bring out some of the deeper anti patterns of Test- like Ice Cream cone shaped test pyramid, Test Suite organization linked to Deployment pipeline and Test Automation architecture issues. Further, I would highlight the anti patterns related to Core Competency and other key Project Management aspects.
Following and some other anti patterns, I would like to cover in this presentation with specific examples and solutions :
1. Core System Engineering
Anti Pattern 1: Requirement analysis of the production environment and the other key details missed during requirement analysis or requirement documentation time. Realization of this happens late in the development cycle.
Anti Pattern 2: Build System (Continuous Delivery) Architecture and the Deployment Pipeline paid less attention
2. Code, Inspection and Test
Anti Pattern 3: Test Automation Architecture NOT taking all factors into account while designing
Anti Pattern 4: Ice Cream cone shaped test pyramid and the Test Suite Organization issues affecting the deployment pipeline.
3. Project Management
Anti Pattern 5: Competency, Team Culture and other project management issues
Anti Pattern 6: Done, Done but not Done :-(
I would provide examples of these pattern of occurences and provide pointers to some of the solution for these.
Some key solutions are:
• Requirement Elicitation and Analysis: Requirement Elicitation and analysis should cover the details about the production environment and other information when there is closer interaction between the customer and business analyst / any other member. We will cover solution about how this input helps in the Continuous delivery implementation in systematic way. For the benefit of the audience we will provide a small checklist which can help the business analyst during the requirement elicitation time.
• CI Architecture and Deployment Pipeline: We will cover the solution about how team should look into the system architecture, dependency between the various components, based on which the CI architecture should be decided. CI Architecture may vary based on the type of system. Here we will cover some examples from network domain and an industry web application system of how the architecture is different when a system is delivered with various products packaged as a solution versus a web application system. Further we will cover the details of how the deployment pipeline should be built. We will cover the various factors for this like :
o Test Strategy
o Selection of the right test suite /test cases for faster feedback
o Test Suite Organization
o Tool Infrastructure including inspection tools
System Architecture should cover the details about the CI Architecture and deployment pipeline rather than CI Architecture being looked as a separate activity. Here we will provide solution about how the packaging requirements will help in deciding this. Also we will cover how the various views of system architecture should cover this perspective.
• Test Automation Architecture- We will cover the solution related to how the test automation architecture should be designed. Test automation architecture is very important to ensure that the continuous delivery pipeline is built appropriately. Many times we find problems like slow running test cases, UI test cases taking long time, some scenarios cannot be automated etc. Will cover the aspects like:
o System under Test Architecture ( Architecture type ,Components, dependency etc.)
o System Under Test Programme Inputs
o System Under Test Program State
o Environmental Characteristics (Automation Tool, OS, DB, JDK, AS etc)
o Key Monitoring Tools
• Test Suite Organization and Ice Cream cone shaped test pyramid: Will cover the solution about how Unit Test, Functional Test, Non Functional Test (Performance, Reliability, Security) should be organized at each feature level. Many teams go wrong here due to which later during the continuous delivery implementation this becomes a pain area to refactor and organize it rightly. There is no silver bullet solution for improving the Test Pyramid. Teams have to think hard about this and make it happen. We will cover details about how this should be addressed in the test strategy and taken up further.
• Project Management: Done Criteria for each of the task will explained in detail. We will cover the solution about how to get the real benefits from continuous delivery rather than just making the deployment pipeline faster. Will cover solution about how to avoid situations where the pipeline is faster but still we have less confidence and require many days of manual testing. In this section we will cover the solution to some other aspects like Culture building, Competency, Self Organization and other related topics.
Conclusion- Until team realizes these anti patterns upfront, it is nearly impossible to have a strong continuous delivery system. Symptoms may be different in different teams but the pattern of issues may be same. Human energy is too costly to do the same mistake again and again. Lets avoid it.
No more submissions exist.
No more submissions exist.