Agile Transformation of Software Testing ICT Services as an enabler for Digital Transformation acceleration

Abstract

As society embraces the digital era, organisations are inclined to embrace Digitalization. This involves adapting to the advancements of technology by digitizing their products and services. The COVID-19 pandemic served as a major catalyst to Digital evolution when it regulated people movement and socialising. This meant that companies needed to respond with haste or be at risk of going out of business. The digital transformation of said business is, in most cases, delivered by their organisations Software Engineering ICT Services. A critical and costly phase of all Software Engineering life cycles and methodologies is Software Testing. Agile methodologies have recently become immensely popular, as they are seen as enablers for new and improved ways of work. This research study examines how the Agile methodology can be utilized to transform Software Testing ICT services and processes to enable accelerated delivery. To ascertain the enablement of the delivery acceleration, key transformation outcomes such as a faster time to market, change failure rates and how the Agile principles enables them will form the premise of this research study.

1. Introduction

The internet soars, all over the globe, over a short period of time (Leeflang et al., 2014) and we bear witness to the mobile industry taking flight, which brings the internet to our fingertips. The Digital era is upon us. This generates a demand on industries to adapt to these technologic advances by digitizing their products and associated business models (Fuchs and Hess, 2018). Today, we are living in the age where literally anything and everything we want, from groceries to furniture, can be â€˜ordered onlineâ€™ and delivered right to our very doorstep. It is not limited to just ordering goods, but extended even further to services such as banking, appointment bookings, etc.

The recent COVID-19 pandemic rapidly became a catalyst for digital transformation (Nanda, Xu, and Zhang, 2021). Regulations implemented throughout the world had restricted the movement of people and this further escalated to lockdowns that subsequently caused multiple industries to lose business and, in some instances, shut down completely (Pinzaru, Zbuchea and Anghel, 2020). One of the solutions to prevent a complete collapse of businesses, was to implement a digital transformation of the organisations operating models and processes or accelerate it, if already in progress as part of the digital era impacts (Pinzaru, Zbuchea and Anghel, 2020).

Software is at the heart of digitalization and therefore so is Software development (Klotins and Peretz-Andersson, 2022). The Software Development lifecycle more specifically, is a group of processes that collectively produces said software (Beng Leau et al., 2012). The life cycle covers all phases, which takes you all the way from ideation, which is the point in time where you start defining and ultimately designing your idea, to deployment of the working program. The phases include requirements gathering and definition to establish exactly what must be built, design and solutioning, where you define how the requirements will be built/met, development to code the actual solution, the testing of the solution to ensure it is working as designed and then deployment of said solution into an environment where the user can access it without any issues (Beng Leau et al., 2012).

The testing phase or software testing process is one of the most critical parts of the SDLC. It involves assessing whether the software meets the requirements that were established when building the software (Pan, 1999). This is done by executing test cases or use cases that are established by applying testing techniques and knowledge on how the system should operate (Whittaker, 2000). There are multiple test types including but not limited to functional (whereby the core functions of the software are tested), integration testing (where integration between components is tested) and regression testing (where the software is tested post changes to ensure that the functionality has not regressed) (Whittaker, 2000). Naturally, executing these different types of testing can be extremely time consuming and expensive.

As the need to digitally transform intensified, so did the pressure to delivery faster and as such, organisations Software Engineering ICT Services needed to find very innovative and fluid ways of work. One of the mechanisms that supports this, is the Agile methodology. When considering agile software development specifically, the development is incremental and iterative as noted by (Victor Szalvay, 2004), which means that the core phases of the SDLC such as design, analysis, development, and testing are repeated in the form of cycles and driven by specific goals. A key principle that agile methodologies are based on includes a focus of actual delivery of value to customers over documentation and admin intensive processes (Victor Szalvay, 2004).

As a result of multiple success stories, many organisations have now sought to kick off an Agile Transformation (Gandomani, Zulzalil and Nafchi, 2014). This is seen as the procedure of moving away from legacy methodologies and moving towards the implementations of the Agile software development life cycle (Gandomani, Zulzalil and Nafchi, 2014). The transformation extends itself even further than just software development, into assisting with new thought processes and rapid responsiveness (Olteanu, 2018). Therefore, we see the adoption of agile principles and methods across multiple different departments and sections of the organizations.

This research study will provide a deeper look into exactly how Software Engineering ICT Service processes, specifically Software Testing ICT services, transformation from legacy methodologies to Agile, can be used to accelerate and support the overall efficiencies of the software delivery or software development life cycle. It will focus on how said Agile Transformation, will enable innovation, faster decision making and faster delivery within the software testing ICT services. Underpinning these focus areas, will be a theme of quality assurance which will be factored in continuously by ensuring the quality metrics are being explicitly reviewed throughout the process, with a concentration on improving change failure rates.

?

2. Problem Statement on Software Testing ICT Services

In this section of the research study, the problem statements are articulated.

2.1.Problem Statement:

As technology advanced, the availability and ease of use of the internet grew (Leeflang et al., 2014). This was further empowered by the advancements of mobile internet and internet enabled mobile devices such as smart phones. Some industries have been able to adapt to this change over time and now offer their products and services digitally. When the COVID pandemic struck the planet, organisations who were not â€˜digitally readyâ€™ were severely impacted (Pinzaru, Zbuchea and Anghel, 2020). To remain competitive and resilient, almost all companies now need to transform their operating models and processes in such a way that they can offer their products and services digitally. This digital transformation requires the software engineering ICT services and processes to rapidly adopt new ways of work that enables the company to respond to change quickly and adequately which as a result, demands a change in mindset.

One of the components or phases of the SDLC that is synonymous for â€˜causing delaysâ€™ due to it taking a large amount of time to be completed, is software testing ICT services. Traditional software testing processes and governance are lengthy and time consuming. They are sequential, and this is further compounded by traditional methodologies of software development and testing, not being able to adapt to the ever-changing business requirements (Wadood et al., 2022). These core challenges highlight further issues, such as the increase in costs when defects are found late in the delivery life cycle due its sequential nature, causing additional development efforts for fixes, retesting, regression testing, etc. extremely late in the delivery schedule. These challenges collectively form the problems statement that will be the focus of this research study.

3. Research Questions

In this section of the research study, the research questions are articulated.

3.1.Research Parent-Questions:

How can Agile Transformation of software testing ICT services enable delivery acceleration, particularly digitalization, in an organisation?

3.2.Research Sub-Questions:

Â·?????? SQ1 - One of the requirements of the Digital transformation is to respond to change quickly. How does an Agile transformation of software testing ICT services, enable a faster time to market?

Â·?????? SQ2 - When an organization increases their frequency of change, the associated risk of failures also increases. How does an Agile Transformation of software testing ICT services, enable a reduction in change failure rates?

Â·?????? SQ3 - As organizations look to adapt to change, they will also need to be able to change their way of thinking. How does an Agile transformation of software testing ICT services, support innovation, faster decision making and team cohesion?

4. Research Objectives and Scope

4.1.Research Objectives:

Â·?????? This research study will show how implementing the Agile methodology and ways of work in an organisationâ€™s software testing ICT Services can enable and accelerate its delivery, and in particular its Digital transformation.

Â·?????? It will articulate key quantifiable outcomes that Agile transformations will produce in an organisation over a period.

Â·?????? Understand the gaps and limitations that the literature on Agile transformations have uncovered, if any.

4.2.Research Deliverables:

Â·?????? This research study will answer the questions posed above by showing evidence from published literature.

Â·?????? Provide insights on the practicality of Agile Transformations enabling the objectives and key results that organizations expect as outcomes of said transformation.

Â·?????? Provide potential research gaps and where possible, further research direction to uncover said gaps to support readers who are looking to take this research topic further.

5. Literature Review

In this section, a review of the literature that formed part of the research materials is discussed.

5.1. Introduction

With the Digital era upon us, almost anything and everything that we need is available at our fingertips. Organizations are often forced into situations where they need to adapt or perish if competitors â€˜went digitalâ€™ before them. As a result, organizations started to invest in digitizing their products and services with haste. The COVID-19 pandemic that has plagued our lives, became a catalyst for this evolution. This meant that organizations needed to accelerate their digitalization, which for many companies, meant delivering software development ICT services faster. A key component of the software development ICT services and often the most time consuming, is software testing ICT services which in turns makes it a core focus area for review. As the software development and software testing industries matured, new methodologies such as Agile emerged in which software is delivered incrementally and iteratively (Victor Szalvay, 2004). In this literature review, we will research and define several concepts as part of a journey to ultimately defining how the agile transformation of Software Testing ICT Services can be an enabler for digital transformation acceleration.

5.2. Digital Transformation or Digitalization

As with most things in life, evolution is a natural occurrence over time. Similarly, we observe the Information Technology industry evolve on a regular basis, with bigger, brighter, more efficient, and leaner ways to achieve objectives. This impacts virtually every industry that makes use of information systems to provide products and services to their customers. On the other hand, there are industries who have not yet implemented digital solutions and information systems as part of their business and operating models. There often comes a time when such industries need to now adapt to the technologic evolution in order to remain competitive and resilient in their respective sectors. This is when industries undertake a process where the entire organization or critical parts of it, make changes that will leverage IT systems and solutions as per (Fuchs and Hess, 2018). They go on to explain that this process is often referred to as digitalization or digital transformation.

These changes will create efficiencies in existing processes and define new products and opportunities for the organization that are digitally ready (Fuchs and Hess, 2018). This could mean several different things, such as their product and services now being available for purchase on IT Platforms such as eCommerce websites and portals or the process to design and build their products will now be managed by IT Systems or their actual product and service can be offered remotely through remote connectivity, etc. At this point in time, we are seeing technology evolve so rapidly, that something developed today, can be obsolete tomorrow. It is for this reason that even after going through a digitalization process, organizations need to remain relevant by continuously ensuring that their digital solutions are always leveraging the latest technological advancements.

5.3. COVID-19 impact on the need for Digital Transformation.

In the previous section we established what digitalization is and how it has become a mega-trend amongst most organizations and industries. In more recent years, humankind went through the COVID-19 pandemic which then prompted even larger, unexpected disruptions (Nanda, Xu, and Zhang, 2021). One of the biggest disruptions included the limitation of movement of people or what was more famously known as the â€˜lockdownâ€™ (Pinzaru, Zbuchea and Anghel, 2020). They go on to explain that this confinement was intended to reduce physical contact in order to decrease the chance of spreading the infections. From here they draw our focus to the fact that this disruption created a dynamic change in both our social and economic lifestyle and habits, as simple things like going to the store for groceries and going to the office for work were no longer possible.

The reduced mobility of the community meant that alternative methods for our daily errands and routines had to be defined with haste. This included but was not limited to working from home remotely instead of going to the office, buying goods online so that they can be delivered to your house instead of you going to the store, streaming movies on your TV using the internet instead of going to the movie theaters and the list goes on. This now meant that if industries and organizations were not already â€˜digitally readyâ€™, they needed to do so urgently in order to remain competitive and at times, in order to remain in business. A practical example of this is a grocery store whose products were only available to be purchased physically in the store. During the COVID-19 pandemic, as movement was restricted it was not always possible to get to the store to purchase your groceries. This meant that customers did not have access to goods and businesses did not have customers, which meant no revenue. On the other hand, businesses whose products were already available to be purchased online and delivered to homes saw an increase in revenue and demand. That is how COVID-19 heavily influenced the need and urgency for digital transformation in many industries. ?

5.4. Software Development ICT Services as an enabler for Digital Transformation

Software is a fundamental component to enabling the digitalization of organizations products, services, processes, and functions (Klotins and Peretz-Andersson, 2022). The group of processes that jointly produces the software is called the Software Development lifecycle (Beng Leau et al., 2012). Many organizations have a specific department often referred to as the â€˜Technology departmentâ€™ whose sole focus is to provide Technology related services to the rest of the organization. In some organizations, they are also referred to as the ICT Services or Information and Communication Technology Services (Bon, Akkermans and Gordijn, 2016). These services include all phases and processes of the software development life cycle.

When organizations kick off a digital transformation journey in the shape and form of a project or program, they would need to leverage each phase of the Software Development Life Cycle that is provided by the companies ICT Services. This, according to (Beng Leau et al., 2012) traditionally includes multiple key phases:

1.???? Define the requirements for the project.

2.???? Establish the time required to implement each phase including provision for any unseen delays.

3.???? Design the solution which includes solution architecture and technical infrastructure.

4.???? Development phase where actual code is written by multiple software engineers.

5.???? Testing phase with overlap of the development phase to cater for the fixing of issues found in testing.

6.???? Inclusion of customers into the testing phase towards the completion of the project as the project is only considered as delivered once the customer is happy with it.

The combination of these software development ICT services, coordinated by a Project Manager would enable the successful delivery of the Digital Transformation project.

5.5. Software Testing ICT Services in the SDLC

As we reflect on the phases of the software development lifecycle covered by the software development ICT services in the last section, we now focus on one of the most fundamental phases, the testing phase. In (Pan, 1999), they advise that the software testing phase is where we assess the quality of the software by establishing if the software meets the customer requirements, which was traditionally defined in earlier parts of the SDLC. They go on to refer to software testing as a niche skillset that involves understanding software engineering, testing techniques and test types to establish the best suited test strategy for the project in hand. Software testing is a fairly complex process where analysts apply testing techniques and knowledge on how the system should operate to establish test cases and use cases that determine how the system should behave within certain scenarios, conditions, and circumstances (Whittaker, 2000). These cases are executed against the software by following the steps in the test cases, ensuring the expected results is seen through the test cases and flagging any issues and discrepancies as defects as explained by (Whittaker, 2000). They build onto this by defining defects as the failures of the system that are often caused by errors in the code.

There are multiple test types within the software testing phase that need to be considered when establishing the appropriate test approach for any given project. The types of testing, according to (Whittaker, 2000) and (Pan, 1999) include:

1.???? Functional or black box testing â€“ this refers to the testing that is based on the functional requirements of the system, which is tested by executing the functions of the systems and assessing the input and output data. The system is viewed as a â€˜black boxâ€™, without any knowledge, visibility, or considerations of the inner workings of the software.

2.???? Unit Testing or White Box Testing - The system is viewed as a â€˜white boxâ€™ or â€˜glass boxâ€™ with full knowledge, visibility, or consideration of the inner workings of the software which includes programming language, logic, etc. Here the focus is to test at a coding level with elements of statement and branch coverage.

3.???? Regression Testing â€“ where the software is tested post changes to ensure that the functionality has not regressed.

4.???? Performance Testing â€“ this is where we test how the system will perform over a multitude of scenarios such as one customer, high volume of customers in an instance (load), high volume of customers over time (soak), etc. Metrics such as response times, resource usage, throughput, etc. is monitored and recorded.

5.???? Security Testing â€“ This is where we rigorously test the system for vulnerabilities, violations, data protection and privacy measures, etc. A common type of security testing execution is called penetration testing where we test to see how â€˜penetrableâ€™ the system is from a security perspective.

Naturally, executing these different types of testing can be extremely time consuming and expensive. These therefore pose a challenge when we need to accelerate the overall delivery of digital transformation projects.

5.6. The Agile Methodology

Over time we saw the need to digitally transform intensify, and in conjunction with this, so did the pressure to deliver faster. To adapt to this, organisations Software Development ICT Services needed to find very innovative and fluid ways of work. One of the mechanisms that were established while trying enable this, is the Agile methodology. In Agile methods, the software development is incremental and iterative as noted by (Victor Szalvay, 2004), which means that the core phases of the SDLC such as design, analysis, development, and testing are repeated in the form of cycles and driven by specific goals. They go on further to describe this as the development lifecycle being separated into â€˜incrementsâ€™ or â€˜iterationsâ€™ where each iteration encompasses the conventional phases of the software lifecycle.

A key principle that agile methodologies are based on includes a focus of actual delivery of value to customers over documentation and admin intensive processes (Victor Szalvay, 2004). A terse outline of Agile values was established in the early 90â€™s which is referred to as the â€˜Agile Manifestoâ€™ (Victor Szalvay, 2004). They go on to highlight that Agile methods advocate software engineering methods that enable economical change as well as rapid production with minimal upfront design required.

(Campanelli and Parreiras, 2015) defines the present mainstream agile methods as:

1.???? XP (Extreme Programming) â€“ a methodology built to assist small teams to engineer software at the back of unclear and regularly shifting requirements. In addition to its lightweight nature, it focuses on cost savings, unit testing before and during code activities, frequent full system integrations, pair programming, simple design, and frequent releases of working software.

2.???? Scrum â€“ a framework for delivering products of the highest value while handling complex challenges, usually in an iterative or incremental manner and done by cross-functional teams. It emphasizes knowledge, experience, and making decisions based on that knowledge.

3.???? Kanban - A workflow should be visualized, work in progress should be limited and completion times should be measured. It is recognised as an adaptable, visual, and cost attentive methodology.

4.???? Lean - The concept considers waste activities those that do not add value to the customer, and as such, the main objective is to deliver according to the customerâ€™s needs.

5.???? FDD (Feature Driven Development) â€“ method which focuses on the quality of the process and regular releases over time. It consists of five primary consecutive processes: develop an overall model, build a features list, plan by feature, design by feature, and build by feature. It is the only agile method that claims to be fit for critical system development.

6.???? DSDM (Dynamic System Development Method) â€“ this method is considered an open-framework to be used for RAD (Rapid Application Development) with the project flow driven by the number of resources available. The delivery time of the features are pre-determined with flexibility on the number of features released based on productivity.

7.???? ASD (Adaptive Software Development) â€“ method that focuses on solving issues in large and complex software delivery. The intention is to supply guidelines that prevent project failures while trying not to prevent creativity and maintaining speed and agility. Key concepts include iterative development, incremental features, and prototyping.

8.???? Crystal â€“ this methodology focuses on people and their connections as opposed to tools and processes. It has 2 core principles i.e. teams are able to improve and optimise their workflows by themselves and every project team is best suited to establish how it will tackle its project work since every project is unique and ever changing.

9.???? RUP (Rational Unified Process) â€“ iterative process focused on object orientated system development and the use of UML (Unified Markup Language) e.g., Use Cases. It consists of four key phases Inception, elaboration, construction, and transition and can be adopted either partially or holistically.

5.7. Organizational Agile Transformation

In the previous section, we discussed the Agile methodology and the different agile methods. The methodology offers new ways of thinking, faster resolution of problems and delivery time as well as new values (Olteanu, 2018). These benefits appeal to organizations who then embark on a journey to use these Agile methods as opposed to their existing more conventional methodologies (Gandomani, Zulzalil and Nafchi, 2014). This journey is the Agile transformation that companies undertake, motivated to do so by the results of increased success rates in software engineering, quality, improved skills, motivation, and productivity of ICT teams (Olteanu, 2018).

Agile transformation is a change that occurs at an organizational level in both cultural and technical practices and as such, comes with a number of challenges (Gandomani, Zulzalil and Nafchi, 2014). They go on to advise that the reason for these challenges is the difference between traditional and Agile methodologies values and practices. Furthermore, it is important to note that agile adoption is not just about practicing agile methods, but also about â€˜being agileâ€™. The majority of the agile methodology are people-oriented processes and therefore the bulk of the transformation lies with changing the peopleâ€™s attitudes, cultures, and mindsets in software development (Gandomani, Zulzalil and Nafchi, 2014). Tools and technology also play a factor for consideration in agile transformation but are seen more as enablers that complement the human-related changes (Gandomani, Zulzalil and Nafchi, 2014).

5.8. Agile Transformation of Software Testing ICT Services

Software testing is a significantly important phase of the Software Development Lifecycle which has matured over time to ensure the ongoing assurance of software products (Najihi et al., 2022). They go on to note that the estimated software testing costs are on average 40% of the total software engineering costs, which is a significant challenge to the clients and stakeholders of software projects. One of the main differences between testing in agile projects and traditional methods is their iterative nature though the ultimate goal of ensuring that the requirements are met remains static (Najihi et al., 2022).

As we noted earlier in this study and further reiterated by (Najihi et al., 2022), agile methods entail team members working collaboratively, adapting to change, and changing direction when necessary. (Najihi et al., 2022), further emphasizes the importance of testing team members being able to work with the design and development teams to provide early feedback and test as the delivery cycles progress. This accentuates the required focus on coordination and shared responsibility to engineering software (Najihi et al., 2022).

The key principles of agile software testing as defined by (Najihi et al., 2022) include:

1.???? Unlike in traditional methodologies, testing is not a separate phase, but rather the test team is included in the processes as early as the requirements gathering phase.

2.???? Testing is embedded into the delivery cycles as opposed to a final phase at the end, to enable continuous testing therefore requirements validations, development, integrations, and testing occur throughout the cycles in an adaptive manner.

3.???? The entire team is responsible for testing as opposed to just the testing team. This includes but is not limited to the business stakeholders, PMâ€™s, developers, and testers.

4.???? Testing is required to provide continuous and regular feedback in order to ensure that the team continues to provide shippable products through shorter, smaller iterations.

5.???? Pairing of developers and testers to develop and test features within the delivery cycles is used in some Agile methods such as XP (Extreme Programming).

6.???? Agile testing focuses on both finding defects and preventing defects through proactiveness and collaboration to ensure that value is provided to the users as opposed to traditional testing which focuses on just finding defects.

7.???? Acceptance testing is done at the end of each sprint on the items delivered in the Sprint as opposed to traditional approaches which perform final acceptance testing at the end of the projects.

6. Research Design and Methodology

In this section, a robust research design and methodology is established which outlines guidelines of research principles and the actual process that was followed to find, analyze, and interpret the information on the topics specified.

6.1.Philosophy

The ontology philosophy was used in this research paper, as it requires the author to look at reality versus perception of reality. It also refers to the study of concepts within an area of expertise and the relation between them. This was appropriate for this research study as understanding the concepts in and around digitalisation, ICT services and agile transformation was the key objective of this study.

6.2.Philosophical stances

The pragmatic approach was chosen as it emphasizes the practicality and flexibility of research findings, focusing on their usefulness and applicability.

6.3.Deductive vs Inductive

The research paper was done in a deductive manner, which proved appropriate since we started the research with statements and clearly articulated questions.

6.4.Research Style

The research style that we used to collect and analyze data was action research. This proved to be appropriate since in the research paper we set out to meet clear objectives, which was followed by understanding the problem and defining the gaps.

6.5.Quantitative vs Qualitative

The mono-method of qualitative research was used as the paper includes opinions and descriptions of multiple sources of information and thus making this the most appropriate choice.

Note this may be further reviewed when completing any follow-up research in this area of study.

6.6.Time Horizon Choices

The cross-sectional horizon was used, as this was a short study.

6.7.Data Collection & Analysis

Â·?????? For each section noted in the assignment instructions and/or rubric, I searched for research material to read up on using Google Scholar and the UNISA Library

Â·?????? Key points from the research materials were used to provide details for each section as required.

Â·?????? Keywords included but are not limited to: â€˜what is digitalizationâ€™, â€˜what is agileâ€™, â€˜what is agile transformationâ€™, â€˜what is SDLCâ€™, â€˜what is software testingâ€™, â€˜agile transformation of software testingâ€™).

7. Results and Findings

Earlier in this paper, we highlighted key challenges and goals of Digital Transformation which included being able to response to change quickly, reducing associated risk of failures, and improved ways of work. We noted that it is the organizationâ€™s software development lifecycle that enables this Digital Transformation. From here we defined a boundary of this research paper by determining that we will be focusing on the software testing life cycle which tends to be a lengthy and time-consuming phase of the SDLC. We now look at the specific impact and improvements an agile transformation has on the time taken to complete the software testing phase, the enabling of a reduction of change failure rates and improved ways of working.

As an initial reference point, we look at the Agile Manifesto which defines improved ways of developing software in the form of 4 core values and 12 associated principles according to (Mohanty et al. 2016). The manifesto assists us with distinguishing agile projects from traditional projects (Coleman, 2016). For each of the 4 core values in the manifesto, we will explore how these are applied to software testing whilst correlating back to the key questions we sought to answer for this research paper, which have been reiterated in the paragraph above. This will be referenced using the following codes that were assigned to the sub-questions in section 3 earlier in this paper (SQ1, SQ2, SQ3).

7.1.Agile Manifesto Value 1 - Individuals and interactions over processes and tools

We note that traditional methodologies relied heavily on following the â€œcorrect processesâ€ and implementation of tools to solve for bottlenecks, etc. according to (Coleman, 2016). They go on to the position that agile methodologies focus on the members of the team, their capabilities, and the promotion of engagements between these individuals. This value encourages continuous interaction between the Software Development team and the customers in particular as per (Al-Saqqa et al. 2020). Building on from this, the software testers are seen as an fundamental role in the software development team that operate as a cross functional unit (Coleman, 2016). We will now look at specific elements of this value that apply to software testing.

7.1.1. Everyone Tests â€“ Ease Bottlenecks, Code Less, and Test More

Whilst we do see evidence that shows everyone is responsible for quality in projects that follow traditional methodologies, the agile projects build on to this even further (Talby et al., 2006). They elaborate on this by highlighting that in agile projects, the expectation is that every project team member will be actively involved in testing therefore, after incorporating the value of customer collaboration, this includes the developers, business analysts, customers, etc. Implementing this mindset and way of work, allows the team to remove the dependency on the testers availability thus reducing bottlenecks by simply coding less and testing more, therefore affectively increasing the teams testing throughput (SQ1) (SQ3) (Talby et al., 2006).

Further to this, the inclusion of the developers in testing created shared understanding on testing outcomes which assisted with reduction and prevention of defects which is direct evidence of reducing the change failure rate (SQ2) and increasing team cohesion (SQ3) (Talby et al., 2006). In additional to this, since all team members were aware of the testing requirements, they also designed for testability thus ensuring that features that are usually difficult and complex to test as-is, was now more testable (SQ3). When it comes to the regression testing, teams are able to opt for the â€˜divide and conquerâ€™ approach where the entire team gets assigned the regression execution towards the tail end of each iteration, working together to ensure successful completion of the regression testing (Talby et al., 2006).

7.1.2. Encourage interaction of test team over isolation

Traditionally, testing disciplines believed that the test team needed to be independent of the project or more specifically, the development teams (Talby et al., 2006). It was believed that testing analysis could be done solely from requirements documentation and that the required tests could not be written sufficiently if the developers have already tried to explain the testing requirements to the testers. These two views were interpreted as Agile not being suitable for producing quality software (Talby et al., 2006). They go on to say that it is not that these views are incorrect but rather that the alternatives are definitely better. It is clear that testers will need to fundamentally change their mindsets to be successful in Agile teams (Talby et al., 2006). From here we look at the findings provided by (Talby et al., 2006) who states that testers who followed traditional methods and worked independently, found few actual defects whilst in teams that worked in an agile method where developers and testers worked together to get things tested, defect counts were significantly reduced (SQ2). This shows that it is much more efficient for the testers/test team to be integrated into the delivery/development team as continuous interaction had yielded more positive outcomes (SQ3).

7.2. Agile Manifesto Value 2 - Working software over comprehensive documentation

We are drawn to the controversial focus that is placed on detailed documentation in the traditional software development approaches (Coleman, 2016). While Agile methodologies on the other hand note that though documentation remains important, we should closely govern the efforts put into documentation, ensuring that we document only that which is necessary and instead focus on what is required to develop the working product (Al-Saqqa et al. 2020). The concept of generating â€˜just enoughâ€™ documentation is introduced and direct engagement between teamsâ€™ members is then pivotal to ensure sufficient communication and alignment is achieved in the absence of certain documents (Coleman, 2016).

7.2.1. Product Size = Test Size / Untested work = no work

Tracking and recording progress remains important in Agile methodologies and a key metric that is often used for this, is the RTF or running tested features which is defined as the number of features that have been successfully developed, tested and are â€˜running smoothlyâ€™ (SeaLights, 2023). Teams use this metric as testing effort tends to be a more accurate view of the complexity of features and including it gives a holistic view of the effort to build the feature (Talby et al., 2006). Further to this, this metrics signals to the team that only features that are fully tested are counted as delivered or in other words, if there is no testing of work, it is not considered delivered/completed which will drive collaboration to produce high quality features (SQ2). An additional approach if for teams to integrate feature testing and coding together where testing and coding estimates are usually equal and emphasizes that no task is considered delivered until it associated tests are written and executing successfully (SQ3) (Talby et al., 2006).

7.2.2. Use a team-centered defect-management approach

The defect-management workflow in an agile methodology is fairly flexible and fluid where anyone on the team can open a new defect that they find, close a defect post fixing and testing it or assign a defect to the most suitable person (Talby et al., 2006). They go on to note that by creating a self-managed defect management process, this will alleviate substantial overheads from the team leads. It is important to note that this type of process only works in teams that sit together or work very closely together remotely (Talby et al., 2006). An additional benefit of the developers and testers working together in the defect management process is the reduction of invalid and duplicate defects.

As part of the defect management process, a policy of fixing defects as soon as you discover it or as soon as possible is required, especially since this is when the significant code is still fresh in the developersâ€™ minds (SQ3) (Talby et al., 2006). They go on to highlight that this correlates directly with the principle that releases should not include any defects (SQ2). In order to manage technical debt sufficiently, defects that could not be fixed in an iteration, such as regression defects found late in the iteration, are focused on at the beginning of the subsequent Sprint (SQ3) (Talby et al., 2006). Agile projects tend to not have the concept of defect severity and instead it is quickly established whether the defect will be fixed or not and if not, it is not opened and if yes, it is fixed when it will cost the least which is usually â€˜immediatelyâ€™ (Talby et al., 2006). This does help prevent lengthy conversations with customers around which defects to fix first, etc. (SQ2).

7.3. Agile Manifesto Value 3 - Customer collaboration over contract negotiation

The term contract in itself holds different meanings in this regard and as such, we will look at this from 2 perspectives. Software development teams have traditionally used requirements documentations to establish agreements between themselves and business teams/customers around what exactly is required to be built (Coleman, 2016). They go on to note that this is seen as a â€˜pseudo contractâ€™ that the teams then spend copious amounts of time on ensuring that it is clear and concise as well as protecting each of the teamsâ€™ interests. The next engagement between these teams then, is once the product is completed and handed over to the business/customer to perform acceptance testing on, only to result in disagreements between what was built and what was expected in the form of multiple defects (Coleman, 2016). The Agile methodologies solves for this by treasuring customer collaboration by means of continuous collaboration and engagements between the delivery team and the business/customer ensuring that sufficient alignment is achieved throughout the process and where not aligned, changes can be made to swiftly re-align without additional work and costs (Coleman, 2016). Legal and commercial contracts between suppliers, contractors, etc. remain necessary (Al-Saqqa et al. 2020).

7.3.1. Applying Agile principles to Traditional Acceptance Testing

Acceptance testing which is also referred to as UAT or User Acceptance Testing is where the business or customer is given the chance to test the software solution that has been built or modified by ensuring that all use cases which are the typical scenarios that users or customers would perform on the system are behaving as expected (Dalton, 2019). As highlighted by (Jeeva Padmini et al. 2016), this activity has been traditionally performed at the tail end or upon completion of the development life cycle which is seen as bad practice as it poses an extremely high risk of failure of the acceptance testing. As such, we will explore how agile practices can be applied to UAT to incorporate it into the Agile life cycle.

In order to integrate the acceptance testing process in the delivery cycle, we need to apply the agile values highlighted in this paper and ensure that we have customer collaboration throughout the process (Dalton, 2019). From their paper, we see that the users and customers are often represented within Agile delivery teams by a Product Owner or in some instances actual users and customers are included within the teams. This allows to embed them into the different stages of testing in the following manner:

1.?????? Understanding of requirements and acceptance criteria is clarified with the Product Owners/Users in the early stages of the interactions.

2.?????? Test cases are reviewed and updated with the Product Owners/Users within the iteration.

3.?????? Test Execution is done by all team members including Product Owners/Users within the Iteration.

4.?????? Defects are clarified and prioritized with the Product Owners/Users within the iteration.

5.?????? Demos of the completed builds/components or Users Stories that make up the software solutions are presented to the Product Owners/Users as soon as they are ready.

If the delivery is of a large scale with multiple inter-dependencies, then a UAT Cycle is scheduled that span across multiple features and therefore potentially across multiple teams. It is important to note that all team members are involved in this cycle to ensure sufficient support and defect turnaround time is provided. By performing the above interventions and new ways of working, we enable faster development completion time (SQ1) and reduce the number of defects that occur (SQ2).

7.4. Agile Manifesto Value 4 - Responding to change over following a plan

Upon reflection of our past project experience that used traditional methodologies for software development, we recall that whilst the initial planning phase has us spending substantial amounts of time building detailed plans, we have repeatedly seen the need to replan and respond to an inevitable change (Coleman, 2016). They go on to advise that this could be due to anything from movements in the market that require us to respond to remain competitive, to changes in legislation. The agile methodology embraces the need to respond to changes with haste and as such development is done in iterations with the planning activities split between long-term release planning and short-term detailed planning (Coleman, 2016). This enables the teams and the development to remain fluid throughout the life cycle, allowing them to easily respond to a change (SQ1) in requirements and constantly aligning to the shared goal of reaching customer satisfaction (Al-Saqqa et al. 2020).

7.4.1. Automate for efficiency

Thus far we have discussed ensuring that testing is included in the development cycle. Now we will look at solutions to accelerate the actual testing process. One such solutions applied to enable development teams to develop and release faster is Test Automation which is defined as the procedure of using testing automation tools to execute the test cases for you including validating actual results with expected results (Albarka Umar and Zhanfang, 2019). They go on to advise that this does have its limitations and therefore not all testing can be automated resulting in a portion of execution remaining manual.

Implementing automated testing into your development life cycle as with any improvements has both advantages and disadvantages. (Albarka Umar and Zhanfang, 2019) describes the advantages as an increase in accuracy and speed in which you can find defects (SQ2), costs and times savings as a result of faster execution which requires less manual efforts (SQ1), increase in test coverage as you are able to execute much more permutations than you could manually (SQ2) and being able to repeat the test executions as frequently as you need (SQ1) which we will discuss a bit further in the next section. They go onto note the disadvantages such as additional time, costs, and skillset required to build the automation framework, write the test scripts, and maintain the test scripts. These upfront costs however are recuperated over time once costs avoidance on manual efforts and defects prevention are realized.

7.4.2. Continuous Testing

Once the development teams have implemented a robust automated testing solution, they now need to implement a process that leverages this in such a manner that enables them to execute their testing quickly, on demand and without increasing the risk of change failure. Continuous Testing is a concept that is often leveraged for this, that entails executing the automated tests regularly for every software build delivered in the pipeline (Madeyski and Kawalerowicz, 2013). They go on to note that the intention is to obtain immediate feedback on the quality of the latest release candidate and the risks associated with it. This enables the team to easily manage the testing of constant builds that will arise at the back of constant requirements changes so that the team is able to establish a faster time to market (SQ1), with highly confident low risk releases (SQ2). The Continuous Testing (CT) process is often a pre-cursor to implementing a Continuous Integration (CI) phase which leverages the continuous testing process to enable the running of a CI Build, CT execution and reporting of results whenever a developer publishes or deploys a change (Bhanushali, 2023).

8. Limitations, Assumptions & Future work

8.1.What Possible Gap(s) Were Identified

Whilst conducting the required research for the paper, multiple topics were explored that spanned across Digitalization, Software Development Lifecycles, Agile Methodologies, Software Testing, etc. As the topics were explored, it was clear that each of them contained a mammoth amount of information and concepts. In order to remain focused, the research questions of this paper were used to maintain the scope and boundaries of the research. Naturally, this has left a large number of areas where we have only â€˜touched the surfaceâ€™ in our research and discussions. These were either discussed in this paper in limitation and can be explored further or were completely excluded to maintain this papers boundariesâ€™ and is recommended to be explored further by researchers looking to fully embed themselves in these research topics. A list of these areas and concepts are noted below:

1.???? Enablers for a Faster Time to Market:

a.???? Micro-Deployments â€“ Shorter and faster deployments that support the release of smaller features to customers more frequently should be researched.

b.???? De-coupling architecture â€“ To enable the deployments of singular application changes, the first step to research is how to decouple the enterprise architectures so that the testing scope per a deployment is much smaller.

c.????? Modularization of code components â€“ To enable the micro-deployments of certain applications, research should be done on how teams can perform a refactor of their code so that code can be deployed in smaller modules so that changes do not impact the entire application thus requiring a smaller set of tests.

2.???? Test Driven Development (TDD) â€“ research should be done on software development processes where the requirements and test cases are built before the start of actual software development and collectively form the basis of the software that is coded so that they can increase the probability of a higher pass rate and less defects.

3.???? Inverting the test pyramid â€“ The traditional test pyramid shows that we focus more on manual frontend tests and less on backend unit tests, therefore research should be done on how faster and more mature implementations actually apply an inverted model of this.

4.???? Shift left strategy â€“ In order to enable faster delivery, it is imperative that we find defects earlier and as such, so research should be done on how the shift left strategy looks at multiple opportunities for testing to occur earlier in the SDLC.

5.???? CI/CD Implementation - When researching how to enable faster testing cycles, we discussed continuous testing and touched base on the next steps being Continuous Integration and Continuous Development/Delivery or CI/CD.? Unfortunately, we did not discuss this topic in detail, and it would be a highly beneficial topic for any researcher looking to fully understand how to implement and fully enable Continuous Testing.

8.2. How Your Research or Future Research can Address This Gap(s).

This research paper serves as a starting point for researchers who are interested in understanding how to accelerate their software testing and overall software delivery durations. As they read through the paper, they will be able to sift out the areas in which they are interested in and from there, they will have the option to further read up on these topics by either going to the articles that I have reference or by going to the section above and having a look at the additional extension points that I have noted down and doing some of their own research.

8.3. Assumptions

1.???? Throughout this paper, multiple terms have been used interchangeably:

a.???? the terms â€˜software engineeringâ€™ and â€˜software developmentâ€™

b.???? the terms â€˜customerâ€™ and â€˜userâ€™

c.????? the terms 'methodologyâ€™ and â€˜Software delivery life cycleâ€™

2.???? The reader of this paper has basic knowledge of software projects and delivery life cycles.

?

9. Discussion & Conclusion

This paper was started by setting the scene of the period during and just after the COVID-19 pandemic which caused a major increase in the need for organizations to briskly adapt to the â€˜new normalâ€™ which meant offering their products and services digitally. This was followed by defining and highlighting the challenges that this brings to the ICT Services departments of these organizations, as this meant more pressure on them to deliver software solutions faster through their software delivery life cycle. The problem statement scope was established by zooming in specifically on the software testing phase of their SDLC. Discussing a problem without discussing solutions is of little value, so the paper explores the industry renowned solution of Agile Methodology and more specifically how transforming our software testing from traditional delivery to agile delivery will assist us.

To ensure that the research outcomes were measured adequately, we established a series of research questions that framed our research scope even further as it guided us on what exact outcomes we were looking to achieve, which included but was not limited to, establishing a faster time to market, reducing the risk of change failure, and improving ways of work. In order to enable the success of the research, a robust research design and methodology was established which outlined guidelines of research principles and the actual process that was going to be followed to find, analyze, and interpret the information on the topics specified.

After triaging multiple sources of information, 25 articles and books were determined to have substantial value to contribute towards this paper. They were used to provide insight to the readers of the research paper on multiple related and in scope topics. The paper looks at digital transformation, how COVID-19 impacted on the need for digital transformation, how software development in ICT Services enables digital transformation and more specifically the software testing ICT services that form part of the SDLC. From there, we reviewed the agile methodology, organizational agile transformation and more specifically the agile transformation of software testing ICT Services.

Using this basis, the information gathered was used to formally answer the core research questions. This was done by discussing the 4 core values of the agile methodology and how these are applied to software development with a key focus on software testing. Within each core value, we further discussed specifics on what aspects of software testing would be transformed to implement said value and how it will be done. Each sub question was referenced within these discussions to create traceability back to the research questions.

From here, it is concluded that the agile transformation of software testing ICT services will indeed enable testing to be completed faster, improve the testing ways of work, and as a result will ensure that adequate testing is still completed regardless of the rate of delivery. These improvements will reduce the risk of change failure. By making these changes to the software testing ICT services, the overall SDLC will be completed faster, which will enable the release of new or updated software products quicker and more frequently. This will allow organizations to develop and mature their digitalization solutions faster, responding to market needs such as COVID-19 promptly, thus enabling the acceleration of their digital transformations. It is important to note that while we have concluded these results, if researchers and readers of this paper wish to implement the transformation discussed, further research is recommended as guided in section 8 of this paper to fully immerse oneself in these topics.

10. References

Albarka Umar, M. and Zhanfang, C. (2019) A Study of Automated Software Testing: Automation Tools and Frameworks.

Al-Saqqa, S., Sawalha, S. and Abdelnabi, H. (2020) â€˜Agile software development: Methodologies and trendsâ€™, International Journal of Interactive Mobile Technologies, 14(11), pp. 246â€“270. Available at: https://doi.org/10.3991/ijim.v14i11.13269.

Beng Leau, Y. et al. (2012) Software Development Life Cycle AGILE vs Traditional Approaches.

Bhanushali, A. (2023) â€˜Challenges and Solutions in Implementing Continuous Integration and Continuous Testing for Agile Quality Assuranceâ€™, International Journal of Science and Research (IJSR), 12(10), pp. 1626â€“1644. Available at: https://doi.org/10.21275/sr231021114758.

Bon, A., Akkermans, H. and Gordijn, J. (2016) â€˜Developing ICT Services in a Low-Resource Development Contextâ€™, Complex Systems Informatics and Modeling Quarterly, (9), pp. 84â€“109. Available at: https://doi.org/10.7250/csimq.2016-9.05.

Campanelli, A.S. and Parreiras, F.S. (2015) â€˜Agile methods tailoring - A systematic literature reviewâ€™, Journal of Systems and Software, 110, pp. 85â€“100. Available at: https://doi.org/10.1016/j.jss.2015.08.035.

Coleman, G. (2016) â€˜Agile Software Developmentâ€™.

Dalton, J. (2019) â€˜Acceptance Testingâ€™, in Great Big Agile. Berkeley, CA: Apress, pp. 111â€“112. Available at: https://doi.org/10.1007/978-1-4842-4206-3_8.

Fuchs, C. and Hess, T. (2018) Becoming Agile in the Digital Transformation: The Process of a Large-Scale Agile Transformation Use of Social Live Streaming Services at the Individual Level View project. Available at: https://www.researchgate.net/publication/330353717.

Gandomani, T.J., Zulzalil, H. and Nafchi, M.Z. (2014) Agile Transformation: What is it about?

Jeeva Padmini, K. V., Perera, I. and Bandara, D.H.M.N. (2016) â€˜Applying agile practices to avoid chaos in User Acceptance Testing: A case studyâ€™, in 2nd International Moratuwa Engineering Research Conference, MERCon 2016. Institute of Electrical and Electronics Engineers Inc., pp. 96â€“101. Available at: https://doi.org/10.1109/MERCon.2016.7480122.

Klotins, E. and Peretz-Andersson, E. (2022) â€˜The unified perspective of digital transformation and continuous software engineeringâ€™, in Proceedings - 5th International Workshop on Software-Intensive Business: Towards Sustainable Software Business, IWSiB 2022. Institute of Electrical and Electronics Engineers Inc., pp. 75â€“82. Available at: https://doi.org/10.1145/3524614.3528626.

Leeflang, P.S.H. et al. (2014) â€˜Challenges and solutions for marketing in a digital eraâ€™, European Management Journal, 32(1), pp. 1â€“12. Available at: https://doi.org/10.1016/j.emj.2013.12.001.

Madeyski, L. and Kawalerowicz, M. (2013) â€˜Continuous test-driven development: A novel agile software development practice and supporting toolâ€™, in ENASE 2013 - Proceedings of the 8th International Conference on Evaluation of Novel Approaches to Software Engineering, pp. 260â€“267. Available at: https://doi.org/10.5220/0004587202600267.

Mohanty, H., Mohanty, J.R. and Balakrishnan, A. (2016) Trends in software testing, Trends in Software Testing. Springer Singapore. Available at: https://doi.org/10.1007/978-981-10-1415-4.

Najihi, S. et al. (2022) â€˜Software Testing from an Agile and Traditional viewâ€™, in Procedia Computer Science. Elsevier B.V., pp. 775â€“782. Available at: https://doi.org/10.1016/j.procs.2022.07.116.

Nanda, A., Xu, Y. and Zhang, F. (2021) â€˜How would the COVID-19 pandemic reshape retail real estate and high streets through acceleration of E-commerce and digitalization?â€™, Journal of Urban Management, 10(2), pp. 110â€“124. Available at: https://doi.org/10.1016/j.jum.2021.04.001.

Olteanu, C.G. (2018) IT Agile Transformation, Economy Informatics.

Pan, J. (1999) Software Testing. Available at: https://www.ece.cmu.edu/~koopman/des_s99/sw_testing/.

Pinzaru, F., Zbuchea, A. and Anghel, L. (2020) Crisis and Risk Management THE IMPACT OF THE COVID-19 PANDEMIC ON BUSINESS. A PRELIMINARY OVERVIEW.

SeaLights (2023) â€˜The Agile Testing Metrics You Need to Knowâ€™. Available at: https://www.sealights.io/agile-testing/testing-metrics-in-agile-development/#:~:text=The%20Running%20Tested%20Features%20(RTF.

Talby, D. et al. (2006) Agile Software Testing in a Large-Scale Project.

Victor Szalvay, by (2004) An Introduction to Agile Software Development.

Wadood, K. et al. (2022) â€˜Large-Scale Agile Transformations for Software Quality Assurance: An Empirical Case Study from Pakistanâ€™, Mathematical Problems in Engineering, 2022. Available at: https://doi.org/10.1155/2022/6153744.

Whittaker, J.A. (2000) What Is Software Testing? And Why Is It So Hard? Available at: www.mtsu.edu/~storm.