Thursday, July 26, 2018

The agile testing mind-set | SupremeAgile

To understand the agile testing mindset, we first need to determine what makes a team "agile." To me, an agile team is one that continually focuses on becoming self-organized and cross-functional to be able to complete any challenge they may face during a project. In addition (and based on the agile spirit), the team must put the customer first and ensure that at the end of each iteration the customer receives the best possible product.



In my experience, there are some aspects that differentiate "agile" teams from other teams, such as:

Continuous learning. As in any other field in life, agile team members must grow as individuals to be able to contribute to the team effort to succeed. They must learn agile practices, new technologies, tools, and technical excellence as well as master all aspects of the product.

Discipline ensures that each team member will follow the rules and guidelines of the agile manifesto and the organization (as each organization has its own rules, boundaries, and goals).

Great HR skills that will allow team members to work with one another, help in case of trouble, and most importantly, allow for team dynamics that focus on both the team and on the individual.

Embracing continual improvement that will allow the team to improve the process and product each iteration.

Sharing knowledge to promote team members who do not have the relevant skills, knowledge or experience that the team needs to complete their goals.

Trust and respect, which are fundamental aspects we want to see in any team and in agile teams in particular. Team members who do not trust and respect their co-workers will become the biggest impediment of the team. 

Now that we understand the characteristics of a great agile team, we can see that successful agile projects are the result of teams built from great people who have the freedom to utilize their skills to generate great work.  

The new tester in agile teams

Agile teams are built from both developers and testers that work together towards a common goal. (The best teams I created were built without testers at all, but this is for a more advanced article.) Now that we’ve discussed the characteristics of a great agile team, it’s time to define the same thing for testers and ask what makes someone a success as a tester on an agile team? The basic answer is that what makes a tester succeed on an agile team is usually the same characteristics that make a highly respectful tester on any other team.



An agile tester doesn't see himself as the team’s quality authority (for more information: What does it mean to be an agile tester?), protecting the customers from the programmers as he did back in the old days when he worked in a dedicated test department, usually at a separate physical location from the development teams (for more information: Testers are not the "Quality" officers in an agile team). 

For me, there is no difference between tester and developer; they are all equal and should follow the same team culture, mindset, and principles. Based on that, I can say that great testers that really succeed in agile teams are those who are willing to share their knowledge and test experience among other team members. They are willing to work hand in hand with developers and the product owner to promote the team and the overall quality of the product, using a collaborative approach that states that the entire team is responsible for quality.

Agile testers (and probably any other testers) that have the right HR skills, technical skills and mindset promote the team and themselves by providing continuous feedback about the overall quality of the product. This allows the team to see the big picture and what should be done to increase quality.

In addition, agile testers are continually searching for new ways to help the team increase their efficiency and produce high-quality products. What does it mean to search for new ways? Here are three examples:
  1. Testers can search for new technical tools that will improve the efficiency of the testing process and reduce manual efforts (such as automated frameworks that will shorten regression cycles).
  2. Testers can create local group meetings or roundtables with other teams to learn and adapt success stories that worked in their team.
  3. Testers can share their knowledge with the rest of the team to increase the quality ownership. During this process, the tester can act as a quality consultant that will help other members remove quality barriers they are unfamiliar with. 
The bottom line is that testers in agile teams should have a different mindset than the one they had in the environment of traditional software development. They must understand that their agile teammates (which include more programmers than testers) share the same goal as them. Testers should like their teammates and enjoy learning from them (especially coding skills that will help them add more value). Testers should never limit themselves to solving only quality issues.

But wait, there’s more. Agile testers should also help the team address issues that arise during the iteration and afterward, especially regarding technical aspects of the product. In addition, testers should know that the team trusts them to understand the big picture of the whole product, rather than concentrating on a specific component.

Great testers are the ones that the team rely on because they know that they have an instinct and knowledge for where and how software might fail and what solutions the team should implement to reduce the risk of failure.

But wait, I think that testers can do even more! Testers should use their expertise, knowledge, and experience in testing and help the team in other layers of the development process. A great tester isn't afraid of being involved in design discussions, giving suggestions that will improve testability and reduce future risk.


Thanks to Tally Helfgott for proofreading :) 


Linkedin Profile

Sunday, July 22, 2018

The changing role of QA managers in the Agile environment | SupremeAgile

Many questions arise when an organization starts the transformation to an Agile environment, some related to the adoption of the new Agile culture and some related to the dramatically changing organizational structure.

One area that creates confusion among managers is, of course, what is going to be their new role once the organization becomes Agile. In this post, I will focus on QA or test managers and describe the transformation from traditional QA manager. I’ll discuss new opportunities in the Agile environment while reviewing some of the most commonly asked questions, such as:
  • What is the role of the QA manager in an Agile environment?
  • Do we really need a QA manager in an Agile project? 
  • Who is responsible for ownership on quality?

A few facts on the current software industry 

Before we start, I want to mention a few major facts that will help you understand the context for this post.

Fact 1: The current challenges in the software industry are different from a few years ago. Just think about the new platforms that did not exist 10-15 years ago such as web, cloud, and mobile.

Fact 2: Agile frameworks are here to stay; we are seeing more and more companies worldwide making the transition to Agile development processes (such as Scrum and Kanban).

Fact 3: The current software industry pushes organizations to their limits, and as a result, organizations must deliver quality products fast and early to stay relevant.

Fact 4: Employees’ welfare is critical to the organization’s success. Organizations that treat their employees as resources will not be able to keep them.

Fact 5: Agile transformation affects all layers of the organization, but the role of managers (and QA managers in particular) is the one affected most.

QA managers pre-Agile

To best provide the answers to the questions above, I’ll start with a quick review on what it meant to be a QA manager in the pre-Agile world. I will review the QA manager’s role in traditional software development while focusing on the Waterfall methodology created in the early 70s. 



The management style was different…

The traditional manager’s management style is mostly based on the “Command & Control” method, defined, according to the Cambridge Dictionary, as “a situation in which managers tell employees everything that they should do, rather than allowing them to decide some things for themselves.

Here are five primary characteristics of this kind of manager:

  • Controls all major aspects of the project (timelines, pace, task assignments)
  • A strict hierarchy of authority (the manager at the top of the pyramid)
  • Micromanagement led by a lack of trust between the manager and his employees
  • Zero tolerance for mistakes made by his employees
  • Commands must be followed, or discipline is applied


The interaction between the manager and his employees is based on five phases:

Phase 1: Identification of the organizational “needs” (budget, resources, and requirements)
Phase 2: Providing employee demands, expectations, and goals
Phase 3: Employees follow the manager’s instructions without question
Phase 4: Monitoring employee progress of task completion
Phase 5: Comparing employees’ deliverables to the preliminary goals


The outcomes of “Command & Control”:

  • Employees are treated as resources and not as human beings who have their own dreams and personal goals
  • There is less room for an employee’s creativity and innovation (how can there be, as the manager provides all the instructions)
  • The manager is at the center of the team (team empowerment is less important)
  • The manager’s success is more important than the success of the team
  • Employees are unmotivated
  • Employees are less involved in high-level decision processes

More opportunities as managers 

QA managers had their own departments, groups, and teams that they could manage, depending on the hierarchy of the organization. Roles like a quality director, test group leader, and the test team leader were very common in traditional software development processes.

In addition, in the Waterfall model, testers worked together on the same team (usually at a separate physical location from the development team) which meant that QA managers managed only testers (there were no programmers on their teams).

Testing projects were challenging but had some major advantages  

Most of the QA managers who have ever worked in the Waterfall SDLC are familiar with the different challenges, disadvantages, and deficiencies of this model. However, compared to an Agile SDLC, the Waterfall model has some major advantages that helped QA managers do their job:
  • There was a dedicated testing phase that started only when the development phase was completed, which reduced the risk of multiple code modifications as occurs in an Agile environment.
  • QA managers and their teams received comprehensive requirements documentation (specs, SRS, etc.) that allowed them to see the big picture of the whole project. In Agile development, one does not use large comprehensive docs.
  • QA managers and their teams had more time to prepare comprehensive test documentation (STP, STD, and STR), which are less relevant to Agile software development.
  • QA managers had the chance to determine both the entry and exit criteria for the testing process. 

Quality ownership

In the pre-Agile era, the ownership on quality was the responsibility of QA managers. As a result, they had more power to affect the different quality aspects of the project. Let’s see some classic examples:
  • QA managers had the power to determine the defect life cycle (DLC)
  • QA managers established the quality metrics used to track different quality aspects and progress
  • QA managers chose how to manage the testing risks based on their own knowledge and experience.
  • QA managers controlled how to split and prioritize the work among their testers.
  • QA managers decided on the test coverage for the different areas of the product.

QA managers post-Agile

After we looked at the world of QA managers pre-Agile, it is time to see how Agile development methodologies changed the roles and core responsibilities of QA managers. In this part, we will review the main reasons QA managers often feel confused about their future once the organization starts an Agile transformation.

There is no such thing as test departments

As we saw earlier, back in the old days of the Waterfall development process, QA managers had their own departments, groups, and test teams. When the organization transitions to an Agile environment, there is no such thing as a pure testing department where testers, managed by a QA manager, sit together, usually at a different physical location from the development team.

Let us examine the most common Agile framework: Scrum. The Scrum framework describes three main roles: Scrum master (SM), product owner (PO) and Scrum development team. The Scrum team is self-organized (does not need managers to tell it what to do) and is composed of different engineers such as programmers, DBA, designers, and testers.
In summary:
  • In Agile, testers and programmers work together on the same team.
  • The Scrum framework does not define the role of a QA manager.
  • QA managers do not manage teams in an Agile environment.
  • There is no day-to-day management of testers (testers are integrated into the new scrum teams).

No day-to-day direct management of testers

In an Agile environment, testers are integrated into the Scrum teams, and Scrum teams are self-organized; as such, there is no need for a QA manager to manage the testers as in the traditional working environment.

Another important aspect in this regard is that the Scrum teams should be able to determine what and how to test each PBI, and therefore there is no need for a QA manager to tell them what to do during the testing effort.

There is less room for comprehensive documentation 

In an Agile environment, there is less room for comprehensive documentation, as described in the following table:
Traditional SDLC
Agile
How and when are requirements delivered?
Heavy SRS/specs that specify all the project requirements at the beginning of the project
Small user stories that describe a small requirement. Not all stories are written at the beginning
Test documentation
QA managers and their teams create two main documents: Software Test Plan (STP) and Software Test Design (STD), which specify all aspects of the testing project (test environment, test strategy, risks, etc.)
All tests are written at the PBI level, and there is less room (if any) for traditional test documentation.



Quality is everyone’s responsibility

As we saw earlier, in the pre-Agile world, QA managers mainly held the accountability on quality. As the leaders of the test departments, QA managers were known as the main focal point for all quality issues that were found during the SDLC and for defects found in customer environments. In Agile, QA managers are not the quality officers anymore. Scrum teams are now accountable for the quality of their deliverables as a group and not as individuals.

Let’s take one classic example of a defect found in a production environment. In a traditional SDLC,` the QA manager was the one responsible to provide answers on why his team failed to find this issue and what mitigation plan he has to ensure that similar defects will not occur. Now, in an Agile environment, a similar issue is handled differently. Once the defect is discovered, the entire Scrum team (or specific people in the team) will try to understand what was missed during the iteration and how similar cases can be avoided.

This is why QA managers do not belong to Scrum teams and cannot be team members with this title. I saw many teams use this role in their team to try to keep some old habits. The direct result was that the QA managers—as team members—held the responsibility for failures of quality instead of letting the team take responsibility and grow from it. 

Progress and monitoring

In Agile teams, there is no need for a QA manager to monitor the testing progress. The Agile framework allows the organization and any other stakeholder to see the team progress using visual boards, backlogs, and burn-down charts.

QA managers lost their ability to see the big picture of the testing project as they did in a traditional testing project. Scrum teams are now accountable for communicating and reporting their progress, providing their estimations as a mandatory part of the Agile methodology, and there is no need for a QA manager to act as an observer. 


New roles for QA managers in the Scrum framework

In Scrum, the leading Agile framework, there are three main roles, with no room for managers: development team, Scrum master, and product owner. The Scrum team is self-managed and cross-functional, so they can take responsibility for all aspects of the project, including that of delivering high-quality products. This eliminates the need for a traditional QA/Test manager. However, all three of the roles specified by the Scrum framework are available to QA managers.




QA manager -> product owner

The first option, which is less common, is QA managers who become the team’s product owner. This new role is completely different from what they did as QA managers. Although it is less common, I’ve met QA managers who become very efficient POs, and some who failed miserably.

For more information about the role of the product owner:

QA manager -> Scrum development team member

Yes, you will be amazed to know that in many cases QA managers (especially ones who managed small teams in the traditional environment) decide to become one of the members of the development team. This means that they act as equal tester/developer (depending on their technical skills) without any authority on other team members.

For more information about the role of the development team:

QA manager -> Scrum master

This is probably the most common option for QA managers. During an Agile transformation, organizations do not know how to handle this role called SM, but because this role is a valid option for a QA manager, why not keep things calm and let the QA managers do it. This allows QA managers to take a real and active part in the transformation with minimal impact to their ego.

For more information about the role of the scrum master:


What other options do QA managers have in an Agile environment?

While there are three main roles that QA managers can take in the Scrum framework, that may not be an option for some who want to keep their ability to influence more, as they did in the traditional world.

Based on my experience, I will share some other options that I see in organizations without determining if they’re right or wrong. Remember that every organization has its own needs and what fits one organization may not be suitable for another.  

Integration team manager

Organizations have multiple Agile teams, each responsible for specific features. The problem here is that there is no team that can see the big picture of the whole product.

The solution is to create an integration team that will get the deliverables of all the Scrum teams and test them as a whole using end-to-end testing. This type of team is managed by a QA manager as in the traditional working environment.

Automation team manager

Depending on the technical skills of the QA manager, in some cases, they become the manager of the team that is responsible for building the automated frameworks that Agile teams use to automate their work and processes.

Quality Consultants


This role is may be titled differently from one organization to another. The common names for this role are a technical leader and quality architect. In this role, QA managers use their vast experience in the quality field to help the new Agile teams handle all quality issues as external consultants.

QA managers in an Agile team

This is the worst thing that can happen to the organization, the team and the QA manager, but it still occurs when the organization does not know how to handle the transformation process. The organization will want to ensure that the product quality is not affected once the test department is broken down and integrated into small Agile teams.

As a result, they will want to keep their ability to affect the team by keeping the QA managers in the new Agile teams. This is a major point, so I want to add another factor to the equation and that is the organization and team maturity in Agile, AKA “Scrum Level,” as described in this simple flow chart:


Defining the role of the NEW QA manager 

As we‘ve seen, the shift from a traditional working environment to Agile will have a major impact on QA managers. QA managers can add real value to the business if they understand that they must change to remain relevant in a world that is completely different from what they used to know.

Therefore, the big question here remains what can QA managers do in an Agile environment. I will review some of the ways QA managers can add value to the business if they have the personality that allows them to make the personal transformation.  


Help build new cross-functional teams

Self-organized Agile teams are the center of the Agile concept, but this does not guarantee that they have the necessary technical skills to handle the challenges that may arise during a development project.

To ensure that Agile teams perform at the highest level, the organization must ensure that they build their Agile teams with the necessary expertise that will allow them to handle all the different challenges of a development project.

However, this is not an easy task at all. We need to remember that each Agile team has its own area of expertise. One team may focus on the user experience of the product (UX), while another team focuses on the performance and functional aspects of the software. Therefore, each team should be built with people who have the relevant knowledge and skills that will allow the team to meet the project goals.

QA managers can have a major contribution in building these teams due to their vast knowledge in testing and in the personalities of their testers. QA managers will also help testers integrate into their new teams, as well as help them understand their new responsibilities, roles, and boundaries.

Process improvement and optimization

Great QA managers should be able to allow the organization to maximize the benefits of Agile. Based on their experience and knowledge, QA managers should monitor the Agile processes and strive towards improving them.

For example, QA managers could:
  • Participate in technical meetings to see how to reduce risks
  • Help the team create functional user stories
  • Work with the PO to define DOD criteria
  • Create and implement quality standards
  • Offer suggestions that will lead to a robust development process
  • Implement new test/development practices to improve testing/coding standards

QA managers as transformation leaders

QA managers can become the leaders of or the biggest impediments to an Agile transition. An Agile transition may take several months or even years to complete. In fact, I have never seen an organization that stopped continually improving the process. During this time, there are many issues and impediments that will affect the organization’s ability to maximize the advantages of Agile.

QA managers can be the change agents of the organization by removing impediments that prevent the teams from reaching their full potential. In addition to facilitating a Scrum implementation within the organization and training their team on Scrum practices, they can:
  • Help teams acquire resources (hardware/software)
  • Remove impediments that are beyond the ability of the team
  • Create a safe environment that will increase confidence among the team
  • Motivate employees by identifying their unique motivation triggers
  • Make room for failure and use it as a growth engine for the team
  • Promote continuous improvement

Promote testers’ professional development

QA manager should ensure that all Agile teams and especially their testers continue to grow as quality owners. By being the quality expert, the classic work of a QA manager is to ensure that testers continue to learn and develop even when divided among the different teams.

QA managers should provide technical lessons about quality practices, support testers in times of crises, mentor testers on how to perform their jobs in a new environment and ensure that they do not lose their identity. 

Lay the ground rules for testing cross-organization

QA managers do not have any authority over the Agile teams and especially not on the testers that may be under their direct management prior to shifting to Agile. QA managers will have to learn to let Agile teams grow in their path to becoming self-organized, independent and strong teams.

However, this is not anarchy; if in the past there were two main departments (QA and development) now we have tens and even hundreds of new Agile teams that are self-managed. To allow the business to ensure that all the teams are keeping to the same quality standards as they do in the traditional environment, there must be clear guidelines and ground rules that all teams must follow.

This is where the QA manager can help and use his experience, knowledge and technical excellence to set specific quality guidelines. The guidelines may include what testing methods the teams should use, testing tools, automation strategies, testing standards and the overall test methodologies to apply.

Cross-functional testing

In an organization of multiple Agile teams, each team is usually focused on their own feature without knowing what other teams are doing. This means that each Agile team will develop, test and deliver an incremental working functionality at the end of each iteration.

The approach that each Agile team is responsible for a specific part of the project has many advantages but still one major problem. The problem arises when there is no one who sees the big picture and how all teams’ deliverables are integrated into one complete product.

QA managers (or any other new title) have the capability to perform cross-functional testing (AKA end-to-end testing) to ensure that the integration between teams works well as a whole product.

In addition, QA managers can provide insights into the overall product quality based on their test results and this is one major responsibility.

The authority for all quality issues

It is hugely important that the business has an authority who can quickly resolve all quality issues that may arise during the Agile development process. QA managers are the best candidates to take this role and act as the quality focal point of the organization. As part of this role, QA managers will hold the following responsibilities:
  • Act as the point of contact for all quality issues
  • Mitigate quality issues that arise during retrospectives
  • Mitigate all quality issues that arise from lack of communication
  • Provide quick feedback on the quality of the team deliverables
  • Resolve conflicts that related to the defect life cycle (DLC)
  • Create learning sessions on technical gaps

Set the quality metrics

One thing that is very common among organizations that started an Agile transformation is the fear of downgrading the quality of their deliverables. This is a very logical fear because the quality ownership that was under the direct responsibility of the QA manager is now spread among the multiple Agile teams.

To overcome this fear, the organization should ensure that it has the right quality KPIs, which will provide the crucial ability to measure the major quality aspects of an Agile working environment.

This is where QA managers help the business by defining the quality KPIs and trends among the different teams. Let us review some classic examples:
  • The number of bugs and their severity per iteration
  • Team velocity compared to team capacity
  • How many stories meet the DOD
  • Defects found in production/customer environment
  • Time to market
  • Number of effective meetings
  • Defects found due to miscommunication between teams
Quality metrics have another great advantage: they allow the organization to identify the weakest and most problematic areas in the process and make the necessary changes to ensure that they meet the quality standards.

Thanks to Tally Helfgott for proofreading :) 

Linkedin Profile

Sunday, July 8, 2018

Why automate tests in an agile environment | Supreme Agile

Agile teams will fail if they don’t use frameworks to automate different aspects of the development, such as tests, builds, test environments, and so on. To understand why a lack of automation causes failure, we first need to know that the main focus of all agile teams is to successfully deliver real value to the customer, which can be translated into delivering working software at the end of the sprint (in other words, short releases in a fast-changing environment).

To achieve this goal, an agile team should be able to test their deliverables often, quickly and with great coverage. In this article, I will review some of the most common reasons that agile teams have to achieve this important goal and the challenges they face.



Why automate?

There are multiple reasons why agile teams will want to automate their tests besides the knowledge that everyone else is doing it, including the following:

Manual testing takes too long

This is the most basic reason for an agile team to automate their tests. Manual testing and long regressions simply take too long to complete in an environment that does not provide the same testing time as traditional software development methodologies (such as the waterfall model).

As an application gets bigger and more complex over time, the test matrix grows longer and longer, and the team will not have time during the sprint to manually complete the regression tests needed to guarantee they meet the highest quality standards.

Running a full regression suite during a sprint is just an incorrect practice in an agile environment. You simply cannot do it with manual execution. If your current practices do not contain any automation coverage, don’t let that stop you from starting now.

Manual testing leads to technical debt  

If you execute your regression testing manually, you already know that it takes a huge amount of time that you simply do not have in an average of two weeks of work. In addition, it is common practice for agile teams to run regressions every day, every iteration (which does not make any sense to do manually).

If your regression tests are executed manually, it will not allow the team to keep pace with coding. Then programmers have to free up their time to help with the testing, which leads to technical debt and increases frustration among the team.

Automation techniques improve team knowledge

Automation can allow the team to get a better understanding of the product architecture. Using advanced techniques such as Test-Driven Development (TDD), where code tests are written prior to the actual code, allows programmers to gain a deeper understanding of the requirements, design, and architecture of the product.

Automated tests provide fast, early and frequent feedback

If there is no change in the automated test script, we can expect it to pass until the functionality of the application is changed. When a programmer modifies the application code, he also needs to maintain the automated tests to accommodate them.

If the programmer changed the automated script to support the code changes, and automated tests still fail unexpectedly, a regression bug may have been produced by the code modification. This is a great indicator of the efficiency of the automated test design.

Another thing we need to know is that when the team runs an automated suite of tests for all new and modified code that is checked in, this ensures that regression defects will be caught at an early stage. Bugs caught early are cheaper to fix and will not add major risk in advanced phases of the development process.

Now, what does it mean to receive quick feedback from the automated tests? The main thing here is that once the defect is found early (a matter of minutes to hours from the time that the programmer adds the code), the change is still fresh in the programmer’s mind and thus will be easier to troubleshoot than if it was found days later, during the manual testing process.


Automation as a key factor for continual stable builds  

Due to the nature of agile development, it is hugely important that the team not spend their already limited time on unwanted problems such as partial or corrupted builds that will prevent the team from finishing their work.

Partial or corrupted builds are one of the top time consumers during agile development. There is no way that the team will succeed in delivering their commitments without having an automated CI/CD system that will allow the team to have continual stable builds throughout the iteration.

Automation will help free up the team’s time

The creation of test automation takes time, and of course, there is more time spent on maintenance, but once the team succeeds in creating the greater portion of this system, it will reduce the time they used to spend on executing manual test scripts, running numerous repeatable tests and endless manual regression cycles.

Now that the team has reliable automation that can replace the manual execution of regression cycles, the team will have the energy and time to focus on new test scenarios and learning more about the product and how it works, which increases the overall quality of the team deliverables.

Automated regression tests as a safety net

Knowing that the code has sufficient test coverage by automated regression tests gives the team a great amount of confidence while modifying or adding new code. This confidence is not a small thing in the agile development process where new code is checked-in and tested on a daily basis.

Automated regression tests will provide the team with a safety net that will help them find unexpected defects caused by the newly added or modified code within a matter of minutes (for unit, component, and integration-level tests) or hours (if at a higher functional level, such as system or end-to-end tests).

Now, if the team fails to invest their time in building a solid automated suite of tests at all levels of the application (unit, component, integration, and system) to act as a safety net, the programmers will start to treat the testers themselves as safety nets, which will lead to "mini" waterfalls during the development process.

Teams that have good coverage from automated regression tests can work in a more reliable environment that will allow them to write their code and add it to the main branch fearlessly because they do not need to wonder how this new code will break the build and what hidden defects may arise. The tests will tell them in a very short time frame whether or not they broke anything. 

Manual processes are more vulnerable to human error

Manual processes and manual testing are more vulnerable to human error. That's just a simple fact that we can explain by saying that manual testing is a repetitive process that gets very boring for a team member who needs to follow the same testing scripts over and over again.

And when people get bored, stupid mistakes are more likely to happen, obvious bugs are overlooked, testing scripts are not executed as they were the first time, and as we know, people will cut corners to complete work when facing tight deadlines.

The simple solution is to automate all tests that contribute to the team ROI from sprint to sprint. The direct result is the reduction of human error, risk mitigation, and creating a constant development process that will increase the efficiency of the team.

I already mentioned the word consistency earlier, which is key in the agile development process. Consistency is achieved by the team once they reduce the manual processes and automate processes (testing included), which will reduce the possibility of human error because each process and test is done exactly the same way over and over again. Automated frameworks will not cut corners to achieve deadlines.


Thanks to Tally Helfgott for proofreading :) 

Linkedin Profile

My Presentations