✈️ Next at PNSQC, Portland, OR!

Team Z is excited to join the PACIFIC NORTHWEST SOFTWARE QUALITY CONFERENCE (PNSQC) this year. PNSQC is the place to be if you are interested in keeping up to date with the latest in the Quality Assurance (QA) world across various industries.

Join us for A Culture of Quality at Booth #12, on Oct 14, World Trade Center, Portland, OR.

Our latest QA Webinar on ‘How AI is changing Defect Detection?’ almost had a similar theme. In case, you missed it live, here are the learnings from our AI webinar on QA.

The 1-hour live session had 90+ attendees registered, and 25% of them watching it live. The presenter, Vasudevan Swaminathan walked the attendees through the need for defect detection and how Artificial Intelligence is changing that.

It all started on 9 Sept 1947, the day when the world’s first bug was found and the defect evolution, over the years costing a fortune for companies, which called for the need for defect detection.

As the aphorism goes, ‘Software Testing proves the existence of bugs, not their absence”. The existence of defects and its serious impacts altered the ways of software testing methods. From Waterfall methodology to the current DevOps era, we have seen it all. The latest and what’s considered to be the future of software testing is AI. The transition to the adoption of AI in testing is no more a buzzword today.

AI relies on Data

The more and diverse the data in forms of past defects, defect trends, etc. fed to the Machine Learning model, the better is the outcome.

Working together with people, AI can raise the data literacy of the entire workforce. While some AI applications rely only on machine automation, most complex business problems like Defect Detection require human interaction and perspective. And that is why we prefer to call it Augmented Intelligence rather than calling it Artificial Intelligence.

We did have an interesting Q&A toward the end of the webinar, I'll be able to share them in my next story.

Thanks for reading!

According to Gartner, 95 percent of applications running in production today are not instrumented.

Shipping defect-free software which has been used by millions of people requires extensive testing to ensure stability and performance. Despite Continuous Testing and Continuous Integration, defects seem to be inevitable.

When the issues arise in the production environment, all the could/should-haves will also step in and after a long meeting, Engineers will go back to fixing the issue and Test team to test them again and give a go for deployment.

There is a 90% chance for the patch to fail again if the QAs don’t define test case scenarios rightly. QAs with their existing domain knowledge should be able to do the justice of testing the right test cases and guarantee the success of patch.

These traditional practices are purely subjective, and it’s commonly known as risk-based testing. Maximum test coverage is not completely possible in the current form of risk-based testing and it poses a series of challenges to the deployment.

How Machine Intelligence can augment Quality Assurance

The World Quality Report states “the most important solution to overcome increasing QA and Testing Challenges will be the emerging introduction of machine-based intelligence”

The inability of the QAs to intelligently select test cases might stem from not having a large volume of test cases in the first place.

Machine-based Intelligence like Spider AI can solve the problem for QAs. Spidering can augment the test coverage by generating optimal test cases to DevOps and QA.

And, shopping like experience would be nice if the QAs are also given recommendations from the pool of test suites like “Test cases you might like”, “More Test cases like this”. And, that’s exactly what Zuci is trying to build with its patented intellectual property.

A good amount of data in forms of past defect history, trends in defects, etc. has to be fed to the machine learning engine, thus helping it in intelligent Test Case selection.

Combined Intelligence can provide a personalized feed of predictive and prescriptive insights into software performance and improve the quality in production environments.

To learn more about the AI trends in software testing, the impact of AI and allied technologies on software testing and how these technologies can be used for the betterment of software testing, join us for the live webinar on “How AI is changing Defect Detection”? on Sept 19, 2019 at 11 AM CST.

Save your spot here

“Artificial Intelligence” was one of the most searched terms in the Scopus scholarly database in 2018, joining cancer, heart attacks, and big data in the top ten.

Continuous quality improvement, a cyclical process of assessing performance, implementing improvement plans, and reassessing results is the goal for every organization across industries and software is no exception.

Effective testing helps in improving quality by identifying and removing defects early in the cycle and emerging technologies such as Artificial Intelligence and allied areas of Artificial Intelligence such as Data Sciences, Machine Learning, are expected to make a significant impact in performing better testing in the years to come.

Software testing and quality as a discipline have borrowed heavily from manufacturing and other industries. Kaizen, Kanban, Lean manufacturing, Just-in-time manufacturing, and other approaches have been used in software to improve quality over the years. Similarly, the use of artificial intelligence techniques to identify and eliminate defects in other industries can be taken as learning and applied in the world of software testing and quality. Let’s look at some examples.

Motorola takes help from “Instrumental Inc“, a company that helps in real-time defect detection of both known and unanticipated issues on manufacturing lines using machine learning algorithms. Instrumental aggregates all of the image data into a cloud database, where it can be analyzed by tens or even hundreds of machine learning algorithms to identify defects or changes that engineers care about.

The Hong Kong Polytechnic University (PolyU) has recently developed an intelligent fabric defect detection system, called “WiseEye”, which leverages advanced technologies including Artificial Intelligence (AI) and Deep Learning for quality improvement in the Textile industry.

Textile manufacturers currently rely on human efforts to randomly inspect the fabric by naked eyes. Due to human factors such as negligence or physical fatigue, defect detection by human labor is usually inconsistent and unreliable. The research team at “WiseEye” has overcome the challenge by applying Big Data and Deep Learning technologies. By inputting thousands of yards of fabric data into the system, the team has trained “WiseEye” to detect about 40 common fabric defects.

“Data” is at the heart of Artificial Intelligence and as we can see in the examples above, the path to better quality comes from past data, which is being used to train artificial intelligence systems. This is a big area of learning that can be applied from other industries to software testing and quality.

Collecting past defects, categorizing them accordingly and using them to train artificial intelligence systems can help software testing detect defects, helping to raise the quality bar in production environments.

It doesn’t matter if you are an Engineer, CTO, QA, etc. When issues arise at production, it’s a collective responsibility of everyone to detect defects, fix it and work on quality releases.

Learn more about Artificial Intelligence, Machine Intelligence, Augmented Intelligence and how influential are these technologies and their impact on Software Testing.

[Webinar] How AI changing Defect Detection? on Sept 19, 2019, at 11 AM CST. Save your spot here

About the Author

Vasudevan Swaminathan is the President and Chief Consultant at Zuci. Vasu is a trusted advisor and business partner to clients, having the ability to grasp their vision for the software. Check him out at Vasudevan Swaminathan

About Zuci

Zuci is revolutionizing the way software platforms are engineered with the help of patented AI and deep learning models. Learn more about Zuci at www.zucisystems.com

“We believe that the most important solution to overcome increasing QA and Testing Challenges will be the emerging introduction of machine-based intelligence,”

AI is not something new, it has been there since the 1950s. For as long as there has been software, there has been software testing and there will be AI in Software testing.

At Zuci, we are excited to host a Webinar on the topic“How AI is changing Defect Detection” on 19 Sept 2019 at 11:00 AM CST (5:00 PM BST)

Applying decade-old AI techniques to the software testing industry has only really started to become feasible since the past year. One of the biggest use cases of AI in software testing is, detecting bugs before they cost a fortune to the company.
Bugs can become more expensive when detected later in the software development process starting from $100 in the Requirements phase to $10,000 in the Production phase.
The pressure on companies to deliver quality software at a greater speed has never been this high. Harnessing the power of AI and ML is the way to go forward.

Join us on Sept 19 at 11 AM CST to learn more about the topic. Register to save your spot at https://attendee.gotowebinar.com/register/6736007755450398988

What constitutes a method in programming is the number of classes. Methods, classes are all made up of lines of code.

What happens when your method is fat?

When the codebase goes into the deployment phase, the fatty methods gets stored in the RAM, the CPU has to retrieve these methods from the RAM and run which takes a little too much time whereas the lean methods, being thin in size get stored in the server of the CPU itself and when it is run, it takes very less time to run it as opposed to retrieving them from RAM and running it.

Hence writing lean methods is to be recommended to save time and storage for fast deployment.

Disclaimer: I work at Horus, an engineering management platform helps companies follow the best practices and help the engineering team address the issues in code and code annotations.

Head over to explore Horus

However, does having a high churn means that the developer has worked hard to write lines of code, rewrote it again, modified and made it better, Or vice versa?

It could be not! The churn rate is not directly proportional to the developer’s productivity. If that could be it, then it is a subjective way of measuring the software quality and developer’s productivity

John has written a greater number of lines of code and churned it more when compared to Sara, but the quality lines of code have been written by Sara, with less churn rate and writing it right for the first time.

The churn rate needs to be tracked early in the process in order to save a lot of time and cost which otherwise would incur when it goes to the production phase. Developers would be spending a lot of time churning, bringing down the quality of code also being less productive.

There needs to be an objective metric to measure these and track the quality of the software and the value of these lines of code.

Disclaimer: I work at Horus, from Zuci, is an engineering management platform, with a set of metrics helps measure these factors and track the health score of the application.

What’s the size of your class? — How big is too big?

For anyone who’s writing the code, there has been this concern — what should be the ideal size of my code in a class/method/function.

It differs from each developer. As a rule of 30, Steve McConnell in his book, Code Complete says that,

If an element consists of more than 30 sub elements, it is highly probable that there is a serious problem:

1. a) Methods should not have more than an average of 30 code lines (not counting line spaces and comments).
2. b) A class should contain an average of less than 30 methods, resulting in up to 900 lines of code.
3. c) A package shouldn’t contain more than 30 classes, thus comprising up to 27,000 code lines

Studies show that, number of lines of code is the base upon which the quality and the complexity of the software that you are building stands on. The real value of a guideline like the Rule of 30 is when you’re reviewing code and identifying risks and costs.

Too many lines of code will be difficult to compile and test. However, there is no ideal metrics that measures the fattiness of the class. It isn’t just based on “opinion” it is based on the result of a decades of practice. Code reviews help identify and rectify issues in the codebase.

Informal reviews can find 20%-30% code defects. Studies at IBM, HP, Microsoft and other places show that it is several times cheaper to find bugs in code reviews than through testing. And evidence keeps coming in to support that code reviews work.

Horus, an engineering management platform helps review the lines of code being written and what it means to the developers writing it, risks and costs associated with it to the mid and top level management, regardless of the domain, level of maturity of the organization, or lifecycle phase during which they were applied.

Developed by Thomas J. McCabe, Sr. in 1976, Cyclomatic complexity is a software metric (measurement), used to indicate the complexity of a program. It is a quantitative measure of the number of linearly independent paths through a program’s source code.

The more the cyclomatic complexity, the more complex is the lines of code that you have written.

Cyclomatic Complexity is directly related to the health of the code!

Cyclomatic complexity is measured based on the numbers given per method in the source code. It is a direct function of the number of branches in your program. With each if, for, or case, you add to the cyclomatic complexity of the program. By removing branching from a function, you can make it less complex.

The lines of code in a class or a method also affects the cyclomatic complexity, a greater number of lines means, a combination of several logic altogether, which clearly violates SRP (ingle responsibility principle).

High “complexity” is directly translated to low readability and high maintenance costs.

There probably is no single simple measurement that can express an abstract concept such as complexity in a single number. But this does not imply that we cannot measure and control complexity. It just has to be done with multiple metrics and checks that cover the various aspects of complexity.

Horus, an engineering management platform, with a set of metrics helps measure these factors and track the health score of the application.

Cyclomatic complexity yields a value to your Software — Know how.

Developed by Thomas J. McCabe, Sr. in 1976, Cyclomatic complexity is a software metric (measurement), used to indicate the complexity of a program. It is a quantitative measure of the number of linearly independent paths through a program’s source code.

The more the cyclomatic complexity, the more complex is the lines of code that you have written.

Cyclomatic Complexity is directly related to the health of the code!

Cyclomatic complexity is measured based on the numbers given per method in the source code. It is a direct function of the number of branches in your program. With each if, for, or case, you add to the cyclomatic complexity of the program. By removing branching from a function, you can make it less complex.

The lines of code in a class or a method also affects the cyclomatic complexity, a greater number of lines means, a combination of several logic altogether, which clearly violates SRP (Single responsibility principle).

High “complexity” is directly translated to low readability and high maintenance costs.

There probably is no single simple measurement that can express an abstract concept such as complexity in a single number. But this does not imply that we cannot measure and control complexity. It just has to be done with multiple metrics and checks that cover the various aspects of complexity.

Horus, an engineering management platform, with a set of metrics helps measure these factors and track the health score of the application.