Results reporting is one of the key stages in the testing phase where the interested project participants or the stakeholders are presented with information on the test progress. Although many of the test automation tools have inbuilt reporting capability, the information may either be too low-level or technical, or it may not be fully relevant for management. As part of test process improvement, I’m working on a requirement to present the test results in an efficient way, so the management can visualise the current status of testing or the overall status for a test cycle, and make decisions accordingly.
Having worked with some of the popular EAI tools like TIBCO BW, Vitria Businessware and SAP PI, it’s time for me now to familiarize myself with something from the IBM product catalogue as well. IIB – IBM Integration Bus. It is the next product offering from IBM in the ESB range; an extension to Websphere Message Broker and Websphere ESB. Going forward, users of Websphere ESB and Message Broker, would have to migrate to IIB. So, here’s few of my initial thoughts when working with IIB.
Across all application teams, but particularly those who are trying to embrace DevOps principles, dashboard technology has an important role to play. Dashboards are key enablers for collaboration within and across teams, and they are excellent at driving the application team in the right direction. They can be the boost that your team needs to get to the next level in your DevOps journey.
Service virtualization is becoming a must-have technology enablement in the IT transformation programmes of many enterprises. However, service virtualization alone will not yield the desired ROI or measurable benefits unless the investment is extended to support the right level of testing and, especially, test automation.
DevOps: Let the team use virtual services instead of production services, and test the application right away. I am sure you might have heard this “virtual service” term in recent times if you are keeping up with the latest trends in the market. Now what is this virtual service and how is it that important for DevOps?
A key part of your DevOps programme, and instrumental in its success, is how DevOps and your applications are measured. If this measurement is done well, it will provide accurate ROI, help you to manage progress towards your DevOps goals, and be a great help in evangelising DevOps success.
Once the big decision has been made to go for DevOps in your organization (or at least give it a go), what do you do next? Below are my suggestions for things which should be considered at this early stage if you want to get started with a successful DevOps programme.
Following on from my previous post entitled 7 Steps to Start your DevOps Initiative, I thought I’d talk a bit about DevOps in the long term. Something which can easily be missed when on the DevOps journey is how to keep the momentum and make sure that good DevOps principles are not lost after the initial driving phase.
Being in software testing for many years now, I feel that one thing that has never changed is IT managers always being in a position to justify the investment of test automation or any technical enablers to improve the testing function within their organisation. I think this is mainly due to difficulty in proving the ROI for testing.