Skip to main content

Posts

Showing posts with the label DevOps Test Engineer

Who needs to be informed and knowledgeable about DevOps Test Engineering?

Testing starts with the first line of code!   It is NOT a downstream activity. DevOps testing has a critical role to play in a Continuous Delivery Pipeline. Without integrated testing DevOps simply will not work!   With the advent of DevOps and the movement to breakdown silos between developers, QA, security, and operations, it becomes critically important that all members of an IT team - regardless of what tools they use, or role they play - understand the essentials of testing. Every member of your development team should also integrate to ensure Compliance and Audit outcomes!   It is a new world.   In this new world, we can leverage from existing but must be open to walking through new doors of opportunity. Understanding traditional test strategies is helpful but when and where, and most importantly how we proceed with our test strategy must shift.   Knowing how to code is not enough, Quality Assurance in and of itself is not enough.   We cannot afford to have our products

DevSecOps - Identity and Access Management

Testing starts with the first line of code!   It is NOT a downstream activity. DevOps testing has a critical role to play in a Continuous Delivery Pipeline. Without integrated testing DevOps simply will not work!   With the advent of DevOps and the movement to breakdown silos between developers, QA, security, and operations, it becomes critically important that all members of an IT team - regardless of what tools they use, or role they play - understand the essentials of testing. Every member of your development team should also integrate to ensure Compliance and Audit outcomes!   It is a new world.   In this new world we can leverage from existing but must be open to walking through new doors of opportunity. Understanding traditional test strategies is helpful but when and where, and most importantly how we proceed with our test strategy must shift.   Knowing how to code is not enough, Quality Assurance in and of itself is not enough.   We cannot afford to have our product

Site Reliability Engineer – Explosion

The Practice Site Reliability Engineering (SRE) is a discipline that incorporates aspects of software engineering and applies that to operations with the goal of creating ultra-scalable and highly reliable software systems. It is an Explosion!  If you have taken any classes including ITIL4, DevOps, Agile, or Lean , you have probably heard how critical Site Reliability Engineering (SRE) is to the Value Streams and Pipelines that deliver products and services to this world. New concepts like understanding “Error Budgets” and the creation of anti-fragile environments are explored. You only need to visit one of the job sites and do a search on “Site Reliability Engineering” to see that there is a huge uplift in demand for Site Reliability Engineers. Try it! T he Role As a Site Reliability Engineer, you'll build solutions to enhance availability, performance, and stability for the resilience of services. You will also work towards a Continuous Delivery Pipeline by automati

10 Types of People Who Need to Understand DevOps

If your organization hasn’t adopted DevOps approaches yet, it probably will soon. In the InteropITX 2018 State of DevOps Report , only 9 percent of the business technology decision-makers surveyed said that their organizations had no DevOps plans. A third said their organizations had already adopted DevOps principles and another 46 percent had plans to do so within the next two years. As DevOps spreads, many IT leaders have questions about which types of employees should get basic training on the fundamentals of the approach. We recommend that at least the following ten types of people get a foundational education about DevOps: 1. Developers In many organizations, DevOps begins with the application development team adopting Agile methodologies. DevOps begins to spread as those in the operations team start to follow some of the same principles. 2. IT operations professionals DevOps is all about closer integration between development and operations, so it stands to r

Orchestration vs. Automation

It is important to understand the difference between orchestration and automation for any DevOps continuous delivery pipeline initiative. We orchestrate processes and we automate the activities within the process. In a recent DevOps Test Engineer (DTE) certification class I learned how to deconstruct the DevOps pipeline. Understanding the constructs of the pipeline and what your test strategies are will prove helpful for both the orchestration and automation of your delivery pipeline. Benefits of that knowledge generate better alignment and cadence with the business demand and greater deployment velocity. Orchestration and automation take advantage of standardization throughout the DevOps pipeline for integrated tools, integrated code, integrated build and integrated test all the way through. The results? Not only can we deliver product faster but that product or service is now delivered into an anti-fragile, secure and stable environment.  Confirmation that the process is repeat

DevOps Testing vs Traditional Testing

Appropriate testing is THE differentiator for high performing IT organizations. What is the Same? Tests need to be classified according to the attributes of the system or the product that is to be tested.  Test types include: Unit Test - This is a method that validates that the code statements satisfy assertions. Static Code Analysis – Testing that checks source code logic and consistency.  Static testing evaluates code against development standards and guidelines. Code execution is not required. Dynamic Analysis – This type of testing might also be referred to as “Functional Testing”. In this type of test, code is executed against positive and negative functional scenarios. Code Coverage – Measures the percentage of relevant lines of code tested. Integration Test – This form of testing will help to determine if code changes work after a code merge.   Integration testing may also be referred to as smoke test, sanity test or build test. Compatibility T

DevOps Test Monitoring Strategy

The combination of continuous monitoring with continuous testing and analytic tools can provide a broader strategic view of test results.  This view is necessary to collect, aggregate and organize test data that enables a gain in confidence for each release.  Key Concepts for Realizing Your Test Monitoring Strategy: Determine continuous test monitoring priorities: Some examples of problems that continuous test monitoring can help with include intermittent failures caused by marginal designs, marginal test designs, environmental condition changes not detected by individual tests, memory leaks, varying starting conditions, interactions with other systems, system topologies and performance degradation within the margin of a test. These can and will accumulate over time. The best practice for continuous monitoring indicates that the problems of most concern to a specific product or DevOps environment will be monitored. Regression test product areas even though there were no expe

Measuring Goals for DevOps Test Succcess

Each organization will have to define what their quality goals are for integrated testing based on the business and customer requirements for speed and outcomes.  The fact is that these goals must be quantified or in other words measurable. If you are not measuring your testing activities in alignment with the strategic goals then success becomes subjective and it will be very difficult to show value for your effort. Some examples of measurements might be in the form of Run-To-Plan and Pass-To-Plan. Run-To-Plan (RTP) is the number of the total planned tests that have completed and typical goals are to have 95% RTP Pass-TopPlan is the number of tests that have passed and a typical goal for this metric is to have a 90% PTP The criteria for determining when testing is complete is agreed by all stakeholders.   It will be impossible to have all stakeholders on the sprint team, but certainly input and validation from key stakeholders will have to be included before acceptanc