Cucumber is one of the most popular tools for behavior driven development testing. Cucumber enables the creation of automated behavior driven development acceptance tests leveraging the Gherkin framework. Cucumber is open-source so you don’t need to worry about paying expensive licensing fees. Cucumber testing tool is written in the Ruby programming language.
What is Behavior Driven Development?
Behavior-Driven Development (BDD) is a software development process within Agile that Cucumber was designed to support. It is one of the leading BDD testing tools on the market today.
BDD does not replace the Agile process but rather enhances the overall process.
Cucumber Testing Tool Benefits
- Testers will be able to write automated tests without needing in depth understanding of a programming language
- Cucumber supports multiple programming languages
- There is a high degree of reusable code
- Cucumber is quick and easy to setup
- Cucumber allows integration with Selenium, Watir, Spring, Ruby on Rails and many more
If you are looking for information on how to install Cucumber you can go to the main website located here. Cucumber is widely used so there are many programming languages across multiple platforms. It is always a good idea to install the one that closely matches your application. Some of the most common programming languages used with Cucumber are: Java, Ruby, PHP, Python, and Perl.
Behavior Driven Development has gained a lot of traction over the past several years with the adoption of Agile across most IT organizations. One of the most common used tools is Cucumber and it uses the Gherkin framework to automate tests. Gherkin language is defined as a business readable, domain specific language created especially for behavior descriptions. The purpose of Gherkin is to promote behavior driven development across the entire team. This includes business analysts, developers, testers, and product owners. The Gherkin framework promotes firmly written requirements and eliminate ambiguity. While Gherkin is primarily used in English, there are a total of 37 spoken languages that can be used. Gherkin serves two basic purposes: provides project documentation and helps in creating automated tests. The most commonly used automation tool for Behavior Driven Development is Cucumber.
Gherkin Language Keywords
Here are the primary Gherkin keywords:
- Example or Scenario
- Given, When, Then, And, But
- Scenario Outline or Scenario Template
Here are secondary Gherkin keywords:
- Document Strings: ” “
- Data Tables: |
- Tags: @
- Comments: #
Gherkin Syntax Example
#This is an example of how you can use the Gherkin syntax
Feature: Login functionality of Amazon
Given: I am an Amazon user
When: I enter username as username.
And I enter the password as password
Then I should be redirected to the home page of Amazon
Gherkin Best Practices
- Each feature should be executed separately
- Each scenario should be executed separately
- Leverage your scenarios with your requirements
- Make your steps modular and simple to understand
- Combine common scenarios
- Gherkin syntax is easy and simple for everyone including non-programmers to understand
- Programmers can leverage Gherkin to write automated tests
- Requirements are firm and unambiguous
- Gherkin can be used to write user stories
- You don’t need to be an expert to understand Gherkin
- Gherkin automatically links acceptance tests to automated tests
- There is significant reuse of tests
- Requires a lot of collaboration across the team and business partners
- There might be some situations where it isn’t an ideal solution
- Poorly written Gherkin will result in high test maintenance
There has been a lot of information shared over the past few years about Test Driven Development. Initially it might seem complicated and counter to logical thinking but it actually makes a lot of sense. Test Driven Development is defined as: a software development process that relies on the repetition of a very short development cycle. Requirements are turned into very specific test cases and the software is modified in order to get those tests to pass. In the normal process of software development, code is written first and then tested to make sure that it works.
What is the origin of Test Driven Development?
The origin of TDD traces back to the late 1990’s when extreme programming started. It because more mainstream when Agile came around. By 2006 it had matured and resulted in additional innovations to the process with ATDD or BDD.
What are the steps for Test Driven Development?
Here are the basis steps for TDD:
- Write a new test
- Check and make sure the test fails
- Write code to pass the test
- Verify the test passes
- Refactor code to make it more efficient
- Repeat steps again
What is the purpose of Test Driven Development?
TDD is a process of modifying code in order to pass a test which was designed prior to code being written. There is more emphasis on writing production code than designing test cases. This includes refactoring and helps to have cleaner and simpler code. It helps to find defects much sooner and eliminates the need of rework.
What is Agile Test Driven Development?
All the teams today that use Test Driven Development follow Agile or some form of it like Scrum.
Who is responsible for Test Driven Development?
Typically the person who is writing the code will be the person to write the test cases. I have seen some situations where there is a slight variation and a test engineer writes them but that is not a common practice.
What are the benefits of Test Driven Development?
- The primary benefit of TDD is that it helps to eliminate writing duplication of code
- Allows developers to capture defects much sooner in the lifecycle
- Software is better designed and results in more maintainable code
- Helps with teamwork. More people can work on code together.
- Less time is spending on debugging code
- Helps with code refactoring
- Eliminates a significant number of defects
- Often results in projects getting completed faster than original timelines
What are the pitfalls of Test Driven Development?
Here are some common pitfalls of TDD:
- Forgetting to run the tests
- Writing too many tests
- Writing tests that are too large
- Writing tests that are too simple
- Writing tests that are too complicated
Test Driven Development Skill Levels
There are different skill levels for TDD which include:
- Someone who can write a unit test prior to code creation
- Someone who can get a failing test to pass by writing code
- Someone who can write a test case for a defect that has been found
- Someone who can take a previous test driven development test and further break it down to simpler tests
- Someone who can factor reusable elements
- someone who can create a test driven development roadmap
- someone who can provide additional guidance and direction to beginner or intermediate levels
I hope this information has been helpful. You might want to also learn more about Behavior Driven Development.
There has been a lot of information published about Behavior Driven Development or BDD. It is counter to what most people are used to so it causes a lot of confusion. It is very popular and a lot of organizations have started to embrace this methodology which results in great success to those who can consistently apply some basic principles. Behavior Driven Development allows companies to shift further left and identify issues much earlier in the process than using the traditional waterfall methodology.
What is BDD?
Behavior-Driven Development is an extension of Test-Driven Development or TDD. Behavior-Driven Development is an approach to build features based upon user stories. You will typically have a product owner that will communicate the expectations for the software in form of a user story. That information will be stated in terms of business objectives or goals. Both the developer and the tester will use this information to both develop and test if these features meet the expectation of the product owner. While BDD is a process, just like any process it requires great communication between all members. What does the product owner want to see? How can that be translated into software features? Are those features really needed or are there other features that might meet business needs. Behavior-Driven Development heavily relies on communication and collaboration which are also one of the key tenants of Agile.
Behavior Driven Development premise is that the tests are written before the code is developed. In basic terms it tells you how a piece of code needs to be tested. You want to test the behavior of a given feature. It is extremely important to do this first so that you will have a high degree of testing coverage. BDD requires the person who is creating the tests to think about the business scenario. As you build code, you are building a very large repository of tests which can be executed over and over again using tools such as Jenkins. Now you might wonder if the developers are writing all these tests, why are testers needed? Well testers are needed more than ever. Developers are often focused on a small module or piece of code and don’t have an overall understanding of how the system works as a whole. Testers typically have a broader understanding and are usually business subject matter experts. It is important for testers to understand the broader context of the what and why of software and the business intended use.
Three Best Practices of BDD
- Discover: The first best practice is the most important one in my opinion. Created a shared understanding across the business and the Agile team of what the requirements are through collaboration. This is a critical step, and one that most Agile teams will overlook and rush to build tests and code. This collaboration needs to occur through structured conversations using specific rules and examples.
- Define: The second best practice is to use real world business scenarios and document how the system should behave. This documentation reinforces best practice 1 and 3. The most commonly used framework for defining scenarios is Gerkin.
- Automation: The third best practice is to automate the documentation. This will allow the documentation to grow and become dynamic. This process will verify that the system works as expected and verifies best practice 1 and 2. Most teams today use Cucumber to automate BDD tests.
BDD Framework Process
Here is a sample flow of how things work within the BDD framework:
- Create a user story with high level functionality
- Hold a requirements session and further define functionality with business examples
- Define business scenario using Gerkin
- Automate the scenario using Cucumber
- Write code so that the test scenario will pass
- Run additional tests including regression, performance, etc.
- Release code into production
I hope this information has been helpful and has provided you with some great information about Behavior Driven Development
Let’s face it, writing detailed test cases takes a lot of time and effort. As a tester, I know this is very tedious work. However, I know first hand there are some tremendous benefits that far outweigh the time involved. It certainly is not easy, but if planned out properly can be done extremely efficiently. You will probably get some push back in certain areas and using certain methodologies but it is extremely important in my opinion. Agile for example, is not in favor over detailed documentation.
Here are 7 Great Reasons to Write Detailed Test Cases
- Planning : It is important to write detailed test cases because it helps you to think through what needs to be tested. Writing detailed test cases takes planning. That planning will result in accelerating the testing timeline and identifying more defects. You need to be able to organize your testing in a way that is most optimal. Documenting all the different flows and combinations will help you identify potential areas that might otherwise be missed.
- Offshore: If you have an offshore team, you know how challenging that can be. It is really important to write everything out in detail when you communicate offshore so that everyone understands. It is critical to write detailed test cases is no different. Without those details, the offshore team will really struggle to understand what needs to be tested. Getting clarifications on a test case can often take a few days of back and forth and that is extremely time consuming and frustrating.
- Automation : If you are considering automating test cases, it is really important to have all the details documented. Automation engineers are highly technical but they might not understand all the flows of the application, especially if they have not automated that application before. Without the details, there is a high possibility that steps will get missed and perhaps that will cause the automation scripts to not be written properly.
- Performance : The performance engineers must also write performance test scripts. They also are more technical in nature, but they really struggle to get the right amount of information needed. It really helps the performance test engineers to have document test case steps so that they will be able to create their performance test scripts a lot faster.
- Audit : I have had the experience in testing applications that fall within domains which require regulatory compliance such as telecommunications and insurance. These domains require internal and external audit teams to review all testing activities. It is important to have the teams write detailed test cases so that audit will have a solid understanding of what is tested and will minimize the amount of questions that will eventually come back to the testing team.
- Development: I have found that having detailed test cases will help the development team, especially when there are defects, to provide additional guidance and direction. This helps to accelerate the fix time and thus the ability to retest and close those defects.
- Training : I have found that it is extremely helpful to have detailed test cases in order to train new testing resources. I typically will have the new employees start understanding how things work by executing the functional test cases. This will help them come up to speed a lot faster than they would be able to otherwise.
As you can see, there is valid justification to write detailed test cases. I am sure if I spend more time, I will be able to come up with another 7 great reasons. I hope this information is helpful and will encourage you to write more detailed test cases in the future.
There is no doubt that AI is Transforming Software Testing. Over the years you can see how software testing has transformed from manual testing into automated testing. It now has reached another milestone and is further transforming with the advent of AI. There are many tools today which have started incorporating AI in order to provide a high level of quality. As a software quality engineer, it is important to understand those changes and be able to evolve with the technology. If you haven’t done that yet, don’t worry since the technology is currently in a fairly infant state.
Here are several ways that AI is Transforming Software Testing
- AI will transform manual testing. Manual testing is very time consuming and expensive. AI will enable the creation of manual tests and be able to accelerate the testing timeline by running those scripts automatically.
- AI will enable testing teams to cover more scenarios and cases. This will identify more defects due to the increased amount of coverage across the application.
- AI will eliminate the need for assumptions. Software testers make a lot of assumptions when they are building and executing test cases.
- AI will help in using predictive analytics to predict customer needs. By identifying those needs this will result in a much better customer experience and customer satisfaction will greatly increase.
- AI enables visual validation. This validation will identify more defects that traditional software testing methods.
- AI will help find software bugs much faster and find more of them.
- There are several tools that incorporate AI/Machine Learning to speed up the development and maintenance of automated tests. One of those companies is Testim. Maintaining automated test cases can be very expensive and time consuming. Reducing the amount of maintenance will allow test automation engineers to focus on new automated tests and that will add a higher degree of quality to your applications.
- There are some AI tools that will complement existing tools that are on the market today. One of those tools is Test.ai. Test.ai leverages a simple Cucumber like syntax, so it greatly simplifies the development of automated scripts.
- Some tools do all the testing for you. I know that is hard to believe and I admit I am also a bit skeptical. ReTest helps to eliminate the need to be able to have programming skills. It leverages AI to fully test applications.
AI will create opportunities for software testers to move into new roles. Some of those roles will include:
AI QA Strategy: This role will use the knowledge gained within AI to understand how this technology can be applied to software testing.
AI Test Engineer: This role will combine software testing expertise along with experience in AI to develop and execute testing activities.
AI Test Data Engineer: this role will combine software testing expertise along with AI in order to understand data and leverage predictive analytics to verify information.
I strongly believe that software testing will continue to be a prominent role within IT organizations. I do believe it will evolve and continue to evolve. This will require additional training on technologies such as AI in order to keep up with technical evolution. AI is a brand new technology, so it will require time and resources will need to be trained on how to use the technology effectively.
Creating Predictive Analytics for Quality Engineering
If you are in the IT profession, you know that metrics are extremely important in helping to make decisions. This is also especially true for Quality Engineering teams. 10-15 years ago, testing was primarily conducted by software quality analysts and test cases were executed manually. Most software testing teams were small, and they would run a limited number of test cases to ensure things worked. Using this approach, it was relatively easy to know if there software was ready for production, and that QA manager could pull the team into a room and determine if the software was ready to be deployed. Those times have drastically changed.
Here are a few reasons why software testing has evolved:
There is a need based upon this evolution to have software testing metrics in order to make better decisions. This data needs to be consistently captured and analyzed. It is important to create predictive analytics so that you will be able to determine the current state of the quality engineering effort and accurately predict what would happen in production.
Quality is required.
Speed is required.
Resources and time is limited.
Decisions must be made.
Software must be deployed to production.
In order for these things to happen data analytics must be performed. A base set of data is needed. Some of those data elements include:
Planned/Executed test cases
Manual vs Automated tests
Root Cause Analysis
Once this data has been identified, it needs to be captured and segregated. When that information is gathered, you will be able to start and see trends. If you are testing a certain application, you will be able to predict how long it will take to perform testing, how many defects you plan to identify, and most likely how many defects will make it do production. Predictive analytics will evolve over a period of years. Many companies have started using AI/Machine Learning in helping perform this analysis.
This is also a continuous process. It is something that is not done once and completed. Additional metrics and more information will be needed. Those metrics will have to be captured and predictive analytics models will need to be created or modified.
Digital transformation requires that quality engineering teams transform how testing is planned, executed, and measured. The key to digital transformation is a focus on the customer. This requires that the quality engineering teams truly understand the business, and more importantly can accurately predict customer behavior. Issues such as usability, compatibility, performance, and security are extremely crucial. Provided these issues are tested, and the results are acceptable, this will create a really positive customer experience. For example, if a mobile application is slow, the customer is not going to have patience and will quit using it.
Predictive analytics can be used for defects. Here is some helpful information that will improve quality:
- Type of defect
- What phase was the defect identified
- What is the root cause of the issue
- What changes need to be made so that defect will not make it into production
- Is the defect reproducible?
Once this is understood, changes can be made to prevent similar issues from occurring. Using these predictive analytics, overall quality will greatly improve and speed to market will accelerate. It is important to have the right amount of data so that predictive decisions can be made.
If you are in an IT organization, you know how important Quality Engineering metrics are. Gone are the days that you can talk to a few quality engineers and get their gut feel on determining if a software application has a high degree of quality. It requires a lot more effort and energy and numbers to figure that out. Quality Engineering metrics are the heartbeat of any IT organization. While you should have several there is one that you should spend the majority of your time and effort focusing on. That Quality Engineering metric is: Defects. Defects tell so much of the story. Once you are able to gather that metric and classify it you can do some pretty amazing things.
I have had many quality engineering positions over the years and understanding defects is the first one that I put my energy and effort doing research. I start to ask a few questions:
- How does the organization feel about defects? Is it seen as a positive tool or a negative one? Do developers take defects personally or do they encourage their quality engineering counterparts to create defects? This is a really important piece of information because it will help me to understand a lot about an organization and their appetite to influence change.
- Are all defects entered into a central tool? This is necessary so that you will be able to capture all defects and not have to hunt through multiple applications to find them.
- How much technical debt does an organization have? From what I have researched, most organizations carry a good bit of technical debt. They are reluctant to spend time and energy in resolving defects. It creates a negative experience from a business perspective and internal customers often have to workaround issues to get their desired result.
- Is there a standard for defects? Once defects are being captured, there are certain criteria that needs to be gathered on each defect so that you can start to see trends and make decisions. Some of those standards include severity, business priority, root cause, project or sprint, environment, and application. By gathering this information you can start to classify defects based upon that criteria.
- Are defects being captured in production? This is critical. This metric will help you understand if the applications are stable, and if defects are being captured prior to a production deployment. Often, production defects are captured in a separate tool, which makes it very hard to consolidate and gain access to for the quality engineering organization. If they are being captured, what information is gathered? Is it possible to tie it to a specific release or feature?
- Which teams are finding the majority of the defects? Once I can get my hands on this information, I find it extremely helpful. In one of my previous companies, I did analysis and found that most of the defects were being captured by UAT testers. This led me to infer that they had the most subject matter expertise on the applications that were being tested. I began to build a relationship with that team, and did several things to help the UAT testers and gain additional knowledge from that team. The first thing, was to review the test cases they had created. While they were at a very high level, my QA team was able to gain some valuable information. We took that information and incorporated it into our test cases. Second, we looked at their test cases and mapped those to our test cases. My team had started automating test cases, so let let the UAT testers see the execution of those scripts and they agreed to let us run the regression test cases for them. This was a huge boost in productivity for them and it really helped to solidify the relationship.
Using this framework, I did analysis on a company where I previously worked and identified a defect leakage percentage of 38%. This number was mind blowing and really unacceptable. I established a goal to reduce defect leakage in production and set the target at 8%.
Here were some key focus areas when the team spent the bulk of their energy:
After a year of hard work, the results were impressive. We were able to get the production defect leakage down to 7%. This was a huge milestone and everyone was thrilled. The business was really happy with the improvements and became a fan of the quality engineering team. While there are many quality engineering metrics that should be captured, defects is the first one that you should start with.
ISTQB Agile Tester Certification
If you are an interested in obtaining more information about the ISTQB Agile Tester Certification, you have come to the right place. Most projects today have moved from Waterfall to Agile, so it is important that you have the right information to leverage best practices when testing on an Agile project. Once you understand Agile concepts and how testing should really be done, you can provide some tremendous education to your peers and other agile team members.
The certification for ISTQB Agile Tester Certification is designed for professionals who are working within Agile. It is also for professionals who are planning to start implementing Agile methods in the near future, or are working within companies that plan to do so, The certification provides an advantage for those who would like to know the required Agile activities, roles, methods, and methodologies specific to their role.
The ISTQB Agile Tester Certification qualification is aimed at four main groups of professionals:
1. Professionals who have achieved in-depth testing experience in traditional methods and would like to get an Agile Tester Certificate.
2. Junior professional testers who are just starting in the testing profession, have received the Foundation Level certificate, and would like to know more about the tester’s role in an Agile environment.
3. Professionals who are relatively new to testing and are required to implement test approaches, methods and techniques in their day to day job in Agile projects.
4. Professionals who are experienced in their role (including unit testing) and need more understanding and knowledge about how to perform and manage testing on all levels in Agile projects.
These professionals include people who are in roles such as testers, test analysts, test engineers, test consultants, test managers, user acceptance testers, and software developers. This ISTQB Agile Tester Certification may also be appropriate for anyone who wants a deeper understanding of software testing in the Agile world, such as project managers, quality managers, software development managers, business analysts, IT directors, and management consultants
Prerequisite: You must have the ISTQB CTFL Foundation Level certification
Exam: 1 hour with 40 multiple choice questions
Pass Rate: 65%
Exam Registration: Click here to register for the ISTQB Agile Tester Certification exam.
Exam Cost: $199 USD
Recommended Book: Agile Testing Foundations: An ISTQB Foundation Level Agile Tester guide
Syllabus: In order to pass the exam, you must study the syllabus and understand the material. Click here to download the syllabus.
Sample Exam: It is always a great idea to review the sample exams so that you can get familiar with the types of questions that you will see on the test. The more questions you can review, the more confident and prepared you will be for your exam. Click here for sample questions and click here for sample answers.
Outline: Here is a basic outline of the material you must know in order to successfully pass the ISTQB Agile Tester Certification exam.
Chapter 1: Agile Software Development
The tester should remember the basic concept of Agile software development based on the Agile Manifesto.
The tester should understand the advantages of the whole-team approach and the benefits of early and frequent feedback.
The tester should recall Agile software development approaches.
The tester should be able to write testable user stories in collaboration with developers and business representatives.
The tester should understand how retrospectives can be used as a mechanism for process improvement in Agile projects.
The tester should understand the use and purpose of continuous integration.
The tester should know the differences between iteration and release planning, and how a tester adds value in each of these activities.
Chapter 2: Fundamental Agile Testing Principles, Practices, and Processes
The tester should be able to describe the differences between testing activities in Agile projects and non-Agile projects.
The tester should be able to describe how development and testing activities are integrated in Agile projects.
The tester should be able to describe the role of independent testing in Agile projects.
The tester should be able to describe the tools and techniques used to communicate the status of testing in an Agile project, including test progress and product quality.
The tester should be able to describe the process of evolving tests across multiple iterations and explain why test automation is important to manage regression risk in Agile projects.
The tester should understand the skills (people, domain, and testing) of a tester in an Agile team.
The tester should be able to understand the role of a tester within an Agile team.
Chapter 3: Agile Testing Methods, Techniques, and Tools
The tester should be able to recall the concepts of test-driven development, acceptance testdriven development, and behavior-driven development.
The tester should be able to recall the concepts of the test pyramid.
The tester should be able to summarize the testing quadrants and their relationships with testing levels and testing types.
For a given Agile project, the tester should be able to work as a tester in a Scrum team.
The tester should be able to assess quality risks within an Agile project.
The tester should be able to estimate testing effort based on iteration content and quality risks.
The tester should be able to interpret relevant information to support testing activities.
The tester should be able to explain to business stakeholders how to define testable acceptance criteria.
Given a user story, the tester should be able to write acceptance test-driven development test cases.
For both functional and non-functional behavior, the tester should be able to write test cases using black box test design techniques based on given user stories.
The tester should be able to perform exploratory testing to support the testing of an Agile project.
The tester should be able to recall different tools available to testers according to their purpose and to activities in Agile projects.
I hope this information has been helpful. I wish you the best of luck as you prepare and pass your ISTQB Agile Tester Certification!
The world of software quality has changed tremendously over the last 5 years. There are many reasons why this has happened, and it is critical that education serve as the primary strategy to influence change in an organization. Here are a few critical areas where the CIO can gain a better understanding of some of the challenges that impact software quality.
Primarily due to Agile, the robust requirements that used to be a cornerstone of the waterfall methology have been thrown in the trash. While there are some organizations that continue to document and provide best practices gathering requirements, most organizations feel this is outdated and no longer necessary. The lack of proper documentation and requirements have a direct correlation on software quality. Here are some specific reasons
- Without proper documentation a developer will code software based upon their understanding. This often will result in buggy code and requires rework after production, which will be very expensive to fix.
- Without proper documentation a tester will write test cases based upon their understanding. This often will result in test cases that have to be written again and will result in the tester missing defects that will go into production.
- Without proper documentation, the test automation engineer, will build automation test cases which will have to be changed once the manual test case changes, and will miss defects that go into production.
- Without proper documentation, the production support developer will fix problems in production and will break other production code, because they didn’t get an accurate picture from the developer that originally built the code.
These are a few examples, but you should start understanding why requirements are critical.
Agile has changed the approach on how software is delivered into production. It has some tremendous benefits, and done properly, it can greatly increase productivity within an organization. It is quick, lean, and provides fantastic feedback from the business. CIO’s love it because it provides rapid return on investment.
There are some challenges from a software quality perspective that need to be incorporated and education needs to happen across all levels of an organization. Unless you are deeply entrenched on an agile team, you will probably make a ton of assumptions that are incorrect. Within an agile team, everyone has a responsibility for software quality. Here are some areas that will have a direct impact on software quality:
- Agile Stories must be well written. It is not enough to throw out tasks without enough detail.
- Agile Planning is critical. There is some real misunderstanding about agile as it relates to planning. The more planning and organizing that can be done, the better the team will respond and be able to pack more work within a given sprint.
- Documentation is needed. This is another area which is often misunderstood. Providing documentation allows the team to understand details and more effectively code and test the desired solution.
- Developers must still test. This is important. Just because the agile team has a tester, doesn’t mean that a developer doesn’t have to test.
- All testing can be automated. Well, perhaps it could. But it might not make sense, especially if the code isn’t stable and will need to change over sprints. ROI, is still important within agile, so just because you can automate a test, doesn’t mean that you should. This is the most misunderstood item that CIO’s need software quality education.
CIO’s often ask why there are so many defects found in production. Well, that is a fairly complicated question. In order to answer that, a full analysis will need to be done on the defects to gain a better understanding. Many years ago, when I began a new job, the same question was asked. In order to come up with the correct answer, the CIO brought in an outside company to perform a software testing assessment. While I was fairly new, it wasn’t uncommon for this to occur. In fact, I welcomed the opportunity, because I already had a hypothesis as to why this was happening. Typically this is primarily due to little or very poor requirements. The company came in and did the assessment and found that there were 38% of defects that were making it into production. That is a really high percentage, most companies will average around 5%. Over a period of time, we started to tackle the problem, and after 1 year of work, we were able to reduce the production defect leakage to 5%. This was a tremendous accomplishment and required a team effort from project managers,business analysts, developers, and testers to make this happen.
Software Quality Metrics
CIO’s are very metrics driven. They use data everyday to make better decisions. While there is usually some form of metrics around software quality, it usually does not make it into the CIO’s hand for one reason or another. I believe software quality metrics will tell a story, and provide great insight to those that are willing to look and interpret the data. Several years ago, my team and I started to perform analysis on what data was important and which metrics would help us make decisions. Once we agreed on what those metrics would be, we started to gather that information release over release. We started to see trends that would help us test more thoroughly those areas which where problematic. That resulted in bringing production defects down. We also, built a web based dashboard, that would allow the CIO and anyone else in the company to see how testing was progressing. Using this dashboard, we could determine if we were going to meet our testing timelines, and see what outstanding defects were holding up production deployments. This was a true game changer for the organization.
Educating CIO’s on sofware quality will take time. CIO’s want to have high quality software, they often don’t understand how to get there. They don’t want their business partners to suffer through using software that doesn’t work properly. It is important as a quality champion, you spend time with your CIO and provide software quality education, so that you can avoid having significant issues in production. Software quality can be done effectively and efficiently within an organization.