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
I’m presenting at UKSTAR 2018 on the Topic: Experiences in Testing Infrastructure Projects. The content is a continuation of my materials and talks about testing outside the SDLC, in this context operations and infrastructure. It’s additional problems and examples compared to “How to test in IT Operations” at Nordic Testing Days 2016.
Relevant blog posts, but not talk content:
The talk is in the same field as this talk – by Mike Talks @testsheepnz although with no applications on top… and other stories 😉
[ 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.
Complexity is a Matter of Perspective 