OpsDev – more dev work by ops

The hyped mnemonic “DevOps” is equally true the other way around: OpsDev – that is, more and more work in the operations and infrastructure departments happens as development activities with scripts, code repositories and build managers. OpsDev is as tool-heavy as DevOps, and test involvement similarly pipeline focussed.

Guest blog post at http://www.plutora.com/blog/opsdev-test-environments-management 


Shift-Right, you wild one!

The Shift-Right label is that more and more testing (and checking) can happen on the live application in production. Some call it monitoring, some call it Testing in the Wild. It is a very wild idea for some people and some contexts #YMMV. It may very well be the best way of testing in some contexts.

Once I consulted on a network stabilization and delivery optimization project for a consumer bank. They had many issues in their production environment… I strongly advocated that they did test controlled and structured in production on the network changes and other operational activities. (I have talked about “How to Test in IT operations“ at Nordic Testing Days 2016). More on testing during IT deliveries in Shift-Deliver.

Shift-Right is trend that people have covered well before me, here are some pointers:

The key is really as Alan puts it “testers should try to learn more from the product in use” and with that comes the tools of Google Canary builds, NetFlix Chaos Monkeys etc.


This trend goes along with Shift-Coach, Shift-Left and Shift-Deliver discussed separately. Initially I considered shift-right to be regarding consulting, but after hearing Declan O’Riordan at DSTB 2016 I realized that shift-right was the right label for test in production, testing in the wild etc.

Similar posts regarding things in the wild: Bugs HappensThe Kcal bugTradition is a choice and Can you see beyond the visible.

Testing decommissioning of ICBMs and software

[ SoftwareTestingClub | October 24, 2011 | Jesper Ottosen ]

Recently I had the great opportunity to visit the only museum in the world for the ICBM’s of the Cold War – http://www.rvsn.com.ua/en/. The museum have some ICBM vehicles, some remaining bunker tops – and the command bunker. I actually sat in the seat 10 stories below ground, that was manned 24x7x365 during the cold war! The decommissioning of the ICBM’s was a HUGE project (on more ways). I came to consider the testing and checking required in that program… how can we test for something that is gone?

Decommissioning, closing, retiring and sun setting applications have somewhat the same challenge. Albeit the mission usually is less …worldwide significant. The mission behind an application retirement project could be huge cost savings as there is a high prize on application maintenance – database and OS licenses etc. Other mission scenarios could be IT strategic initiatives to rearrange existing enterprise applications for an updated business fit. The retirement initiative could also be a side effect of moving applications to Software as a Service Platforms.

The simplest approach to application retirement is to stop it, and see if anybody notices. Alas – this might turn off something vital. It is important to do a retirement analysis and making some of the unknown known. The actions involved in a more controlled application retirement analysis could be:

  • Identifying known interfaces to the application
  • Identifying known interfaces from the application
  • Identifying data that needs to be migrated elsewhere
  • Identifying a close down, ramp down and retention periods
  • Identifying documents, manual processes, SLA’s, customer and vendor contracts

As in all testing projects it is worth discussing the test strategy with the project team (sponsor included) up front. Discuss the worst-case scenarios are and have a risk analysis and evaluation based on those. Discuss “Is there a problem if” scenarios. This will help to guide the retirement road map and testing activities moving forward. As in all testing and analysis work, you will not be able to turn every stone and pledge every deadly mistletoe.

From a business perspective the removal of the application from the underpinning contracts might be the one that enables the business case of whole project, and will be the worst-case for the project, should the cost reductions be missed. Don’t disregard the testing of removing the application from the contracts and SLA’s. Test and check all the identified documents and consider all manual business process that utilizes the application being removed. How are the business processes being affected by the application change?

The retirement road map may also addresses application “retention” time, a time frame where the application is “on hold” being monitored for something unexpected to pop up. There might be an unknown yearly batch job around the fiscal year. There might be regulatory requirements for the data to be read-only for a number of years.

Some good-old software testing & checking, will be possible considering the updated application portfolio:

  • The updated applications are not doing something it should be doing
  • The updated applications are doing something it shouldn’t be doing
  • The updated applications are doing something it should be doing but it feels or looks wrong

[from http://cartoontester.blogspot.com/2010/06/3-types-of-bugs.html]

In the end an application retirement project is a much about making a planned change, at “build” projects are. Some of it is just the other way around – but the key mission of testers & checkers is to provide decision input for a successful outcome.