Innovation Case Study: Test Automation & Ambit Enterprise Upgrade

A business case of how technology innovation successfully integrated into the business operations an improved the way of working that supported business success.

  
Areas of Science and TechnologyData Engineering, Computer Science
R&D Start DateDec 2018
R&D End DateSeptember 2019
Competent ProfessionalRenier Botha

 

Overview and Available Baseline Technologies

Within the scope of the project, the competent professionals sought to develop a regression testing framework aimed at testing the work carried out to upgrade the Ambit application[1] from a client service solution to a software as a service solution (SaaS) operating in the Cloud. The test framework developed is now used to define and support any testing initiatives across the Bank. The team also sought to automate the process, however this failed due to lack of existing infrastructure in the Bank. 

Initial attempts to achieve this by way of third-party solution providers, such as Qualitest, were unsuccessful, as these providers were unable to develop a framework or methodology which could be documented and reused across different projects. For this the team sought to develop the framework from the ground up. The project was successfully completed in September 2019. 

Technological Advances

The upgrade would enable access to the system via the internet, meaning users would no longer need a Cisco connection onto the specific servers to engage with the application. The upgrade would also enable the system to be accessed from devices other than a PC or laptop. Business Finance at Shawbrook is comprised of 14 different business units, with each unit having a different product which is captured and processed through Ambit. All the existing functionality, and business specific configuration needed to be transferred into the new Enterprise platform, as well as the migration of all the associated data. The competent professionals at Shawbrook sought to appreciably improve the current application through the following technological advances:

  • Development of an Automated Test Framework which could be used across different projects

Comprehensive, well executed testing is essential for mitigating risks to deployment. Shawbrook did not have a documented, standardised, and proven methodology that could be adopted by different projects to ensure that proper testing practises are incorporated into project delivery. There was a requirement to develop a test framework to plan, manage, govern and support testing across the agreed phases, using tools and practices that help mitigate risks in a cost-effective and commensurate way.

The test team sought to develop a continuous delivery framework, which could be used across all units within Business Finance. The Ambit Enterprise Upgrade was the first project at Shawbrook to adopt this framework, which lead to the development of a regression test pack and the subsequent successful delivery of the Ambit upgrade. The Ambit Enterprise project was the first project within the Bank which was delivered with no issues raised post release.

The development of a regression test pack which would enable automated testing of future changes or upgrades to the Ambit platform

Regression testing is a fundamental part of the software development lifecycle. With the increased popularity of the Agile development methodology, regression testing has taken on added importance. The team at Shawbrook sought to adopt an iterative, Agile approach to software development. 

A manual regression test pack was developed which could be used for future testing without the need for the involvement of business users. This was delivered over three test cycles with the team using the results of each cycle (bugs identified and resolved) to issue new releases. 

173 user paths were captured in the regression test pack, across 14 different divisions within Business Finance. 251 issues were found during testing, with some being within the Ambit application. Identifying and resolving these issues resulted in the advancement of Ambit Enterprise platform itself. This regression test pack can now be used for future changes to the Ambit Enterprise application, as well as future FIS[2] releases, change requests and enhancements, without being dependent on the business users to undertake UAT. The competent professionals at Shawbrook are currently using the regression test pack to test the integration functionality of the Ambit Enterprise platform.

  • Development of a costing tool to generate cost estimates for cloud test environment requirements

In order to resolve issues, solutions need to be tested within test environments. A lack of supply was identified within Shawbrook and there was an initiative to increase supply using the Azure cloud environment. The objective was to increase the capability within Business Finance to manage an Azure flexible hosting environment where necessary test environments could be set up on demand. There was also a requirement to plan and justify the expense of test environment management. The competent professionals sought to develop a costing tool, based on the Azure costing model, which could be used by project managers within Business Application Support (“BAS”) to quickly generate what the environment cost would be on a per day or per hour running basis. Costs were calculated based on the environment specification required and number of running hours required. Environment specification was classified as either “high”, “medium” or “low”. For example, the test environment specification required for a web server is low, an application server is medium while a database server is high. Shawbrook gained knowledge and increase its capability of the use of the Azure cloud environment and as a result are actively using the platform to undertake cloud-based testing.

The above constitutes an advance in knowledge and capability in the field of Data Engineering and Computer Science, as per sections 9 a) and c) of the BEIS Guidelines.

Technological Uncertainties and activities carried out to address them

The following technological uncertainties were encountered while developing the Ambit Enterprise upgrade, mainly pertaining to system uncertainty:

  • Implementation of the new Ambit Enterprise application could disrupt existing business processes

The biggest risks for the programme of change, was the potential disruption of existing business processes due to the implementation of the change without validation of the upgraded application against the existing functionality. This was the primary focus of the risk mitigation process for the project. Following the test phases set out in the test framework would enable a clear understanding of all the residual risks encountered approaching implementation, providing stakeholders with the context required to make a calculated judgement on these risks.

When an issue was identified through testing, a triage process was undertaken to categorise the issues as either a technical issue, or a user issue. User issues were further classified as “training” or “change of business process”. Technical issues were classified as “showstoppers”, “high”, “medium” and “low”. These were further categorised by priority as “must haves” and “won’t haves” in order to get well-defined acceptance criteria for the substantial list of bugs that arose from the testing cycles. In total, 251 technical issues were identified.

The acceptance criteria for the resolution of issues were:

  • A code fix was implemented
    • A business approved work around was implemented
    • The business accepted the risk

All showstoppers were resolved with either a code fix or and an acceptable work around. Configuration issues were within the remit of Shawbrook’s business application support (“BAS”) team to resolve, whilst other issues could only be resolved by the FIS development team. When the application went live, there were no issues raised post release, and all issues present were known and met the acceptance criteria of the business. 

  • Business processes may no longer align with the new web-based application

Since the project was an upgrade, there was the potential for operational impact of existing functionality due to differences between the Ambit client server solution, and the upgraded Ambit Enterprise web-based solution. The BAS team at Shawbrook were required to make changes to the business processes in order to align with the way the Ambit Enterprise solution now operated. Where Shawbrook specific issues could not be resolved through the configuration of the application with the business processes, changes were made to the functionality within Ambit, for example, additional plug-ins were developed for the Sales Portal platform to integrate with the Ambit Enterprise application. 

Because Ambit Enterprise was a web-based application, application and security vulnerabilities needed to be identified so that the correct security level was achieved. Because of this, performance and security testing, which was currently not being executed, needed to be introduced to the test framework. Performance testing also needed to be executed so that speed and stability requirements under the expected workloads were met.

Summary and Conclusions

The team at Shawbrook successfully developed a test framework which could be used across all projects within Business Finance. The development of the test framework lead to the generation of a regression test pack for the Ambit Enterprise upgrade. By undertaking these R&D activities, Shawbrook gained knowledge in the use of Azure Cloud Environment for testing, and increased its automated testing capabilities, enabling the transition to a continuous delivery framework whereby the majority of testing is automated.


[1] Ambit is the asset finance application operating within the business unit, 70-80 percent of transactions on all lending is captured and managed through Ambit

[2] FIS is the Ambit Enterprise vendor

Advertisement

Different Software Testing – Explained

Testing of software and application is an integral part of the software development and deployment lifecycle. But with so many different types of tests to choose from when compiling your test approach, which are best suited for your requirements?

In this post 45 different tests are explained.

Software Application Testing are conducted within two domains: Functional and Non-Functional Testing.

Functional testing is a software testing process used within softwaredevelopment in which software is tested to ensure that it conforms with all requirements. Functional testing is a way of checking software to ensure that it has all the required functionality that’s specified within its functional requirements.

Functional testing types include:

  • Unit testing
  • Integration testing
  • System testing
  • Sanity testing
  • Smoke testing
  • Interface testing
  • Regression testing
  • Beta/Acceptance testing

Non-functional testing is defined as a type of Software testing to check non-functional aspects (performance, usability, reliability, etc) of a software application. It is designed to test the readiness of a system as per nonfunctional parameters which are never addressed by functional testing.

Non-functional testing types include:

  • Performance Testing
  • Load testing
  • Stress testing
  • Volume testing
  • Security testing
  • Compatibility testing
  • Install testing
  • Recovery testing
  • Reliability testing
  • Usability testing
  • Compliance testing
  • Localization testing

45 Different types of testing – explained

  1. Alpha Testing

It is the most common type of testing used in the Software industry. The objective of this testing is to identify all possible issues or defects before releasing it into the market or to the user. Alpha testing is carried out at the end of the software development phase but before the Beta Testing. Still, minor design changes may be made as a result of such testing. Alpha testing is conducted at the developer’s site. In-house virtual user environment can be created for this type of testing.

  1. Acceptance Testing

An acceptance test is performed by the client and verifies whether the end to end the flow of the system is as per the business requirements or not and if it is as per the needs of the end user. Client accepts the software only when all the features and functionalities work as expected. It is the last phase of the testing, after which the software goes into production. This is also called as User Acceptance Testing (UAT).

  1. Ad-hoc Testing

The name itself suggests that this testing is performed on an ad-hoc basis i.e. with no reference to test case and also without any plan or documentation in place for such type of testing. The objective of this testing is to find the defects and break the application by executing any flow of the application or any random functionality.

Ad-hoc testing is an informal way of finding defects and can be performed by anyone in the project. It is difficult to identify defects without a test case but sometimes it is possible that defects found during ad-hoc testing might not have been identified using existing test cases.

  1. Accessibility Testing

The aim of accessibility testing is to determine whether the software or application is accessible for disabled people or not. Here disability means deaf, color blind, mentally disabled, blind, old age and other disabled groups. Various checks are performed such as font size for visually disabled, color and contrast for color blindness etc.

  1. Beta Testing

Beta Testing is a formal type of software testing which is carried out by the customer. It is performed in Real Environment before releasing the product to the market for the actual end users. Beta testing is carried out to ensure that there are no major failures in the software or product and it satisfies the business requirements from an end-user perspective. Beta testing is successful when the customer accepts the software.

Usually, this testing is typically done by end-users or others. It is the final testing done before releasing an application for commercial purpose. Usually, the Beta version of the software or product released is limited to a certain number of users in a specific area. So end user actually uses the software and shares the feedback to the company. Company then takes necessary action before releasing the software to the worldwide.

  1. Back-end Testing

Whenever an input or data is entered on front-end application, it stores in the database and the testing of such database is known as Database Testing or Backend testing. There are different databases like SQL Server, MySQL, and Oracle etc. Database testing involves testing of table structure, schema, stored procedure, data structure and so on.

In back-end testing GUI is not involved, testers are directly connected to the database with proper access and testers can easily verify data by running a few queries on the database. There can be issues identified like data loss, deadlock, data corruption etc during this back-end testing and these issues are critical to fixing before the system goes live into the production environment

  1. Browser Compatibility Testing

It is a subtype of Compatibility Testing (which is explained below) and is performed by the testing team.

Browser Compatibility Testing is performed for web applications and it ensures that the software can run with the combination of different browser and operating system. This type of testing also validates whether web application runs on all versions of all browsers or not.

  1. Backward Compatibility Testing

It is a type of testing which validates whether the newly developed software or updated software works well with older version of the environment or not.

Backward Compatibility Testing checks whether the new version of the software works properly with file format created by older version of the software; it also works well with data tables, data files, data structure created by older version of that software. If any of the software is updated then it should work well on top of the previous version of that software.

  1. Black Box Testing

Internal system design is not considered in this type of testing. Tests are based on the requirements and functionality.

Detailed information about the advantages, disadvantages, and types of Black box testing can be seen here.

  1. Boundary Value Testing

This type of testing checks the behavior of the application at the boundary level.

Boundary value Testing is performed for checking if defects exist at boundary values. Boundary value testing is used for testing a different range of numbers. There is an upper and lower boundary for each range and testing is performed on these boundary values.

If testing requires a test range of numbers from 1 to 500 then Boundary Value Testing is performed on values at 0, 1, 2, 499, 500 and 501.

  1. Branch Testing

It is a type of white box testing and is carried out during unit testing. Branch Testing, the name itself suggests that the code is tested thoroughly by traversing at every branch.

  1. Comparison Testing

Comparison of a product’s strength and weaknesses with its previous versions or other similar products is termed as Comparison Testing.

  1. Compatibility Testing

It is a testing type in which it validates how software behaves and runs in a different environment, web servers, hardware, and network environment. Compatibility testing ensures that software can run on a different configuration, different database, different browsers and their versions. Compatibility testing is performed by the testing team.

  1. Component Testing

It is mostly performed by developers after the completion of unit testing. Component Testing involves testing of multiple functionalities as a single code and its objective is to identify if any defect exists after connecting those multiple functionalities with each other.

  1. End-to-End Testing

Similar to system testing, End-to-end testing involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.

  1. Equivalence Partitioning

It is a testing technique and a type of Black Box Testing. During this equivalence partitioning, a set of group is selected and a few values or numbers are picked up for testing. It is understood that all values from that group generate the same output. The aim of this testing is to remove redundant test cases within a specific group which generates the same output but not any defect.

Suppose, application accepts values between -10 to +10 so using equivalence partitioning the values picked up for testing are zero, one positive value, one negative value. So the Equivalence Partitioning for this testing is: -10 to -1, 0, and 1 to 10.

  1. Example Testing

It means real-time testing. Example testing includes the real-time scenario, it also involves the scenarios based on the experience of the testers.

  1. Exploratory Testing

Exploratory Testing is an informal testing performed by the testing team. The objective of this testing is to explore the application and looking for defects that exist in the application. Sometimes it may happen that during this testing major defect discovered can even cause system failure.

During exploratory testing, it is advisable to keep a track of what flow you have tested and what activity you did before the start of the specific flow.

An exploratory testing technique is performed without documentation and test cases.

  1. Functional Testing

This type of testing ignores the internal parts and focuses only on the output to check if it is as per the requirement or not. It is a Black-box type testing geared to the functional requirements of an application. For detailed information about Functional Testing click here.

  1. Graphical User Interface (GUI) Testing

The objective of this GUI testing is to validate the GUI as per the business requirement. The expected GUI of the application is mentioned in the Detailed Design Document and GUI mockup screens.

The GUI testing includes the size of the buttons and input field present on the screen, alignment of all text, tables and content in the tables.

It also validates the menu of the application, after selecting different menu and menu items, it validates that the page does not fluctuate and the alignment remains same after hovering the mouse on the menu or sub-menu.

  1. Gorilla Testing

Gorilla Testing is a testing type performed by a tester and sometimes by developer the as well. In Gorilla Testing, one module or the functionality in the module is tested thoroughly and heavily. The objective of this testing is to check the robustness of the application.

  1. Happy Path Testing

The objective of Happy Path Testing is to test an application successfully on a positive flow. It does not look for negative or error conditions. The focus is only on the valid and positive inputs through which application generates the expected output.

  1. Incremental Integration Testing

Incremental Integration Testing is a Bottom-up approach for testing i.e continuous testing of an application when a new functionality is added. Application functionality and modules should be independent enough to test separately. This is done by programmers or by testers.

  1. Install/Uninstall Testing

Installation and uninstallation testing is done on full, partial, or upgrade install/uninstall processes on different operating systems under different hardware or software environment.

  1. Integration Testing

Testing of all integrated modules to verify the combined functionality after integration is termed as Integration Testing. Modules are typically code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.

  1. Load Testing

It is a type of non-functional testing and the objective of Load testing is to check how much of load or maximum workload a system can handle without any performance degradation.

Load testing helps to find the maximum capacity of the system under specific load and any issues that cause the software performance degradation. Load testing is performed using tools like JMeter, LoadRunner, WebLoad, Silk performer etc.

  1. Monkey Testing

Monkey testing is carried out by a tester assuming that if the monkey uses the application then how random input, values will be entered by the Monkey without any knowledge or understanding of the application. The objective of Monkey Testing is to check if an application or system gets crashed by providing random input values/data. Monkey Testing is performed randomly and no test cases are scripted and it is not necessary to

Monkey Testing is performed randomly and no test cases are scripted and it is not necessary to be aware of the full functionality of the system.

  1. Mutation Testing

Mutation Testing is a type of white box testing in which the source code of one of the program is changed and verifies whether the existing test cases can identify these defects in the system. The change in the program source code is very minimal so that it does not impact the entire application, only the specific area having the impact and the related test cases should able to identify those errors in the system.

  1. Negative Testing

Testers having the mindset of “attitude to break” and using negative testing they validate that if system or application breaks. A negative testing technique is performed using incorrect data, invalid data or input. It validates that if the system throws an error of invalid input and behaves as expected.

  1. Non-Functional Testing

It is a type of testing for which every organization having a separate team which usually called as Non-Functional Test (NFT) team or Performance team.

Non-functional testing involves testing of non-functional requirements such as Load Testing, Stress Testing, Security, Volume, Recovery Testing etc. The objective of NFT testing is to ensure whether the response time of software or application is quick enough as per the business requirement.

It should not take much time to load any page or system and should sustain during peak load.

  1. Performance Testing

This term is often used interchangeably with ‘stress’ and ‘load’ testing. Performance Testing is done to check whether the system meets the performance requirements. Different performance and load tools are used to do this testing.

  1. Recovery Testing

It is a type of testing which validates that how well the application or system recovers from crashes or disasters.

Recovery testing determines if the system is able to continue the operation after a disaster. Assume that application is receiving data through the network cable and suddenly that network cable has been unplugged. Sometime later, plug the network cable; then the system should start receiving data from where it lost the connection due to network cable unplugged.

  1. Regression Testing

Testing an application as a whole for the modification in any module or functionality is termed as Regression Testing. It is difficult to cover all the system in Regression Testing, so typically automation testing tools are used for these types of testing.

  1. Risk-Based Testing (RBT)

In Risk Based Testing, the functionalities or requirements are tested based on their priority. Risk-based testing includes testing of highly critical functionality, which has the highest impact on business and in which the probability of failure is very high. The priority decision is based on the business need, so once priority is set for all functionalities then high priority functionality or test cases are executed first followed by medium and then low priority functionalities.

The low priority functionality may be tested or not tested based on the available time. The Risk-based testing is carried out if there is insufficient time available to test entire software and software needs to be implemented on time without any delay. This approach is followed only by the discussion and approval of the client and senior management of the organization.

  1. Sanity Testing

Sanity Testing is done to determine if a new software version is performing well enough to accept it for a major testing effort or not. If an application is crashing for the initial use then the system is not stable enough for further testing. Hence a build or an application is assigned to fix it.

  1. Security Testing

It is a type of testing performed by a special team of testers. A system can be penetrated by any hacking way.

Security Testing is done to check how the software or application or website is secure from internal and external threats. This testing includes how much software is secure from the malicious program, viruses and how secure and strong the authorization and authentication processes are.

It also checks how software behaves for any hackers attack and malicious programs and how software is maintained for data security after such a hacker attack.

  1. Smoke Testing

Whenever a new build is provided by the development team then the software testing team validates the build and ensures that no major issue exists. The testing team ensures that build is stable and a detailed level of testing is carried out further. Smoke Testing checks that no show stopper defect exists in the build which will prevent the testing team to test the application in detail.

If testers find that the major critical functionality is broken down at the initial stage itself then testing team can reject the build and inform accordingly to the development team. Smoke Testing is carried out to a detailed level of any functional or regression testing.

  1. Static Testing

Static Testing is a type of testing which is executed without any code. The execution is performed on the documentation during the testing phase. It involves reviews, walkthrough, and inspection of the deliverables of the project. Static testing does not execute the code instead of the code syntax, naming conventions are checked.

The static testing is also applicable for test cases, test plan, design document. It is necessary to perform static testing by the testing team as the defects identified during this type of testing are cost-effective from the project perspective.

  1. Stress Testing

This testing is done when a system is stressed beyond its specifications in order to check how and when it fails. This is performed under heavy load like putting large number beyond storage capacity, complex database queries, continuous input to the system or database load.

  1. System Testing

Under System Testing technique, the entire system is tested as per the requirements. It is a Black-box type testing that is based on overall requirement specifications and covers all the combined parts of a system.

  1. Unit Testing

Testing an individual software component or module is termed as Unit Testing. It is typically done by the programmer and not by testers, as it requires a detailed knowledge of the internal program design and code. It may also require developing test driver modules or test harnesses.

  1. Usability Testing

Under Usability Testing, User-friendliness check is done. Application flow is tested to know if a new user can understand the application easily or not, Proper help documented if a user gets stuck at any point. Basically, system navigation is checked in this testing.

  1. Vulnerability Testing

The testing which involves identifying of weakness in the software, hardware and the network is known as Vulnerability Testing. Malicious programs, the hacker can take control of the system, if it is vulnerable to such kind of attacks, viruses, and worms.

So it is necessary to check if those systems undergo Vulnerability Testing before production. It may identify critical defects, flaws in the security.

  1. Volume Testing

Volume testing is a type of non-functional testing performed by the performance testing team.

The software or application undergoes a huge amount of data and Volume Testing checks the system behavior and response time of the application when the system came across such a high volume of data. This high volume of data may impact the system’s performance and speed of the processing time.

  1. White Box Testing

White Box testing is based on the knowledge about the internal logic of an application’s code.

It is also known as Glass box Testing. Internal software and code working should be known for performing this type of testing. Under this tests are based on the coverage of code statements, branches, paths, conditions etc.

Release Management as a Competitive Advantage

“Delivery focussed”, “Getting the job done”, “Results driven”, “The proof is in the pudding” – we are all familiar with these phrases and in Information Technology it means getting the solutions into operations through effective Release Management, quickly.

In the increasingly competitive market, where digital is enabling rapid change, time to market is king. Translated into IT terms – you must get your solution into production before the competition does, through an effective ability to do frequent releases. Doing frequent releases benefit teams as features can be validated earlier and bugs detected and resolved rapidly. The smaller iteration cycles provide flexibility, making adjustments to unforeseen scope changes easier and reducing the overall risk of change while rapidly enhancing stability and reliability in the production environment.

IT teams with well governed agile and robust release management practices have a significant competitive advantage. This advantage materialises through self-managed teams consisting of highly skilled technologist who collaborative work according to a team defined release management process enabled by continuous integration and continuous delivery (CICD), that continuously improves through constructive feedback loops and corrective actions.

The process of implementing such agile practices, can be challenging as building software becomes increasingly more complex due to factors such as technical debt, increasing legacy code, resource movements, globally distributed development teams, and the increasing number of platforms to be supported.

To realise this advantage, an organisation must first optimise its release management process and identify the most appropriate platform and release management tools.

Here are three well known trends that every technology team can use to optimise delivery:

1. Agile delivery practises – with automation at the core 

So, you have adopted an agile delivery methodology and you’re having daily scrum meetings – but you know that is not enough. Sprint planning as well as review and retrospection are all essential elements for a successful release, but in order to gain substantial and meaningful deliverables within the time constraints of agile iterations, you need to invest in automation.

An automation ability brings measurable benefits to the delivery team as it reduces the pressure on people in minimising human error and increasing overall productivity and delivery quality into your production environment that shows in key metrics like team velocity. Another benefit automation introduces is consistent and repeatable process, enabling easily scalable teams while reducing errors and release times. Agile delivery practices (see “Executive Summary of 4 commonly used Agile Methodologies“) all embrace and promote the use of automation across the delivery lifecycle, especially in build, test and deployment automation. Proper automation support delivery teams in reducing overhead of time-consuming repetitive tasks in configuration and testing so them can focus on the core of customer centric product/service development with quality build in. Also read How to Innovate to stay Relevant“; “Agile Software Development – What Business Executives need to know” for further insight in Agile methodologies…

Example:

Code Repository (version Control) –> Automated Integration –> Automated Deployment of changes to Test Environments –> Platform & Environment Changes automated build into Testbed –> Automated Build Acceptance Tests –> Automated Release

When a software developer commits changes to the version control, these changes automatically get integrated with the rest of the modules. Integrated assembles are then automatically deployed to a test environment – changes to the platform or the environment, gets automatically built and deployed on the test bed. Next, build acceptance tests are automatically kicked off, which would include capacity tests, performance, and reliability tests. Developers and/or leads are notified only when something fails. Therefore, the focus remains on core development and not just on other overhead activities. Of course, there will be some manual check points that the release management team will have to pass in order to trigger next the phase, but each activity within this deployment pipeline can be more or less automated. As your software passes all quality checkpoints, product version releases are automatically pushed to the release repository from which new versions can be pulled automatically by systems or downloaded by customers.

Example Technologies:

  • Build Automation:  Ant, Maven, Make
  • Continuous Integration: Jenkins, Cruise Control, Bamboo
  • Test Automation: Silk Test, EggPlant, Test Complete, Coded UI, Selenium, Postman
  • Continuous Deployment: Jenkins, Bamboo, Prism, Microsoft DevOps

2. Cloud platforms and Virtualisation as development and test environments

Today, most software products are built to support multiple platforms, be it operating systems, application servers, databases, or Internet browsers. Software development teams need to test their products in all of these environments in-house prior to releasing them to the market.

This presents the challenge of creating all of these environments as well as maintaining them. These challenges increase in complexity as development and test teams become more geographically distributed. In these circumstances, the use of cloud platforms and virtualisation helps, especially as these platforms have recently been widely adopted in all industries.

Automation on cloud and virtualised platforms enables delivery teams to rapidly spin up/down environments optimising infrastructure utilisation aligned with demand while, similar to maintaining code and configuration version history for our products, also maintain the version history of all supported platforms. Automated cloud platforms and virtualisation introduces flexibility that optimises infrastructure utilisation and the delivery footprint as demand changes – bringing savings across the overall delivery life-cycle.

Example:

When a build and release engineer changes configurations for the target platform – the operating system, database, or application server settings – the whole platform can be built and a snapshot of it created and deployed to the relevant target platforms.

Virtualisation: The virtual machine (VM) is automatically provisioned from the snapshot of base operating system VM, appropriate configurations are deployed and the rest of the platform and application components are automatically deployed.

Cloud: Using a solution provider like Azure or AWS to deliver Infrastructure-as-a-Service (IaaS) and Platform as a Service (PaaS), new configurations can be introduced in a new environment instance, instantiated, and configured as an environment for development, testing, staging or production hosting. This is crucial for flexibility and productivity, as it takes minutes instead of weeks to adapt to configuration changes. With automation, the process becomes repeatable, quick, and streamlines communication across different teams within the Tech-hub.

3. Distributed version control systems

Distributed version control systems (DVCS), for example GIT, Perforce or Mercurial, introduces flexibility for teams to collaborate at the code level. The fundamental design principle behind DVCS is that each user keeps a self-contained repository with complete version history on one’s local computer. There is no need for a privileged master repository, although most teams designate one as a best practice. DVCS allow developers to work offline and commit changes locally.

As developers complete their changes for an assigned story or feature set, they push their changes to the central repository as a release candidate. DVCS offers a fundamentally new way to collaborate, as  developers can commit their changes frequently without disrupting the main codebase or trunk. This becomes useful when teams are exploring new ideas or experimenting as well as enabling rapid team scalability with reduced disruption.

DVCS is a powerful enabler for the team that utilise an agile-feature-based branching strategy. This encourages development teams to continue to work on their features (branches) as they get ready, having fully tested their changes locally, to load them into next release cycle. In this scenario, developers are able to work on and merge their feature branches to a local copy of the repository.After standard reviews and quality checks will the changes then be merged into the main repository.

To conclude

Adopting these three major trends in the delivery life-cycle enables a organisation to imbed proper release management as a strategic competitive advantage. Implementing these best practices will obviously require strategic planning and an investment of time in the early phases of your project or team maturity journey – this will reduce the organisational and change management efforts to get to market quicker.