Director-Quality, Huawei Technologies India Private Limited
Member since 6 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.
Penetration Test Engineering - A Systematic ApproachSriharsha NarayanamManagerHuaweiAnish CheriyanDirector-Quality, Huawei Technologies India Private LimitedHuawei Technologies
schedule 4 years agoSold Out!
Penetration Testing is an important activity and ability to do the penetration testing effectively should not be limited to few senior security professional in an organization.
In our presentation , we will bring the systematic Engineering approach to Penetration Testing , such that it is not left for a chance.
We will touch upon the Security Principles and Threat modeling which are foundation for a secure product
Also we will present a success case of the application of this Engineering practice in our organization
High level topics list that will be discussed are as below.
Principles of Security for Secure Products
Security in Product Development Life Cycle
Penetration Test Engineering analysis
Cyber Security- a mindset and some anti-patterns
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
DevOps - The Opening GameRajith RaveendranathVPSunTecAnish CheriyanDirector-Quality, Huawei Technologies India Private LimitedHuawei Technologies
schedule 5 years agoSold Out!
The setting up phase of DevOps is like the Opening Game in Chess. A good opening can give us advantage for the remaining games. As in chess, there are "book moves" in the Opening Game of DevOps that may be played to our advantage.
Based on my experience in setting up DevOps in an overseas eCommerce platform project with world wide deployment, I will be sharing these book moves as aphorisms in each of the three stages of the build pipeline.
Some of these good practices will be demonstrated in GitHub using some open source projects and the CI tools used in Git Hub.
In the concluding part, we will look at some conventional traps which may hindering the devops in your project context to deliver on its promise and consider some alternatives which we have discussed in the earlier part of the session.
From Chaos to Clarity- Sustainable Test Practices for Continuous DeliveryAnish CheriyanDirector-Quality, Huawei Technologies India Private LimitedHuawei TechnologiesRajith RaveendranathVPSunTec
schedule 5 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 TechnologiesGowrishankar KrishnanDirectorOracle
schedule 6 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.