Automation and Large Businesses: Streamlining Processes and Improving Efficiency

In today’s fast-paced business world, the need for efficiency and productivity is more significant than ever. Large businesses, in particular, are under constant pressure to deliver high-quality products and services while keeping costs low. One solution to this problem is automation. Automation can help streamline processes, reduce errors, and increase productivity, allowing large businesses to remain competitive in an increasingly crowded market.

What is Automation?
Automation refers to the use of technology to perform tasks that were once done manually. Automation can take many forms, from simple, repetitive tasks such as data entry to complex processes such as machine learning algorithms that can make predictions and decisions. Automation can be implemented in almost every area of a business, from finance to marketing to operations, and it can bring significant benefits.

Streamlining Processes
One of the main benefits of automation is the ability to streamline processes. Large businesses have many complex workflows, and the manual completion of these workflows can take a considerable amount of time. By automating these processes, businesses can save time and reduce the number of errors that occur. In a study conducted by the McKinsey Global Institute, it was found that automation could increase productivity in the manufacturing sector by up to 30% (Muro et al., 2017). This productivity boost can translate to other areas of the business as well, including customer service, supply chain management, and marketing.

Reducing Errors
Another advantage of automation is the reduction in errors. Manual processes are prone to errors, and these errors can be costly for large businesses. By automating these processes, businesses can reduce the risk of errors, saving time and money. In a study conducted by PwC, it was found that automation can reduce the error rate in finance processes by up to 50% (PwC, 2018). This reduction in errors can lead to increased customer satisfaction and improved efficiency, allowing businesses to focus on more important tasks.

Increasing Productivity
Automation can also increase productivity, allowing large businesses to get more done in less time. By automating repetitive tasks, employees can focus on more complex and valuable tasks, such as strategic planning and customer service. In a study conducted by Deloitte, it was found that automation can increase productivity in the retail sector by up to 30% (Deloitte, 2018). This increase in productivity can lead to increased revenue and profits, which is essential for large businesses that need to remain competitive in a crowded market.

In conclusion, automation can bring significant benefits to large businesses, including streamlining processes, reducing errors, and increasing productivity. These benefits can lead to increased revenue, improved efficiency, and higher customer satisfaction. As technology continues to advance, the use of automation is likely to become even more prevalent in the business world, and it is essential that large businesses adapt to these changes to remain competitive.


Deloitte. (2018). Retail in transition: How automation is transforming the industry. Retrieved from

Muro, M., Maxim, R., & Whiton, J. (2017). Jobs lost, jobs gained: What the future of work will mean for jobs, skills, and wages. Retrieved from

PwC. (2018). The hidden value of automation in finance. Retrieved from


Resources for Learning OCaml Concepts

I’m taking a software engineering course called Abstraction and Design in Computing (CSCI E-51 or CS51) this semester. The class teaches functional programming concepts using the language OCaml among other topics. One of the things that makes this a difficult class so far is the lack of online documentation and discussion of the language.

In fact, that is the reason for this post.

I wanted to provide a list of resources that I’ve found useful in learning OCaml so hopefully they are useful to others as well. I’ll continue to update this list as I find more resources.


Migrating from a Waterfall to an Agile Model of Software Development

I recently submitted the below text as a research paper for a homework assignment in my Software Testing and Test Driven Development class. The assignment called on me to react to a case study and submit my response in the form of a proposal to a manager.

Here is the situation I was tasked with responding to:

Case Study on Testing Processes and Software Development Lifecycle

You are a new manager of a team consisting of development and testing engineers at a company you just joined. Your team has been assigned to work on a high-profile IT project that is due in 2.5 months. When you meet with the business analysts for the project, they inform you that the requirements they received for the project are high-level and incomplete and they are spending more time than originally planned to fully document all the detailed requirements for the project and create functional specifications. Business analysts are in constant meetings with business stakeholders to clarify and detail the project requirements.

When you meet with the development and testing engineers for the project, they inform you they cannot really start any work without the completed functional specifications from the business analysts and that the project timeline of 2.5 months may be achievable if all functional specifications would be ready right now, but without functional specifications they cannot tell you when the project realistically can be delivered. You try to get a high-level timeline estimate from development and testing teams and end up with a 4 month delivery timeframe, instead of the original 2.5 months.

After further review of the software development lifecycle, you realize that the company is using the traditional waterfall software development lifecycle approach. Additionally, the software you are working on is considered to be “mission-critical”, which means it needs to meet high availability and reliability standards and go through a very rigorous testing process so that the rate of defects is very low once the software is in production. Your boss reminds you that a failure of this project will put the company on the front pages of the news and you certainly do not want that as your first experience leading a project at this new company.

When you discuss the current testing process with your test lead, you find out that the current testing approach consists of test engineers using functional specifications as the starting point for test strategy and test case creation. Test engineers work on test strategy and test case creation while the development team is working on design, implementation, and unit testing. When code is delivered to a testing environment, test engineers perform manual test execution, document results, and create defects for any issues found. Defects are tracked in a defect tracking system, reviewed by business analysts, assigned to developers for fixing and then retested by testers manually. Test automation is currently limited to selected test cases used for regression testing. The testing lead seems very concerned about having sufficient time to do thorough testing on the project, especially considering the high-profile of the project and business consequences of missed defects.

And my response is below:

Executive Summary

As a new manager of software engineering and test engineering teams at ABC Software, LLC, is a current project that needs immediate attention. There are many challenges facing this project:

  • Our customer has yet to provide a fully functional scope of work for the software project we are currently developing yet expect it to be delivered in 2.5 months
  • Our software engineering team cannot complete the work in the 2.5 month time frame but state that they can likely finish it in 4 months if the functional specification was delivered to them immediately
  • Our development model is the traditional waterfall method for a client that is facing changing needs
  • The software we deliver needs to meet high-availability and high-reliability quality standards and any failures of the product will gain national attention
  • Our test engineers are currently limited to selected test cases for regression testing and they are concerned about having enough time to test the software adequately to meet the projects stated availability and reliability standards

With these issues in mind, phasing in an agile development model for our business analysts, project managers, software engineers, and test engineers will be a key part of our strategy to deliver software that is built with quality in mind from the start. Migrating to an agile strategy is part of a three-prong strategy to effectively manage this project and make our technical and business staff able to deliver key objectives to customers in the future:

  • Ensure our upper-management is engaged with the client so they understand we cannot deliver software without a signed scope of work and engage with the client’s upper-management so they are aware we will be delivering subsets of functionality in 2-4 week iterations in the future.
  • Engage in activities to help our business analysts, project managers, software engineers, and test engineers why we are switching to an agile model for software development. This means making sure they are involved in the changes and understand what is expected of them.
  • Build quality into the software by having defined processes for software testing that we do not deviate from. All team members need to understand that it is their responsibility to deliver quality software, not just to do their sole task and hand it off to another individual/team.

Software Lifecycle Model

Transitioning from our traditional waterfall model to an agile model will help in delivering discreet sections of functionality to our customer while meeting our internal software quality and delivery goals. The waterfall method works for large projects where change is difficult and expensive.

The delivery and continuous integration needed this project and our future projects can better be served by utilizing an approach that can be more reactive to our customer’s changing needs. Our business analysts and project managers can work with the client to develop break down the high level functional specification that we have from then into deliverables for each 2-4 week iteration. This will give our software engineers and test engineers the information needed to perform verification and validation testing which is needed to provide the high-availability and reliability standards that our company is known for.

Feasibility of a New Lifecycle Model

Changing the current waterfall development model to agile may not be an easy transition. Changing to an agile model will be a challenge but ensuring the global development team, including business analysts and project managers, understands the change and feels empowered throughout the process will help deliver quality software while meeting the business’ goals.

Phasing in agile methodology with our current waterfall model will make the transition easier for all team members involved. This means transitioning to delivering functionality in 2-4 week iterations but keeping certain workflows that are familiar to the team members such as using the V-Model to plan the iterations and test phases.

Lessons learned meetings after each iteration that involve team members from each of the functional areas (business analysts, project managers, software engineers, test engineers, and managers) will facilitate knowledge transfer and help improve our processes for the next iteration. Constant improvement is the goal of transitioning to the agile model.

Challenges of Introducing a New Lifecycle Model

Introducing a new development lifecycle model will be a challenge, but one our team is ready for and one that will prepare us for the future as we grow as an organization. Getting the team’s mindset on-board will be one of the biggest ways that we can ensure a smooth transition because it will help the team understand how each and every member’s role is about delivering quality software. Some of the long-term challenges of agile adoption include the need for discipline, constant reinforcement of principles and goals, and the fact the people change at different rates (Abdelnour-Nocera & Sharp, 2012).

Any distractions that arise can be eased by listening to the team’s concerns and addressing them during the change or letting the specific team member know how their specific concern will be addressed so they feel empowered instead of silenced.

Training will also be provided in the development methodology as well as the specific tools that will be used during the project. Our workforce should be constantly learning and able to understand what is being asked of them. This will help us retain our current talent as well as ensure our newer hires can be valuable members of our team as they grow professionally.

As a method to facilitate the long-term strategy shift to an agile model we will train key members of the business analyst, project management, software engineering, and test engineering teams to be agile evangelists. These team members will employ a strategy of ‘embedded coaching’ (Abdelnour-Nocera & Sharp, 2012) where they teach the other members of their team the agile strategies we are putting in place in order to implement a cultural change toward agile methodologies (Abdelnour-Nocera & Sharp, 2012).

Another challenge is making sure that the software engineers and test engineers understand that out software quality standard is fixed, but the scope of each iteration is not (Samanta & Mani, 2015, pp. 135-139). This means that quality cannot be compromised. The scope of the functionality that needs to be completed within each iteration can be scaled back to provide more time for testing but code that does not meet our quality standards will not be integrated until it passes all required tests in the test execution phase of testing.

Ensuring that the middle managers are on board with the change to an agile model is key as well (Abdelnour-Nocera & Sharp, 2012). There is always the possibility that they do not share the vision (or additional work load creating stories for defects/changes) of the development team and such will blame any failures or delays on agile itself. One way to mitigate this is to bring the managers of the business analysts and project managers early in the decision-making process. Ensuring that the switch to agile is a top priority and is represented in C-level management’s project portfolio will also assist in applying the needed pressure to be able to shift towards building and releasing higher quality functionality to customers faster.

Software Engineering and Testing Best Practices


Changing to an agile development methodology will assist in delivering discreet sections of functionality to the customer. Ensuring that the test team members are empowered and treated as equals to their feature developer counterparts will help build quality into the code before the verification step.

Having a valid specification for the upcoming iterations will let the development team know what they are building and will help keep deadlines in mind when scoping out the next iteration. Having cross functional teams attend iteration planning meetings will help the team members understand the challenges that may be faced in the coming iterations. This means having experienced team members as well as newer members in the meetings so they can learn the entire process and gain the experience so the new members can become experienced members faster.


Our testing team needs to ensure unit tests cover each class and they are run automatically as code is checked in. The test engineers also need to configure our source code repository so that when code is checked into the repository there are meaningful comments so other developers do not need to read the code to understand what the checked in changes do.

We can ensure that all database scripts, configurations, external libraries, automated tests, and all related code is in the repository so replicating issues is not a large task. The test engineers and management team need to make sure that all automated tests pass before releasing code to production. Our test engineers also need to work closely with the SWE and BA for the verification testing.

Testing Tools

Our test engineers and software engineers will use the appropriate Unit Testing Framework, such as PHPUnit, to run unit tests of the software to ensure as complete code coverage via tests as possible. The software engineers will write their own unit tests to cover discreet functions and methods from their code. The test engineers will test higher level frameworks and classes to validate their functions, ensure that their interfaces work as expected, and perform regression testing.

Depending on the operating system in place, we will use tools like Puppet for operating system configuration management. Using Puppet will allow us to have a variety of servers for testing, development, staging, and production and ensure they are all configured appropriately. Other tools such as Vagrant will help individual software engineers spin up a new virtual machine with the base operating system and automatically run the Puppet configuration script so the developers do not need to worry about making changes or writing bad code on the virtual machine. With one command, the developer should be able to get back to a baseline system and deploy their code to it.

Our test engineers will use front-end automated testing tools like Selenium for automated user interface testing. This will be useful for testing how large amounts of the codebase interact with each other from a user’s perspective.

Testing Phases

During the iteration planning process, we will need to focus on 6 main testing phases (Bartlett 2016):

  1. Requirements Analysis
  2. Test Planning
  3. Test Case Development
  4. System Environment
  5. Test Execution
  6. Test Reporting

The requirements analysis phase is where the test engineers, software engineers, project managers, and business analysts meet to discuss what is testable in the iteration after reviewing the scope of work and functional specifications.

The test planning phase will involve the test engineers, software engineers, and the manager of development operations. This is when the test plan is developed and each team member understands what they are responsible for testing. The manager of development operations is involved due to their experience with testing software systems so they can provide any needed insights to the team to ensure that all of the needed functionality is in the test plan.

The test case development phase details how to test the application and involves team members from the test engineers and the software engineers.

The test cases should guide each tester through the testing process including any data or external interfaces (stubs or mocks) needed to adequately test a particular section of code or functionality. Employing a higher number of tests and test cases has been correlated with a higher baseline quality and productivity for developers and test engineers (Fucci & Turham, 2014), so ensuring an adequate number of tests covers the codebase is key. The knowledge and experience of management, the software engineers, and test engineers will assist in achieving this goal without the need for arbitrary “x number of tests per line of code” goals that can tend to demoralize team members.

The system environment phase details the environment the software will be running in or tested in. Team members from the business analyst, test engineer, and software engineer teams should be represented while working on this phase. Testing should occur in environments as similar to production as possible. All configuration changes should be logged in a central repository and any configuration scripts should be stored in the code repository.

The test execution phase is when the test engineers and software engineers execute the test plan and log the results of each test. It is important notate whether each test passes, fails, or was skipped. If a test fails the results of what the software did needs to be documented along with the expected output. If a test is skipped it is important to document why it was skipped so it can be reviewed to see if it is necessary to be included in the next iteration’s test plan. The results of the test execution phase are gathered and compiled into the output of the test reporting phase.

The test reporting phase involves any person that ran a test to provide a summary of the pass/fail/skip status including details of the tests to the manager of development operations. The manager will review to ensure all necessary testing has been completed and will conduct a meeting with representatives from the business analyst, project management, software engineering, and test engineering teams to develop a ‘lessons learned’ document in the development and testing process of the current iteration. In the meeting insight from the customer base and project management teams for any insights to how we can improve processes during future iterations.

Discovery of Business Requirements

The agile model will help assist us with the client’s inability to provide lower level functional requirements. Our managing directors or C-level management will need to have talks with the client’s business in order to get the high level functional specification signed off as a scope of work. We then can work on getting functional specifications for each iteration completed. Our upper management also may need to stay engaged with their counterparts in the customer’s business in order to ensure that we are not only maintaining the level of service that the customer expects, but to keep them engaged and able to provide us the information needed to start each iteration on time.

Breaking up the project in discreet sections of functionality in each iteration will help by focusing the customer on what they need from smaller sub sections of the entire application. This will prevent them from potentially causing delays by attempting to over-think their needs based on the entire large software project. Our upper management will help the process by working to the customer’s business and letting them know that there are delays on the customer’s end that they may be able to break through to deliver results.

Timeline Negotiation

The project likely cannot be finished in 2.5 months because we do not have a signed scope of work document or project charter that is well defined from the client. Acknowledging that we attempted to work with the client and started development before the scope of work was completed which was outside of our normal business practices but we cannot honor our given deadline as the scope of the project continues to change.

Alerting the client that we can work on their project and deliver functionality to their users sooner with our changes to the way we manage their project will inspire goodwill. The change will also allow us to alleviate the pressure from their staff from needing to gather requirements from the entire system internally to deliver the functional specification to us at once and allow them to focus their efforts while being more reactive to change.

Activating the highest levels of our management team to reach out to the client’s business to explain the situation and get a scope of work signed off on will allow us to complete the project in the 4-month time frame. The client will be happier to know that they will start getting software features delivered sooner and that our development teams will be responsive to any changes that need to occur and changes can be implemented within 2-4 weeks.

Starting a media campaign involving blog posts, social media posts, videos on media platforms, as well as having our external client facing reps alerting their contacts touting our business’ development strategies.  We can also focus on how we are innovating in the software development and testing fields will help bring a sense of understanding when media reports come out regarding the software being delayed. A preemptive media campaign can also allow us to shape the message that we are delivering features of the software package before the initial 2.5-month timeline even though the initial timeline was for the entire software package to be delivered then.

Our focus is on delivering quality software with high reliability and high availability. While continuing on with our current strategies would allow us to complete the tasks needed, changing our software development method will allow us to be more responsive to our customer’s needs, build quality into the software development process, and have a more engaged team that shares values and information.

Works Cited

Bartlett, J. (2016, August 02). Software Testing Life Cycle Phases (STLC). Retrieved September 17, 2017, from

Samanta, U., & Mani, V. S. (2015). Successfully transforming to Lean by changing the mindset in a global product development team. 2015 IEEE 10th International Conference on Global Software Engineering, 135-139. doi:10.1109/ICGSE.2015.17

Fucci, D., & Turham, B. (2014). On the role of tests in test-driven development: a differentiated and partial replication. Empirical Software Engineering, 277-302. doi: 10.1007/s10664-013-9259-7

Abdelnour-Nocera, J., & Sharp, H. (2012). Understanding Con icts in Agile Adoption through Technological Frames. International Journal of Sociotechnology and Knowledge Development, 29-45. doi:10.4018/jskd.2012040104


V-Model for Agile Software Development

The V-Model is a software development and testing model which highlights the need to plan and prepare for testing early in the development process (Watkins & Mills, 2011). It does this by listing the traditional waterfall development phases on the left-hand side of the “V” and lists the corresponding test phases on the right-hand side. Planning can begin for a testing phase once the corresponding traditional waterfall stage has been completed.

(“V-Model and Agile Methodology”, 2017)

Waterfall development treats analysis, design, coding, and testing as discreet phases in a software project (“Agile vs Waterfall”, 2017). Each phase of planning corresponds to a testing phase in the V model. An Agile development strategy treats these activities as activities that happen throughout the development cycle. Each of the steps of the development cycle still occur but deliver smaller sections of functionality to end-users in iterations that typically last between two and four weeks as opposed to 6+ months.

The V Model can be adapted for an Agile team by considering each two to four-week iteration a complete Waterfall cycle. This may seem more like work due to needing to perform the same planning steps every iteration but because the scope of the work is smaller it should be manageable.

Using the V Model for software development can be useful for teams that are migrating from a Waterfall methodology to an Agile one. This way as the team becomes used to scoping and delivering smaller sections of features. Project managers and business analysts can retain their familiar tools for project planning while feature developers and test engineers understand the new development process.

Works Cited

V-Model and Agile Methodology. (n.d.). Retrieved September 14, 2017, from

Watkins, J., & Mills, S. (2011). Testing IT: an off-the-shelf software testing process. New York: Cambridge University Press.

Agile vs Waterfall. (n.d.). Retrieved September 14, 2017, from


Transforming to a Lean Methodology by Changing Team Member Mindset

I recently came across a paper entitled “Successfully transforming to Lean by changing the mindset in a global product development team” in the 2015 IEEE 10th International Conference on Global Software Engineering while preparing for one of my homework assignments. I thought the topic of the paper was interesting because most of what I have focused on up to now is technical and less management oriented. The paper focuses on how a large distributed group at Siemens Technology and Services Pvt. Ltd. struggled implementing a new operating methodology and how they improved their Lean processes by changing the mindset of their teams as opposed to just changing the team’s internal processes. The tools and techniques in the paper can be used to adopt any new operating methodology such as an Agile or Scrum.

Samanta and Mani, the authors of the article, estimate that effective enablement of Lean methodology depends 80 percent on culture and mindset, and only 20 percent on processes (Samanta & Mani, 2015, pp. 135-139). At the beginning of their process they decided to complete a small 3 month project with the Lean method. The project was successful so they implemented the changes across their global development team. After two years of the implementation they found that they gained several efficiencies and improved communication but they could not regularly have usable features completely finished on each takt (similar to a sprint in Agile).

After recognizing how adopting a Lean mindset could benefit the team, the managers decided to talk to the team members to identify what problems were limiting them with regard to the core principals (Samanta & Mani, 2015, pp. 135-139). The takt team speakers, Lean coaches, and senior management decided that they faced 6 challenges and took actions to overcome those challenges.

  • Employee empowerment
    • Challenge: They identified four items related to employee empowerment, but the most important is that team every team member had to feel empowered to raise a red flag when they see show-stopping problems arise as well as management had to learn to respect that red flags were raised for valid reasons and work to resolve the issue(s)
    • Action: Processes to escalate red flag issues; intensified training to ensure the processes as whole were understood as well as each team members individual role
  • Continuous improvement
    • Challenge: Changing mindset from ‘responsibility for a component’ to ‘responsibility for the whole product’
    • Action: Defect analysis involved cross-functional teams that allowed team members to understand the entire process, from the client’s workflows to development and systems engineering’s challenges
  • Quality is not variable, scope of each takt is
    • Challenge: Needed to understand that quality is not variable, scope of the work in each takt is variable
    • Action: Quality gates to ensure only code with acceptable quality is integrated into the system
  • Quality, Cost, Delivery
    • Challenge: Ensure each team member is aware of their role and responsibilities so they are fully accountable for the work they committed to in each takt
    • Action: Takt teams were given end-to-end responsibility for features
  • Synchronized processes
    • Challenge: Feeling accountable to synchronize their current status continually to keep everyone aware of the status
    • Action: Automation to ensure continuous integration; Status calls involved all key stakeholders to ensure synchronization at all levels
  • Usable software after teach takt
    • Challenge: Understanding that at the end of each iteration, all the committed results had to be integrated, tested and ready to release
    • Action: Competence in writing smaller user stories that could be implemented, tested, and delivered in a single takt by applying usage-centered design

(Samanta & Mani, 2015, pp. 135-139)

I would suggest reviewing the article in the journal to find more in depth actions that the management team took to implement Lean strategies to their team. After reading the article I understand that any change in the operations should have the employee’s mindset on board before implementing the changes themselves.

In the past I have had managers explain that organizational change is difficult, even if the change creates more efficient workflows. It was interesting to be involved in planning a technology change and seeing the feedback/pushback even though the change in question resulted in eliminating the need to remember an extra password. Now I can understand that the changes could be communicated differently and input can be requested from the team to find any limiting beliefs that may be underlying that causes friction with the change.

Works Cited

Samanta, U., & Mani, V. S. (2015). Successfully transforming to Lean by changing the mindset in a global product development team. 2015 IEEE 10th International Conference on Global Software Engineering, 135-139. doi:10.1109/ICGSE.2015.17


Google’s Test-Driven Development Process

Google has innovated a testing strategy that is different than the traditional testing approach seen at other companies. This new approach comes with benefits and drawbacks that need to be managed in order to effectively incorporate the testing methodologies in an organization. While Google’s approach to testing/quality can be replicated in other organizations, it may be smart to review an organization’s culture while implementing a strategy to improve software quality.

Google has a variety of differences from a traditional software organization, but the three I find most important are:

  1. They treat development and testing as the same discipline. Both of which are focused on engineering quality into software from the ground up.
  2. They divide their software developers into three distinct roles, each of which have equal development skillsets: Software Engineers (SWEs), Software Engineers in Test (SETs), and Test Engineers (TEs).
  3. And their organizational structure prioritizes testing by having a separate testing organization within Google that loans SET and TE resources to product development groups.

Quality is not the same as testing (Whittaker, Arbon, & Carollo, 2012). Google uses this mentality along with test-driven development to engineer quality software as free from defects as possible which is one of the benefits of their process. Software Developers writing their own tests ensure that the people that know the code are the ones to debug it while they are adding features. It falls on the Test Engineers to ensure that not only the features work at a high level (an end user level) but also that the features fulfill the needs of a client. Having a separate testing organization within Google helps not only ensure that the Test Engineers have a depth of knowledge across the company’s software portfolio but it helps remove the information silos. For example, a Test Engineer that works on that works on Google Chrome may transfer to the YouTube team and share their experiences and best practices with the new team so they can adopt new processes and improve their continuous integration process.

Downfalls of Google’s approach to testing include losing quality Test Engineers to other software projects in the organization. Losing a team member that provides a certain level of product knowledge could potentially cause an impact on the product. Another risk of Google’s using approach is in the implementation of the process itself. An organization needs to have quality as a key focus from C-level management down, otherwise any issues that come with change within the organization (changing daily duties, changing HR’s perception of the testing role in the organization and raise their compensation to match Software Engineers, ect). This is reminiscent of what Patrick Copeland’s struggle to implement change to his feature developer and testing teams receiving push-back from the engineers who had their own personal concerns with changes to the day-to-day operations (Whittaker, Arbon, & Carollo, 2012). He was able to overcome the challenge in order to develop Google’s current testing practices that student’s study to this day.

While Google’s exact testing approach can be copied to other organizations it is important to remember that not every organization is the same. It is likely a better strategy to learn Google’s process and how to best incorporate certain features of their approach to one’s own organization.

Works Cited

Whittaker, J., Arbon, J., & Carollo, J. (2012). How Google Tests Software. Upper Saddle River, NJ, USA: Addison-Wesley.


Tolerability of Software Defects Across Industries

When analyzing software testing/bug tracking through a Priority/Severity matrix the same defect can be categorized differently depending on the industry and product of the project (Nadig, 2017). While different organizations might use different terms or levels of classification, the terms here will be defined in four categories. In this post, I will take a look at the definitions of labels used for defects and some examples across industry.

Priority determines how quickly the defect turnaround time must be (Nadig, 2017). Four categories that can be used to determine defect priority levels are:

  • P1 – Showstopper
  • P2 – Critical
  • P3 – Major
  • P4 – Minor

A defect’s Severity reflects how critical the defect is and what the impact of the defect is on the entire system’s functionality (Nadig, 2017). Four categories for labeling the severity of a defect are:

  • S1 – Showstopper
  • S2 – Severe
  • S3 – Moderate
  • S4 – Minor

A content-based website, such as one for MIT’s Math Department, may label accessibility and responsive design issues as P3/S4 which means it is should be fixed soon, but not if there are higher order defects to fix. A news organization like CNN may categorize a defect that causes only the first 1,000 articles to be displayed in their paginated list of articles as P3/S4 assuming the articles can still be found via searching their site. The older articles are less likely to be browsed to and they likely do not bring in as much ad revenue as more recent and timely articles so they do not represent a threat/risk to management.

On the other hand, MIT’s Math Department may consider a typo in a professor’s name, title, or credentials to be a P1/S2 since not only the internal faculty would not be happy about the issue, but their site is one way that they drive funding to the organization as a whole and in the organization’s eyes typos/not correctly advertising their faculty’s experience can hamper their efforts. CNN may classify a misconfiguration that causes their SSL certificate to appear as invalid to be a P1/S1 defect because the issue can lower a site’s PageRank score and lower the results in search engine listings causing revenue loss.

A tolerable (P3/P4 and S3/S4) defect for a financial website may be a website styling issue or responsive design. A credit union account I have has a non-responsive website and iOS app that displays all of my account information but none of the text is aligned and it is just a poor experience.  These are obviously things that should be fixed but the main function of the site and app are to convey my account information on demand which is why I still use them. A tolerable defect for tax preparation software may be a functionality issue where the user needs to click the ‘Next’ button twice to progress to the next step in the process. The user would likely expect to need to click a button once, but the software can still generate correct returns so it is not a showstopper.

If a financial website for a credit union could only accept a maximum 10 concurrent connections that could be considered a P1/S1 defect. An issue like this should not only be under automated testing, but it may stem from the development environment not being tested in a similar environment to production. To mitigate this, all configuration and deployment scripts should be kept in the source code management and optimally systems would be configured with tools such as Puppet to ensure testing environments were similar to production.

A medical device maker may consider an issue where the unit does not turn itself off after use a P4/S3 defect because it does not halt the use or usefulness of the product. A showstopper defect could be one that causes the device to function normally but not provide any output to the end user, definitely a P1/S1 defect. A defect of this caliber would render the device essentially useless, such as the recent string of smart lock and smart TV devices where silent firmware updates caused the main feature of the devices to stop functioning which enraged the end users.

A car navigation system may have a tolerable defect of not being able to show a user’s saved home address as hopefully the user will be able to remember their address to enter it manually if needed. This may be a more critical issue if a company finds that many of their end users are actually using this feature in an unexpected way. This would also be a good opportunity to document how users are currently using the feature and prioritize its implementation with their software engineering team. An example of a showstopper for a car navigation system would be one that prevents spoken audio from playing turn-by-turn navigation because this is a safety feature that prevents users from needing to take their eyes off the road.

Works Cited

Nadig, S. (2017, April 17). How to Set Defect Severity and Priority: Defect Triage Process. Retrieved August 28, 2017, from Software Testing Help: