Stas Zvinyatskovsky

[classicprogrammerpaintings]

Édouard Manet from 1867 to 1869

“Maximilian sends his OSS pull request for code review” - fragment

[staszv-blog]

Don’t Test Your Software

As I started my first job, the company was approaching the end of its 9 month release cycle. Two days into my employment the entire company got together and the head of QA proclaimed: “We have put the product through rigorous testing, we have hit it from all angles for three weeks, we feel good about its quality, we are ready to sign off”. This was met with loud cheers - the product was ready to be released.

This statement - “we have put the product through rigorous testing, we feel good about its quality” - captures the approach to software testing that is prevalent in our industry. How many tests does it take for you to feel good about the quality of your software? How much time?

I don’t want to feel good about the quality of my software. I must know.

I work with teams whose release cycles are measured in hours or even minutes. On such teams, knowing with high confidence that product is ready to be released is essential. Testing, as we know it, doesn’t provide that. It is probabilistic at best. A deterministic approach to software certification is required.

Assertive Product Certification is an approach to software certification that allows teams to deterministically reach conclusions about readiness of their product for production release. This approach has been utilized by hundreds of teams in fully automated releases environments across the technology spectrum. Many of these teams operate some of the world’s largest software systems.

At a high level, the approach is straightforward: all expected behaviors of the product must be explicitly declared, then asserted every time the product is modified.

I wrote an article that goes into the details of Assertive Product Certification. The article covers the definition of the approach as well commons questions and situations. I finish with an example workflow of a team utilizing the techniques described in the article.

I am very much interested to hear your feedback. Please comment directly in the document or write to me via LinkedIn, Twitter, or Tumblr.

The full article is available here.

picture: (cc) Paolo Camera @flickr

[staszv-blog]

Deliver!

tl;dr

We are writing a book on Continuous Delivery and want to interview potential readers. If interested, ping me.

Photo: (cc) ceekay@flickr

I am a software architect at Yahoo. I lead Technical Excellence initiative for the company.

James Couball and I are writing a book on Continuous Delivery. We are looking to interview potential readers. 

We have a simple definition for Continuous Delivery: “Continuous Delivery = commit to production without human intervention”. 

Over the past couple of years we worked on implementing this pure form of Continuous Delivery across Yahoo. We successfully implemented Continuous Delivery across hundreds of teams and thousands of software components that serve billions of requests per day. We dealt with all kinds of technologies - from Windows to Linux to iOS, from Ruby to Java to JavaScript, from Hadoop to Oracle to Redis. 

We learned a lot in the process. By publishing this book we want to share our knowledge with the world. 

  If you are at all interested in this subject and could see yourself benefiting from our experience, please get in touch, we would like to talk to you to understand which topics you are interested in. 

Reach out to me directly with Tumblr, Twitter, or LinkedIn.

Thank you!

(and please reblog)