Technology and Collaboration in the Workplace

Collaboration is a top priority for many organizations and business leaders. At Optimus, collaboration is integral to office culture and how we evolve and stay flexible. Collaboration within the workplace elevates the group as a whole. We are better able to solve problems and serve our clients by incorporating technology into our collaborative practices

Open Communication

Every desk in the Noida office is in an open work-space which provides easy communication between all members of a team. This helps facilitate the daily huddles that happen between team leads and their members. Firstly, a detailed plan executes all tasks. Following that, each individual takes responsibility for their sections and logs their efforts. A retrospective meeting addresses what can be improved. 

office-300x171 Technology and Collaboration in the Workplace

The Optimus team collaborating in the office

Our two offices have weekly check-ins to maintain clear communication of projects and keep up to date on their status. Leads of test and development meet to converse on the status of projects, and what challenges need to be addressed. Furthermore, clients are kept up to date through weekly status reports which analyze what work has been completed, where efforts were directed for the week, along with dependencies for the clients to act upon. 

Collaboration Across Time Zones and Platforms

Optimus Information uses technology to come together and spread information across a multitude of platforms. For instance, internally you can see birthday messages posted on Google Plus, schedule a meeting overseas through Zoom, keep up to date with your colleagues through Slack, and track your metrics on Zoho. Moreover, the use of Azure boards provides lucidity in work. A ticketing system assigns a ticket to each collaborator amongst the projects.

Through this common board, collaborators can see which tickets are assigned to whom, and what the progress is on each task. As a result, allocating tickets is based on individual capacity along with how many projects they are working on. In addition to filters, there are separate boards per project. These boards optimize differentiation and keep an organized way of merging a multitude of channels. Technology and collaboration in the workplace happen homogeneously. To reach overseas, Zoom ensures all calls are easily accessible. This allows for the Vancouver and Noida office to have a seamless partnership.

cafe-300x225 Technology and Collaboration in the Workplace

Daily huddles keep our teams up to date on each project

Technology is constantly evolving. In order for a company to remain at the forefront of the industry, information must be accurate and up to date. Collaboration allows for knowledge to be shared, cultivating a culture of continuous learning. Optimus utilizes technology to pass forward the information efficiently. Each individual has their own strengths, and by combining their unique standpoints it accelerates the achievement of common goals. 

Technology is Becoming the Core to Every Business

By Goran Kimovski, SVP Global Customer Solutions (Onica)

For many decades, technology businesses were considered a separate industry sector. These were typically companies whose revenue was dependant on developing technology-based products and selling those products to other businesses. The majority of other businesses were relegated to the role of technology consumers. Wanting to reduce their technology budgets, these technology consumers focused on minimizing their technology costs by standardizing their business processes and tools. This approach worked for a while, since everyone in their industry and market were in the same race. However, with the advent of ubiquitous technology – in the form of cloud services, mobile and edge devices – a new wave of companies emerged. These new companies shifted technology from the periphery to the core of their business model.149 Technology is Becoming the Core to Every Business

Technology Became the Differentiator

New businesses in sectors ranging from healthcare to transportation to financial services were able to compete and steal market share from existing businesses. We started using terms like fintech, healthtech, and transportation as a service to differentiate these businesses from the respective industry sector they were competing within. They almost always looked more like technology companies based on their R&D budget and technology innovation. This new wave of hybrid startups has attracted tons of investments across the globe.

Many traditional businesses have changed their direction to keep up with the competition. They had to take advantage of the same trends in cloud, mobile, and edge, to start catching up to (or in some cases outperform) their new competitors. These traditional businesses have recognized that these new businesses are using technology to differentiate themselves and grabbing market share from them. Some have been able to successfully change their direction and take their competition. Many found new solutions for their customers by partnering with these new vendors. Some have decided to acquire these businesses and bring them into the core of their operations. This effectively started a transformation towards becoming more and more technology oriented.

What Drives This Process?

Several technology innovations:

  1. Open and fast internet access
  2. Adoption of mobile in every aspect of our business and professional lives
  3. Extensive processing and sensor technology being built in every device
  4. Low cost and easy access to large computing power in the form of cloud

Screen-Shot-2019-05-14-at-11.14.03-AM Technology is Becoming the Core to Every Business

These innovations have converged and democratized access to technology. This enabled new business models like “everything as a service” to thrive. As businesses adopt more technology, they create a greater wealth of data and many new integration possibilities.

In turn, this drives innovation to:

  1. Make sense of all the data
  2. Help businesses drive better decisions and optimize the user experience
  3. Offer new ways for users to obtain services from their business
  4. Create additional revenue generating opportunities uniquely enabled by technology

What Does this Mean for Your Business?

If you’re not already on the path of transforming towards a technology-centric future, now is the best time to start.

This is how you can begin:

  1. Starting the Discussion
    Initiating discussions with your leadership (or, if you’re an executive, by leading such discussions) about making an initial investment.
  2. Create a Team
    Empower a small team to start experimenting with technology and exploring how to solve current business challenges in a different way using cloud-based or related technologies. It is critical that you truly empower the team to try different technologies. Give them a budget and authority for creating a sandbox with enough guardrails and support from your IT and security teams to enable them to safely run experiments fast. It is equally critical to hold them accountable for their learning and sharing the results of their experiments. Therefore, you can build a roadmap for transforming your business through the use of technology and get wider support from the organization to continue further investments.

If you’ve started the transformation and feel overwhelmed, you’re not alone. The technology driving the trends discussed here is largely developed for builders. These are companies that employ engineers and others that have the skill and know-how to build solutions from various technology components. However, many of the businesses outside the technology sector employ people that are good at customizing and managing solutions who don’t have the capacity to maintain their existing technology stacks.

Learning the New Model

Customization, integration, and maintenance is commonly outsourced to professional services or managed services firms. In addition, most of those firms are too invested in their existing technology platforms and unable to move as fast as their customers who feel the pressure of the market. They need to adopt new technologies faster than their vendors can. This leaves room for a new kind of service firms (Optimus Information and Onica included) that have been born in the new technology-centric world. These new service firms are not constrained by old business models or large numbers of customers with support agreements that keep their staff working with outdated technologies. These companies are more than happy to share the best practices they have developed over the years working with early adopters of technologies like cloud, IoT, serverless, Big Data, Machine Learning, etc. Larger enterprises are also great examples of this new model. Many have already started their journeys and have been relying on those new technology-centric services organizations to help.

Technology Transformation Trend

It is somewhat useful to think of all of these trends as enabling a transformation towards technology-enabled businesses. However, in my 6+ years offering cloud consulting and managed services in Canada and the US, I have often seen this trend of technology becoming central to the business. These businesses are on the path to becoming or have already become technology-centric; and many aspects of their organizations have been transforming to support that. I expect this trend to continue over the next 10 years. I predict that we will find ourselves in a world where almost every business will become technology-centric.

DevOps: Embrace the Culture and Speed App Development and Deployment

The past decade has seen some tectonic shifts in how application software is developed and deployed.

Traditional waterfall methods, which siloed teams and produced apps that mostly worked well (until they didn’t), gave birth to Agile, a fresh new way of including the various design, development and production teams in a holistic way while creating a lean operational approach.

iStock-607969272 DevOps: Embrace the Culture and Speed App Development and Deployment


Going Further with DevOps

While Agile spelled out a new, far more efficient way for teams – and clients – to work together to produce an app, DevOps goes one step further1. It recognizes that development and operations teams must also work efficiently with each other, because the full end-to-end life-cycle of creating, testing, rolling out and improvement are inextricably linked. A well-integrated DevOps environment can deliver the highest customer experience levels.

It’s all about evolution, and Optimus Information has embraced the concept of DevOps, putting it into practice earlier this year.


Taking a New Approach to Project Development

“Lean” was pioneered by Toyota in Japan at the end of the Second World War, where its principles of reducing waste and Continuous Improvement have influenced software development methods.

Khushbu Garg, Optimus’s Senior Technical Lead at the company’s office in Noida, southwest of New Delhi, refers to DevOps as a culture. It’s a way of approaching and working a project, she says, and should be the path that every new organization should follow.

“By ‘new organization’,  I mean a new company trying to make a name for itself to attract customers. The only way to do this is to deliver fast, with A+ quality in the work. You want to gain the trust of your customers and this is the only way to do it,” she explained.

The net result of using the DevOps approach, she says, is a significant increase in the speed of development, delivery and deployment time while dealing with issues and scaling up the application.


The Five Stages in the DevOps Process

Organizations, new or otherwise, can’t simply plunge into DevOps and expect it to work straight out of the box. There is a process that must be followed before success can be achieved.

It begins with delineating the stages:

  • Define your business logic and plan around that.
  • How will you build the solution, where will you place the coding, where will you put the configuration?
  • This is where you ensure the quality of the build through regression testing, acceptance testing, etc.
  • Package the app, release it and configure it.
  • Monitor, to be certain the app remains functional.

DevOps is not an outgrowth of the Agile methodology; it stands on its own. But the two share similarities in approach. Agile allows fast development and rapid bug fixes so deployment occurs in production as soon as possible – you test fast and release fast. The DevOps approach allows this to occur smoothly, especially within the CI/CD pipeline, where automated testing using the Optimus Test Harness can pay huge dividends.


Technology Considerations of DevOps

When faced with a new project, Khushbu points out, it’s important to determine if it will be easy to implement DevOps for that project. Then, an organization needs to consider which technology will be used. At Optimus, numerous projects are running at any given time and the company makes use of a variety of technologies, both cloud-based and open source.

“Currently,” she says, “we’re using Jenkins, an open source technology. Jenkins works well for us because it supports almost all the technologies we use, like Node, Angular, C# and Java. Also, there’s no cost to Jenkins because it’s open source.”

Her team in India uses pipelines for Continuous Integration and Continuous Development because the pipeline method requires very little developer knowledge – which contributes to fast app development.

She then tasks her team with researching which technology will work best. Once the project is underway, a great deal of testing occurs smoothly with the DevOps method:  unit testing, deployment stage testing, automated testing, and so on.


The Critical Role Played by the Customer

A hallmark of Agile app development is how the client, and sometimes the customer, is involved at every point in the project. That’s no different with DevOps, Khushbu explains.

“In fact, we place great emphasis on email notification of all stakeholders whenever a stage is deployed. Even here, we get granular: how many emails we send, what information we include, what test reports are pertinent, even what template we use to convey the information and which developer is working on which stage.” The result of this care and attention to communications means the stakeholder can identify how the project is progressing and contact the appropriate developer to offer input, if needed.

By putting the DevOps culture to work, through the step-by-step process that Optimus has implemented, the client is always up to speed because of the collaboration that occurs. “We don’t need a separate IT person to deploy our builds, we don’t need IT infrastructure time, and we can quickly share a build with a customer and give the development team any feedback needed,” said Khushbu.

DevOps is as much a discipline as it is a culture. Optimus has adopted DevOps for all our projects and we’ve already seen great success with it. We know it works because it’s inclusive when it’s deployed properly.

We invite you to contact us to learn more about this evolutionary approach to app development. Our job is to stay at the leading edge of software technology and our goal is to provide our clients and customers the benefits that such technologies bring. So, get in touch with us today!

More Resources:1

Test Automation in Agile

Although both agile development and automated testing have more or less independently come into more widespread use with each passing year, it seems they were made for each other from the start. The advantages of both are derived from the same desire to increase software production efficiency overall.

Both work best when there is a high degree of collaboration between development and testing although they offer significant benefits to all project stakeholders. You often see a high usage of each approach wherever organizations are growing their continuous integration and continuous delivery capabilities.

Test Automation in Agile versus Traditional Waterfall

There certainly is no reason that teams employing waterfall methods cannot take advantage of test automation too. Typically, however, automation tends to be of lower priority in those scenarios due to the ingrained “throw it over the wall” mentality. Such a back-end loaded scenario is unfortunate because automation, especially test-driven coding, can be used quite effectively during development phases.

In agile, however, the questionable “luxury” of developers shedding testing responsibility is simply anathema to a process of two week scrums in which planning, designing, coding, testing and deployment all happen nearly at once. Without thorough development and testing automation, the productivity and quality of agile cycles would consistently fail to meet project goals.

When Automating Tests, Choose Wisely

Despite the brevity of agile development cycles, there can exist a tendency to over-automate testing. This is where careful planning and in-cycle flexibility are both necessary. Tests will naturally be categorized as to their type, whether that be functional, white box, black box, performance and so on. Within categories, however, individual test tasks need to be sorted by how likely they are to be reused repeatedly in order to optimize automation.

Any test that will be repeated more than twice, especially if it appears it will carry over to the next scrum, is a prime candidate for automation. That pretty much eliminates automation of exploratory testing and perhaps some boundary testing if the boundaries are still in flux and are not easily parameterized. On the other hand, even one-off tests might be amenable to automation in the sense that they are ongoing placeholders within an automation framework test suite for future software revisions.

Avoid Automating for Automation’s Sake

With more sophisticated test automation tools and frameworks, it is uncannily easy to become lost in the forest without seeing the trees. This is especially true of homegrown test frameworks, where the framework development effort might rival that of the applications it is meant to test. It pays at all times to bear in mind that meaningful, reusable tests must be the top priority.

An additional potential trap is not paying enough attention to the ebb and flow of value within your test suites. They naturally become cluttered with marginally valuable test scripts that may have lost relevance and eat up undue cycles of execution time. That is why it is important to set clear criteria for what does and does not get automated plus regular reviews of the test code base.

Staying One Step Ahead

Due to the rapid pace of agile development, anything to gain a leg up will pay dividends. Crisp, detailed planning is one key to getting ahead of the game, but in addition you should implement testing and its automation as early in the development cycle as possible.

The use of pair programming with one developer and one tester simultaneously working on the same code is an innovative practice in this regard. It is especially effective when combined with test-driven development in which the tester first writes the unit tests based on the specification and the developer follows with application code that turns each test “green.”

Actually, the underlying concept of first creating acceptance criteria as test code and then programming the software to make that test succeed can be applied at most points throughout the development cycle. These “live” requirements should be captured in an automated test environment that can be accessed and run by all stakeholders in the project to further increase collaboration.


Test automation is a key tool in agile development project success. As development organizations naturally evolve their entire production team from agile development to continuous integration and continuous deployment, the use of build and test automation becomes ever more critical.

Test automation in an agile development environment, however, has to be finely tuned to a greater degree than when employed in waterfall environments. Precise planning, a shift-left of testing responsibilities, keen maintenance policies and a sharp weather eye for when and when not to use automation are the most important elements for extracting the highest value from test automation.

Traditional vs Agile Software Development

The modern software development life cycle methodology can be subdivided into two types – the Traditional process and the agile process. In this post, we will look at what each of these processes are and then do a comparative analysis between them.

A software system is built in such a way that it can perform complex tasks and computations on the behest of the user. The process of building a software requires a rigorous attention to detail and a general guiding algorithm. The traditional and agile processes essentially are manifestos for software development ideologies, more than anything else. They can be further subdivided into more specific processes that form the basic plan of each unique software development life cycle. The agile methodology post-dates the traditional one in the evolution of the software development processes.

Traditional Software Development

Traditional methodologies are characterized by a sequential series of steps like requirement definition, planning, building, testing and deployment. First, the client requirements are carefully documented to the fullest extent. Then, the general architecture of the software is visualized and the actual coding commences. Then comes the various types of testing and the final deployment. The basic idea here is the detailed visualization of the finished project before the building starts, and working one’s way through to the visualized finished structure.

Agile Software Development

As its name suggests, the agile method of developing software is a lot less rigorous than the former. The crux here is incremental and iterative development, where phases of the process are revisited time and again. Agile developers recognize that software is not a large block of a structure, but an incredibly organic entity with complex moving parts interacting with each other. Thus, they give more importance to adaptability and constant compatibility testing.

Traditional Vs. Agile Methodologies

Customer Involvement

While traditional methodologies require the user to provide a detailed idea of the exact requirements with respect to the intended software, agile developers are more flexible through their iterative style of work. With agile development, the user is constantly in the loop, suggesting improvements and reviewing every phase. This increased customer involvement works on two levels – one is that it makes reflective changes easy, as opposed to traditional development where chunks of system might have to be dismantled to improve a small part, and the second being that it increases the customer satisfaction drastically.


This is a key issue. Especially the reworking costs, which tend to shoot after a bout of testing, are very low in agile computing than the traditional methods. Since testing is not compartmentalized in agile development, a potential problem can be identified and swiftly dealt with. This affects the corrective maintenance costs for the software.

Development Flexibility

Again, agile wins hands down in this category. The idea is that in traditional systems, the role of a coder and a business analyst is bifurcated. The architecture stems from the initial customer requirements collected and analyzed by the business analysts which is then developed by the coders. With agile, since the customer interaction is so extensive at every stage of development, and since the developers are the ones who are handling the interaction, the amount of architectural, functional and fiscal flexibility endowed to the project is pretty high.


One of the few areas where the agile methodology falls short as compared to the traditional one is the documentation process. Traditional development prides itself in stringent documentation and reviewal of every step in the way to deployment. The documentation process also becomes easier due to the unidirectionality of the algorithm. With agile, the primary interface of documentation and reviewal is the code itself, with annotations and comments added by developers. This can become a bit of an issue in terms of communicability.

System Size

Small to medium sized systems are perfect for agile development since they offer more compatibility to the elastic method of attack that agile brings to the table. Large software systems offer more inertia to iterative change in some respects, especially with the system design parts. In this case, one can either go for the traditional way of software development that deals with bulkier, unilateral systems with better ease and forgo the other advantages offered by agile; or one can compartmentalize the large system into smaller agile developed processes and play a compatibility gamble.

Choosing the development ideology compatible to your software is a difficult and complex decision.

Get in touch with OptimusInfo for more information on Agile and Traditional development processes. Make an informed decision with the help of our experts!

Continuous Integration, Delivery and Deployment Explained

The concepts of continuous integration, delivery and deployment arose from the shift to “small-chunk” software methodologies versus “large-chunk” processes. Waterfall development measures progress by weeks or months, whereas agile development gauges tasks in hours, days or a week at the most. Conceptually, both approaches employ a development pipeline of discrete steps from specification to coding to testing and deployment. However, the brisk, incremental pace of agile methodologies is what imparts that impression of seamless continuity.

Although the agile pipeline, observed from on high, seems to blur differences between continuous integration, delivery and deployment, they each have distinct roles. However, they share an underlying philosophy that favors incremental, stable momentum over big-bang, throw-it-over-the-wall practices. One of the fundamental characteristics of continuous software development is that task duration is short. One effect of that is a significant improvement in organizational responsiveness.

Continuous Integration

Developers tend to prefer working on code via a branch off version control’s mainline in order to reduce distractions caused by other developers’ contributions. Typically, this approach creates greater difficulty merging code back to the mainline than it saves. Continuous integration requires developers to work from a single shared code source without branching. Tasks must be well-scoped and completed in no more than a day. Integration efficiency increases, since it avoids combinatorial integration thrash due to multiple, broad changes with unforeseen side effects.

Continuous integration is greatly facilitated if an easy-to-use, automated unit test framework is included in the development environment. With such a framework, changes are thoroughly validated by the development team prior to builds and regression testing. Such a component usually resides on a dedicated server. If defects are found, they are more quickly remedied while the coding details are still fresh in the minds of developers.

Continuous Delivery

After the build/integration process, but prior to customer deployment, lies the process of continuous delivery. It includes a staging environment that emulates the final production context as nearly as possible. Achieving production conditions requires such things as identical hardware, software configurations and production data to drive tests. Within this environment, business logic tests and user acceptance tests are performed.

In a typical waterfall process, a nearly complete version of the software under development would be delivered to the staging environment every month or so. In an agile methodology, however, incremental versions are constantly delivered via the development pipeline. As in continuous integration, the impetus behind this is enabling faster turnaround time on defects whether they appear in programming or business logic. Furthermore, it facilitates early customer feedback, which in turn reduces development efforts to accommodate customer requirement modifications.

Continuous Deployment

It is improbable that your software’s customers require actual, live deployment of the software on a daily or even weekly basis. However, a fundamental principle of continuous deployment is that you could deliver software that frequently if the need arose. That characteristic is a natural disciplinary consequence of the continuous development and continuous delivery stages that precede it.

Continuous deployment lies on the same pipeline, works from the same shared code base and embodies precisely the same rapid, continuous change paradigm. It enables incremental feature introduction, measurement and early revenue generation without the burdensome overhead that would result from attempting integration, testing and releasing new features in a “whole-hog” fashion. New ideas enter the development pipeline and emerge into deployments in one or a few weeks instead of months later. Improvements can be added weekly based on real-world feedback.

The Role of Automation in Continuous Development

The success of agile methodology depends on instilling stability into the process from end to end at the start. If done correctly, the evidence is reduced development thrash, instant progress feedback and the ability to create a product that better meets customer requirements.

Automation is key to obtaining such stability, which in turn enhances the automation process itself. It is not unusual for early automation efforts to be fragmented over development, integration, delivery and deployment stages, but the ideal is a one-touch, end-to-end process that validates the stability of the project as a whole.

Overall, the operational goal of a “continuous” approach to software development is the reduction of overhead activities that slow down the implementation of new features and diminish the organization’s responsiveness to defects, changing functional requirements and market shifts. Metaphorically, it is akin to climbing a mountain slope step by step rather than spending months building a rocket-propelled sled to attain the summit in one go. At any point in a continuous process, you are able to measure your progress, adjust your route and keep both feet on the ground.

Agile and Scrum Testing Methodologies

Test teams new to Agile methodologies may find themselves in unfamiliar territory due to their fundamentally distinctive features when compared to serial processes of software development:

  • Collaboration between developers and testers is closer and more direct. Communication via documents is considered inefficient.
  • Agilists regard rapid change as inevitable and welcome. Fluid customer requirements in the quest to deliver high quality software are considered advantageous.
  • Agile development cycles or sprints are typically 10 times shorter than Waterfall cycles. Sprints last two to four weeks. This time compression is possible with test-driven development, tighter collaboration and less reliance on documentation.
  • Each sprint “post mortem” includes discussion of enhancements for the next sprint. In this way, the process itself embraces continuous improvements.

Agile Team Requirements

These features of Agile development imply substantial changes in how development and testing teams accomplish their work compared to serial methodologies:

  • All stakeholders, including business managers, architects, designers, coders, testers and QA participate in developing prioritized requirements. All must employ discipline and accountability to produce functional code by the end of each sprint.
  • Agile testers work in parallel with developers even before code is functional. Testers, are at the forefront of dynamically evolving requirements that are often represented by the tests themselves.
  • Agile works best when expertise is distributed within the teams. Reliance on specialists tends to serialize work. Thus, a tester who is expert in, say, performance testing, must be ready to pinch-hit by applying additional expertise in order to be fully effective.

Agile Development Lifecycle

Fast-paced, iterative sprints are actually sub-cycles in the overall Agile process, which consists of three higher-level phases: Inception, Construction and Transition. Depending on the phase currently in progress, testing approaches may vary. Naturally, the phases and the details of sprint execution are adaptable to an organization’s particular culture, goals, customers and resources.


Inception includes activities similar to the start of any project regardless of the overarching methodology. Resources are marshaled, responsibilities assigned, funding is secured, tools are acquired and first requirements are defined and validated by all stakeholders.


This is the phase in which core Agile methodology practices are front and center. The goal of each development iteration – the sprint – is to produce deliverable software from the requirements designated for that sprint. Work arrives from a prioritized stack of tightly scoped requirements. Testers and developers collaborate side by side throughout the sprint. Testing efforts are focus on functionality and coverage during this phase.


The move from raw software development to production code marks the beginning of the transition phase. However, nothing is “thrown over the wall” in the sense that business, programming and testing personnel must continue close collaboration as the software moves through this complex phase that includes deployment testing, compatibility testing, usability tests, performance testing, localization and the development of user documentation and training. Once this phase ends, the software should be ready for production and release.


Scrum is one flavor of Agile methodologies. Other variants include Extreme Programming, Feature-Driven Development and Adaptive Software Development. All flavors value adaptive, iterative, collaborative, and transparent development techniques.

Scrum identifies three essential roles: product owner, development team and Scrum master. The product owner is the actual end customer or an internal representative. The development team consists of those responsible for sprint deliverables. The Scrum master oversees and facilitates the entire process.

Work is pulled from a prioritized backlog of requirements on a daily basis. The Scrum master holds a Daily Scrum, during which each team member reports on the previous day’s accomplishments, the current day’s goals and any roadblocks to completing those goals. Problem-solving during the Daily Scrum is deferred to outside meetings.

Each sprint begins with a half-day Planning event followed by Daily Scrums and Review and Retrospective meetings to close the sprint. The two-hour Review focuses on presenting completed work to stakeholders, whereas the two-hour Retrospective reflects on how the next sprint can be revised based on the experiences of the last sprint.

A Test-Driven Development approach in Agile puts the test team center stage with other stakeholders. Testing trails requirements, design and coding phases in a Waterfall process. That is why testing often falls under the hatchet when a project is nearing its delivery date. Agile development ensures that the test team is continuously ahead of the curve if the methodology is correctly applied.

Agile methodologies’ greatest strength resides in its ability to handle dynamic customer requirements. While it cannot guaranteed eventual success, it is more likely than a serialized methodology to deliver quality software close to the mark with time to rebound. In today’s fast-paced software markets, it is the only approach that can keep up.

Common Challenges for Agile Testing Teams

The fact that Agile methodology has achieved mainstream status is clearly supported by anecdotal evidence and surveys, such as one by VersionOne in which 84 percent of respondents replied in the affirmative that their organization was indeed employing Agile development methods. As Agile development eclipses Waterfall methodologies for software development, it has stirred up some distinct challenges in its wake for testing organizations.

Key Aspects of Agile Development

Three key characteristics of Agile development as distinct from the Waterfall process have significant effects on testing efforts:

  • Agile compresses development time into sprints, which can run from one to several weeks each versus several months for Waterfall development.
  • Whereas Waterfall processes work in a linear fashion through requirements, design, coding, unit testing, integration testing and so on, Agile teams more or less do everything at once. Its continuous integration philosophy implies constant change throughout the development chain.
  • Thorough revision of original requirements to the point of throwing them out and starting over fresh is a not uncommon side effect of Agile processes. Since in Waterfall methodologies the requirements, architecture, coding, testing follow distinct sequential stages, each stage’s result is considered to be whole subject to relatively minor revision.

The scope of work an Agile team embraces is smaller within any single sprint, but the pace and churn is overall higher at any moment.

How Agile Challenges Testers

Requirements Churn’s Effect on Test Coverage

Since requirements and code flux steadily during a sprint, ensuring full test coverage is not always straightforward. Even with an assist from automation, testers must be nimble to avoid missing new code tests on a daily basis and to ensure that what is tested is tested thoroughly.

Test plan documentation with links from test cases to user stories helps ensure high-level coverage. Code coverage tools and source code instrumentation are both essential in demonstrating how much functional logic is tested. Additionally, there must be a system by which developers tag new source code so that it is not overlooked by the test team.

Test team members must be full participants from minute one of any sprint to provide input into the requirements from a testing point of view. The priority of requirements must account for the testability of each one within the scope of the current sprint.

Support of Daily Build Tests

Daily or semi-daily builds of the code base during a sprint is quite common. Test teams must therefore dedicate resources to preparation of solid functional and integration test suites that accurately detect breakage during and after builds. This aspect of testing benefits significantly from automation.

Additionally, the test team – via tools, scripts or pair programming – must facilitate developer unit testing before code check-ins, which substantially mitigates the time-consuming process of tracking down broken features due to cross-module dependencies or broken interfaces.

Waterfall Creep

Despite Agile’s specific rejection of linear, block processes for code development, it is natural for development and test teams to perform work in a sequential manner. This tendency results in sprints resembling mini-Waterfalls when development and test personnel are not working in parallel from a sprint’s first minute. Degradation of Agile into a linear process puts the greatest squeeze on the test team. Therefore, it is vital that testers stay tightly synchronized throughout the continuous integration process.

Squeezing out Essential Tests

Sprints by their nature demand focused prioritization from both developers and testers. When time is short, a tendency to defer certain types of testing to later sprints can result in larger problems that are harder to fix close to the time of final delivery. Pushing off performance, API, compatibility and stress testing will create a pressure cooker situation for the test team.

In this regard, Agile should borrow from Waterfall methodology the concept of an overall, all-encompassing project test plan that provides traceability of all test types. It need not be developed in toto before the first sprint, but the framework should exist from the beginning of the project. It must receive reviews and updates during each subsequent sprint to ensure test types other than functional testing are being adequately executed.

Agile methodology is proven to deliver high-quality software faster for most projects than Watefall methodologies. Agile does, however, require significant adjustments from testing teams to ensure that adequate test coverage, efficient build tests and non-functional testing are being performed effectively throughout each Agile sprint cycle. Deft use of documentation, tools, automation and innovative tracking processes can ensure quality testing is performed within a fast-paced Agile context just as it would in a Waterfall methodology.

Introduction to Agile Project Management

Agile software development was created to address inefficiencies inherent in sequential development methods, such as waterfall methodologies. Creating software with an opaque assembly line process where specification, coding and testing are separate and done in strict order struggles to keep up with fast-moving markets requirements within which modern software products must compete. In order to retain market relevance and extract the highest productivity from development and business resources, companies are ditching plan-driven software methodologies for the responsive, continuous delivery model that the Agile Method offers.

The Agile Method

The Agile Method takes into account the unpredictability of non-trivial software projects that are the bane of plan-driven methodologies. Agile software development is centered on brief, concurrent development/test cycles and close collaboration between all stakeholders.

The Agile Method acknowledges the impossibility that all project requirements are known before coding begins. Participants in a waterfall development process know this also but compensate for missing requirements by padding the schedule to account for their disruptive effect at later development stages.

Unlike plan-driven methodologies, the Agile Method is adaptive and based on iterative requirements discovery. It compresses the typical steps of the waterfall method into sprints. To build a sprint, which typically has a lifespan of a day or two, specific functional component requirements are targeted. These are coded, tested and approved or disapproved by the agile team’s product owner. Feedback is gathered after each sprint, which is used to fine-tune the next sprint.

Principles of Agile Project Management

The original Agile Methodology outlines 12 principles that are essential to meeting the objectives of continuous delivery, intimate stakeholder involvement and self-motivated contributors:

  1. Satisfy customers by continuous delivery of working software
  2. Changes in requirements are expected, planned for and embraced
  3. Useful software is delivered regularly with the shortest possible frequency
  4. Cross-functional collaboration between developers, testers, and business development owners is essential
  5. Project contributors are empowered to make decisions within an environment of trust
  6. Face-to-face communication is the preferred method for information transfer among teams
  7. Useful, working software is the fundamental measure of project progress
  8. Development must occur at a consistent, sustainable rate
  9. Technical excellence and sound design principles must be adhered to at all times
  10. Simplicity is essential in order to maximize the amount of work that is not done
  11. Teams should be self-organizing and self-managed
  12. At each iteration, teams incorporate feedback to adapt to changing circumstances

Benefits of Agile

The Agile Method is widely recognized as the best solution to the problems inherent in building software products of high quality and market relevance. Agile Methodology has a number of valuable benefits:

  • Delivery of working software is frequent and predictable.
  • The rapid, iterative nature of agile development teams means shorter time-to-market and time-to-revenue.
  • Major and minor product revisions are seamless within a continuous delivery environment.
  • Defects are found quickly and when they have the least impact to the overall schedule.
  • Stakeholders are actively engaged and progress is transparent, which leads to the highest business value.
  • The right product is delivered in the end without surprises.
  • Market relevance is achieved by a process that embraces change.
  • Motivated, decision-empowered teams are not waiting to catch what other teams throw over the wall.
  • Contributors expand skills that provide increasing value to the organization

Differences between Agile and Waterfall

  • The waterfall process works well only with fully specifiable projects. Agile has built-in requirements discovery/coding/testing iterations that deliver usable software early and often.
  • Traditional software development is control-centric, whereas agile methodology distributes responsibility.
  • Waterfall development prizes skills specialization, whereas agile contributors fulfill multiple roles.
  • Waterfall development utilizes functional silos, whereas cross-functional collaboration is the key feature in agile development.
  • Contributors are guided by planned tasks in waterfall methodology. In agile methodologies, product features guide activity at any moment in time.
  • Waterfall development engages customers at the beginning and end of the process, whereas customers are active participants throughout agile software development.

The Agile Method has become the de facto standard for competitive, nimble software development products driven by fluid market requirements. Compared to plan-driven methodologies, such as the waterfall process, the seeming informality of agile methodologies may present a challenge to the status quo, but their clear benefits outweigh these concerns in the long run.

Agile QA in Vancouver

agile_vancouver Agile QA in Vancouver

Agile Vancouver is hosting an event this month focused on Agile QA and we’re very proud to co-sponsor. The event is very exciting as Agile Vancouver consistently brings in top-notch speakers from local industry that share their trials and tribulations.

The two day event will consist of workshops, presentations, panels and open discussions on the successful (and sometimes not so successful) practical experiences of development and QA using agile methodologies.

Here are some of the discussion topics:

  • Test Automation Strategies
  • Evolving careers in Testing and QA
  • ROI on testing in an Agile environment
  • Property-based testing
  • Quality in Outsourcing
  • Performance Testing
  • Quality in the Cloud
  • DevOps approach to Quality
  • QA and Distributed Teams
  • New to Agile: Challenges and Opportunities
  • Exploratory Testing
  • Quality Measures & Metrics

For full details, visit

We hope to see you there!

If you are looking to work with an agile QA team, visit the site for our dedicated QA division, OptimusQA.

Portfolio Items


Nothing Found

Sorry, no posts matched your criteria