recentpopularlog in


« earlier   
Kitchen Soap – MTTR is more important than MTBF (for most types of F)
MTTR > MTBF. MTTR is more important than MTBF (for most types of F). Being able to recover quickly from failure is more important than having failures less often. What I'm definitely not saying is that failure should be an acceptable condition. I'm positing that since failure will happen, it's just as important (or in some cases more important) to spend time and energy on your response to failure than trying to prevent it. I agree with Hammond, when he said: If you think you can prevent failure, then you aren't developing your ability to respond.
operations  devops  testing  development  rto  recoverytimeobjective 
49 minutes ago by dlkinney
Draw an AST diagram of any file, on the command line, using Google Closure Compiler.
JavaScript  testing  from twitter
1 hour ago by noahsussman
Testing and monitoring in production - your QA is incomplete without it : Assertible
We all agree that bugs in production are inevitable. But that doesn't mean fixing them is free; bugs that make it all the way to end-users are generally the most expensive to fix. This is where building to recover comes into play. With faster release cycles, testing goals move away from trying to completely erradicate failures up-front and towards building recoverable systems that will identify and alert us of issues as quickly as possible. This means sturdy monitoring and automated tests for production APIs. John Allspaw has a great blog post on developing your ability to respond. The take is that reaction is more important than prevention. I completely agree with this, and particulary his acronymic description of the technique: "MTTR > MTBF, for most types of F" (
testing  operations  observability  devops  deployment  continuousdeployment 
1 hour ago by dlkinney
Testing in Production, the safe way - Cindy Sridharan - Medium
The goal of testing in production isn’t to completely eliminate all manner of system failures. To quote John Allspaw: "While any increase in confidence in the system’s resiliency is positive, it’s still just that: an increase, not a completion of perfect confidence. Any complex system can (and will) fail in surprising ways." Testing in production might seem pretty daunting at first, way above the pay grade of most engineering organizations. While it’s not easy or entirely risk-free, undertaken meticulously, it can greatly help build confidence in the reliability of the sort of complex distributed systems that are becoming increasingly more ubiquitous in this day and age.
deployment  testing  development  production  devops  sre  qa 
1 hour ago by dlkinney
Google Testing Blog: Just Say No to More End-to-End Tests
As a good first guess, Google often suggests a 70/20/10 split: 70% unit tests, 20% integration tests, and 10% end-to-end tests. The exact mix will be different for each team, but in general, it should retain that pyramid shape. Try to avoid these anti-patterns.
development  testing  qa  software  unittests  integration  e2e  google 
1 hour ago by dlkinney
Have you ever wished you could create a simple monitoring service to help with your routine?

Here's a ser…
testing  from twitter
1 hour ago by noahsussman
Exploratory is more or less the practice of continually asking what is different and then why is it differ…
Testing  from twitter
16 hours ago by noahsussman

Copy this bookmark:

to read