The Optimus Family: Interning in Noida

From the moment we stepped on to the plane, there was always a looming fear of “will I fit in?” It was extremely intimidating to embark on a journey that we were both unfamiliar with. We knew that we would stand out and feel somewhat alone. However, what we thought we knew couldn’t be further from actuality as soon as we stepped off the plane.  

Welcome-New-Hires-300x169 The Optimus Family: Interning in Noida

Optimus’ Company Culture

 

MVS-300x175 The Optimus Family: Interning in Noida

You will always finding smiling faces on the floor.

The Noida office emphasizes the importance of developing a strong family and friend culture. When you start your first day at Optimus, you are not just a number in the system; You are a part of the Optimus family. Every morning, a friend will come to your workstation and invite you for coffee or tea. At first, we thought this was a “Welcome to Noida” initiation. However, this is just a standard, friendly gesture that we see each day; three weeks later, the hospitality remains the same. Every day, they share breakfast, gather over lunch, and cultivate a work environment of high productivity and creativity.

SouthIndianSarthak-300x225 The Optimus Family: Interning in Noida

Post-lunch at an amazing South Indian restaurant with Sarthak, Olivia’s supervisor, and his team.

It is difficult to contextualize the feeling of working at Optimus through word; to truly understand, you can synthesize by imagining having a fantastic day with a group of your closest friends. To add to the fun, everybody always shares new and exciting findings to help boost the community goal of continuous learning. This environment leads to a heightened vocation, where you want to engage with more colleagues, join in on the Fun Friday Activities, and get the most out of what the job has to offer. This company culture is the foundation for building meaningful careers.

432Session1-300x225 The Optimus Family: Interning in Noida

The team shares some laughs during a weekly 4:32 knowledge session.

To summarize, we may look different, we may sound different, and we may tolerate spices differently, but everybody from the office accepts us for who we are. So, do we fit in? In short, we don’t. However, in an organization that promotes individuality and self-leadership, fitting in is not a primary concern. Our main goal is to feel like we belong. Luckily for us, we have never felt more at home. 

RepublicDayRuchi-300x225 The Optimus Family: Interning in Noida

A quick click with Ruchi, Laura’s supervisor, in our kurtas on Republic Day.

  • Laura and Olivia

Technology is Becoming the Core to Every Business

By Goran Kimovski, SVP Global Customer Solutions (Onica)

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

Technology Became the Differentiator

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

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

What Drives This Process?

Several technology innovations:

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

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

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

In turn, this drives innovation to:

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

What Does this Mean for Your Business?

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

This is how you can begin:

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

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

Learning the New Model

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

Technology Transformation Trend

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

Automated Testing on Azure DevOps

If you are looking for automated testing for any of your applications and would like to integrate it with your Azure DevOps infrastructure, Optimus Information has a “ready to deploy” Test Automation solution for you.

Our Azure DevOps based test automation solution uses the latest Azure CI/CD features and offers the following functionalities:

1. Configure automated test cycles using Azure DevOps

2. Schedule and execute Web UI and REST API test scripts on cloud using Azure VMs

    • Self-serviced virtual machines and PaaS resources for testing using Azure DevTest labs
    • Supports automated test scripts developed in Java or C# using Selenium WebDriver, REST Assured and RestSharp

    3. Distribution of apps to beta testers and your collaborators with Azure App Center

      • Selection from a large variety of test devices using the App Center Test Cloud
      • Supports popular frameworks like Xamarin.UITest, Appium, XCUI Test etc.

      4. Test result reporting and logging with screen shots and 6 month data retention with App Center

        • Support for notification over mail or other communication tools like Slack

        5. Data persistence support using AzureSQL service

        6. Integration with PowerBI Embedded for reporting and analytics

        7. Built in test script source code management using Azure DevOps

          • Supports integration with third party Git providers like Github if required

          8. Built in test case management for test plans using Azure Test Plans

            • Custom integration possible with other tools like TestLink where supported

            9. Concurrent execution

            10. Ability to start automated testing in short time frame with expense control

            Cloud is important to our customers. The Optimus test automation framework on Azure makes it possible for our customers to seamlessly integrate test automation into their cloud-based development as well as their test and production environments. Contact us to get a more in-depth look to to get a demonstration.

            Automated-Testing-Solution-on-Azure-2-e1554082144564 Automated Testing on Azure DevOps
            All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.

            Types of Performance Testing and the Best Tools for the Job

            In the abstract, it’s easy to think of testing a piece of software as a single set of actions. Within the industry, however, it has become common practice to look upon performance testing as a multifaceted task. The process includes:

            • Load testing
            • Stress testing
            • Endurance testing
            • Scalability testing
            • Volume testing
            • Spike testing

            Each phase has its distinct requirements and goals, and it’s important to be aware of them before moving ahead with a project. Likewise, it’s prudent to know which tools and processes are most suited to the job.

            Load Testing

            Load testing is intended to look at performance under two sets of conditions, normal and peak loads. An organization needs to model what it feels is likely to be normal usage of software. For example, a cloud-based photo storage system might expect to handle a certain load during particular parts of the year. Conversely, specific annual increases, such as during the holidays, would also need to be anticipated.

            The aim of load testing is not to overload the system. This can be done by using software to create virtual users and have them interact with the software. The goal is to see what performance looks like when an expected load is regularly hitting the system. Bottlenecks have to be identified, and notes need to be passed along to developers to see what can be done.

            Stress Testing

            Taking things to the next logical step, we arrive at stress testing. This is a deliberately intense process that’s intended to find out where the breaking points of operational capacity are. It should only be conducted once reasonable load testing efforts have been made and remedies have been implemented during that stage.

            The objective is to identify safe usage limits, and it’s particularly important to spot vulnerabilities that may be triggered when the system is operating under stress. If a database implementation suffers a buffer overrun during excessive loads, it’s good to know that in advance.

            Endurance Testing

            It may seem a fine distinction to make, but the question of how a piece of software will hold up over a long period of load is important. Anyone who has ever watched a desktop program’s memory usage balloon over the course of several hours of normal use can appreciate the difference. Just as issues often occur when a system is overwhelmed during a peak test, similar problems may begin appear only after a prolonged run of normal usage.

            Scalability Testing

            Maintaining any project over the course of years will present issues as the user base grows. This calls for a degree of guess work, as you’ll find yourself often trying to determine how 1,000 users today might grow out over five years. This can lead to unanticipated failures, if not addressed early on in a non-functional environment. No one wants to see a production database run out of space for entries because the index was built using INT11 and the system ran out of assignable unique IDs.

            Volume Testing

            The throughput of any user base is likely to grow as the popularity of a product increases. To get ahead of these problems, it’s also wise to perform volume testing. The goal in this case is to identify where problems might exist based on the volume of usage. For example, read-write issues with critical interface files, such as settings stored in XML, may create volume limits that can be adjusted by minor tweaks.

            Spike Testing

            Sudden increases and drops in usage can lead to issues that are difficult to predict. If an entire block of internet addresses loses connectivity, a high-volume site might experience a dropoff that’s both massive and instantaneous. These interruptions may even occur mid-operation. Spike testing allows you to identify specific potential issues and see the system fails elegantly.

            Moving to Performance Testing

            Devising a way to engage in testing while developers are still working on a specific generation of software takes a lot of planning. A lot of companies are turning to Agile methodologies in order to handle their testing needs. The goal with Agile processes is to see that orderly efforts are made to advance products into testing, make notes of issues, implement changes and confirm completion of work.

            Software performance testing work tends to call for a large degree of automation, and it’s wise to keep this in mind when choosing what to use. Many software development environments, such as the Enterprise editions of Microsoft Visual Studio, come with their own performance testing components. Those looking for an open source solution designed for web applications might wish to check out Apache JMeter. IBM Rational Performance Tester and HP LoadRunner are also popular choices for Licensed solutions.

            There are several questions to look at. For example, JMeter, by virtue of being open source, doesn’t offer the same sort of scalability that the Visual Studio tools do, especially in terms of being able to buy more virtual users instances in order to keep loading up. If you’re looking for a system that offers cloud-based solutions and simple Agile integration, IBM Rational Performance Tester is a solid option.

             

            If you have questions about getting started with Performance Testing or want to push the toolset further, give us a call. We’re always happy to answer any questions.

            Include more than 1000 Values in Oracle IN Clause

            In Oracle we can’t include more than 1000 values in the “IN” clause.

            To get around this limitation, you divide the string of comma delimited values to be included into two or more parts using SUBSTR or through any similar other function and then these new strings should be placed in the IN clause of different SQL statements that are later combined using the UNION operator.

            Sample Code

            First create two hidden parameter that include the initial first and second half of the selected values of the parameter. For this write a custom code can be used.

            Sample code to break the parameter into two hidden parameter of half the original length.

            Public Function Group1(ByVal parameter as Parameter) as String
             Dim s as String
             s=String.Empty
             If parameter.IsMultiValue then
             For i as integer = 0 to parameter.Count/2
             s = s "" CStr(parameter.Value(i)) + ","
             Next
            
            Else
             s = CStr(parameter.Value(0))
            
            End If
             Return s
             End Function
            
            Public Function Group2(ByVal parameter as Parameter) as String
             Dim s as String
             s=String.Empty
             If parameter.IsMultiValue then
             For i as integer = (parameter.Count/2) to parameter.Count-1
             s = s "" CStr(parameter.Value(i)) + ","
             Next
            
            Else
             s = ""
             End If
             Return s
             End Function

            Sample Query

            New we use two SQL queries including the two hidden parameters joined by the UNION operator

            SELECT * FROM TABLE_1 WHERE VALUE_1 IN (:prmHiddenInspectorFirstGroup1)
            UNION
            SELECT * FROM TABLE_1 WHERE VALUE_1 IN (:prmHiddenInspectorFirstGroup2)

            Obviously, this example breaks when you get to 2000 values, but it is presented here as a sample approach that can be easily modified to suit more advanced situations.

            The post Include more than 1000 Values in Oracle IN Clause appeared first on OptimusBI.

            Test Scenarios for Credit Card Payment Through a POS Application

            What are the Test Scenarios for Credit Card Payment through as POS Application

            Point of sale applications need to handle a wide variety of transactions like cash, debit cards, credit cards, gift cards and loyalty cards. Credit cards play an important role in payment for anything purchased. Below are some of the most important test scenarios for credit card payment which should be tested with any credit card payment solution when integrated with a POS application.

            Prerequisites

            Credit Card Configuration: Includes configuration of card length, card range and card type (VISA, AMEX, MASTER etc)

            Merchant Configuration: A merchant needs to be configured who is authorized to accept card type payments

            Credit Card Processor Configuration: Credit card processor needs to be configured to process credit card payment (e.g. Mercury Payment System or Lynk, etc.)

            Test Scenarios

            Capturing Card Details: Following areas should be tested while capturing card details.

            1. Credit card number : Test card numbers using the correct length and range and card numbers that are outside the correct length and range.
            2. Expiry date: Test valid expiry dates, invalid expiry dates and invalid date formats.
            3. CVV number: Test valid CVV numbers , mismatched CVV numbers and blank CVV numbers.
            4. AVS code: Entering AVS details for configured numeric or alphanumeric formats.
            5. Card reader to capture card details: Test swiping of cards from both sides and chips.
            6. Encryption: Verify that captured card numbers are properly encrypted and decrypted.

            Authorization: Once card details are captured, they are sent to processor to be authorized. Following areas need to be tested during authorization.

            1. Authorized amount: Test that the correct amount is being authorized.
            2. Receipt printing: Test that merchant and customer copies of the receipts and any vouchers print properly.
            3. Receipt details: Check that the receipts are printing the proper date, time, card details, authorized amount etc…
            4. Response code: Test that the correct response codes are being returned for approved, declined, on hold and all other transactions.

            Settlement: Once the payment is done following things should be tested:

            1. Reprinting receipt: Test that you can reprint the receipt for a closed transaction.
            2. Void credit card’s payment: Check that you can void a payment before posting it and that after posting a payment voiding is not allowed.
            3. Verifying report: All information regarding each credit card transaction should be reflected in reports. Any adjustments made in closed checks should be reflected in the report.

            Contact us to lear about our testing services.

            (Note: This post has been updated with new information)

            Report Performance Optimization: Data Quality

            What is Query Optimization?

            Query optimization is the first place everyone looks when doing performance optimization on reports, but there is more to performance optimization than just optimizing queries.

            Proper use of tables, joins conditions and wide data ranges are all solid techniques for optimizing queries. However, data quality is another factor in report performance.

            Let me share an example from an organization we were working. The company was using the project management module of an ERP system to track hours, billing and expenses. They had more than 500 projects in the system and ran a weekly report that is configured to run on the database of active projects to provide detailed information on hours consumed, capacity, project status and resources breakdown.

            The problem is that it takes one hour to run the report and requires a lot of computing power even after query optimization.

            The report is developed to show the information for only active projects in the week. There is no process of closing and archiving the completed projects on regular basis. As a result, the query had to run through all the projects that are marked active, even though these are actually completed.

            The solution to this performance optimization challenge was not query optimization in this case. Improving the process of changing the status of projects and archiving them resulted in the performance improvements that they needed. This resulted in better data available in the database and less time and computing resources to produce the query output.

            After implementation of the process, the organization has seen significant decrease in the query run time.

            The lesson learned here is that report performance optimization isn’t always about query optimization.  The people that touch data at any point can also have an effect on performance.

            Lear more about performance optimization here.

             

            (Note: This post has been updated with new information)

            Testing a Point of Sales (POS) Application

            How to test POS Applications?

            Testing point of sales (POS) systems is something that we have done a lot of here and I wanted to share an overview of what POS application testing entails.

            A POS is a computer that is used instead of an old fashioned cash register. It’s more like a personal computer connected to a receipt printer, cash drawer, credit/debit card reader and a bar code scanner.

            Goals of a POS Application Test Plan

            A good POS test plan should ensure the following:

            1. The system makes the process of paying for an item simple and fast. This can be accomplished by scanning the item with a barcode scanner, totaling the purchase and accepting payment easily through credit, debit, gift cards or by cash.
            2. It gives the customer the option to pay part of the bill by cash and part of it by a Credit/Debit/Gift card. The process of paying with multiple options should be simple and fast so that customer does not have to wait to process their orders.
            3. A good POS system allows you to suspend a transaction for a particular customer with one touch in case the customer forgets something while letting the cashier help other customers who are waiting for the checkout. When the customer with the suspended transaction returns, the system should retrieve the transaction and complete it without re-entering all the items.
            4. The system keeps track of what your customers are buying and who they are. It keeps track of what’s selling, at what times of day or week, to which types of customers and by which sales people. The data collected from POS terminals is useful in planning of long term strategies. A good POS System will also have reminder dates for each customer so you can call or e-mail them prior to an anniversary or birthday.

            Testing of POS applications

            In today’s competitive business, a POS can be a key differentiator for retailers. It needs to meet changing business needs under tight budget and aggressive timelines. So it is very important for POS applications to be reliable, scalable, easily maintainable, highly secured, and easily customizable by the customer.

            Challenges

            1. Multiple Configurations: Testing a POS application with different settings and configurations is a cumbersome task. Test cases should be designed covering each and every scenario (valid or invalid) in detail. Therefore significant budget should be put in testing of such applications to prevent any major issues at the customer end.
            2. Peripheral issues: The peripheral issues may be related to devices which are connected to a POS like barcode scanners, scales, printers, towers and cash drawers.
            3. Complex interfaces: Integration of POS System involves numerous interconnected systems and third party elements. Systematic test design techniques are followed to reduce the complexity of interfaces
            4. Test Lab Maintenance: As a significant amount of hardware is normally connected to a POS, so it requires a large amount of space to house this hardware. You also have to put some effort and expense in to keeping the hardware is in good repair.
            5. Upgrades: Rapid technological advancements necessitate a frequent hardware and software upgrades which requires more infrastructure.
            6. PCI Compliance: Care must be taken to adopt of PCI-compliant, tamper-proof infrastructure at all POS terminals to protect cardholder data and identity.

            POS Test Stack

            1. System Testing: System testing involves testing the complete, integrated system against the requirements specified in the requirement documentation. It aims at finding defects within the system as a whole. It includes testing of complete workflows from ordering an item to settling of checks through different modes of payment and generating reports.
            2. System Integration testing: It aims at evaluating the software in terms of its co-existence with other third party software. For instance, in POS applications third party software like CRM systems are integrated and tested to find major flaws in their interactions.
            3. Business layer testing includes testing of:
              • Hardware Settings and Hardware Units: Testing of hardware devices connected to a POS application with different and configurations.
                Barcode Scanner: Testing of barcode scanners to check whether it reads the code of an item correctly and displays price corresponding to that item.
                Printers: Testing of printers to verify whether the correct information related to an item is printed on various receipts generated at the printer. Correct information related to the customer, his ordered items and total should be printed on the receipts.
                Scale: Testing of scales used to weigh items sold by weight. The scale should display the exact quantity of an item which is placed on it to weigh and its price should appear according to the weight of the item.
                Cash Drawer: Testing of Cash Drawer to check whether it opens when an order is placed or when a check is settled.
                Tower: Testing the tower that displays the ordered item and its price. This helps customer to see what he has ordered. It also displays the due amount, tendered amount and the change given to the customer. A tower is tested against this information to check if correct information is displayed on it.
              • Normal and Abnormal Scenarios: This involves testing of POS application with valid and invalid data. This testing is performed keeping in mind that the application does not crash on entering the invalid data.
              • Business Transaction flow tests: These tests involve testing the complete workflow from ordering an item to the settlement of the check.
            4. Reporting Tests: This involves testing of reports. The reports are an important part of the POS application which keeps track of all the transactions that take place on a particular day, in a particular week, month or year. These reports need to be verified to check that they show the correct information related to sales, transactions etc… The reports must also be tested to see if they are properly apply any filters.
            5. Regression Testing: This is testing which is performed to verify the application after a new functionality has been introduced into the application to checks that this has not hampered other parts of the application which were working correctly earlier. Regression testing may also be performed as a result of some bug fixes.
            6. Performance Testing: Performance of the system should not degrade with the increase in size of data in the database.

             

            (Note: This blog post has been updated with new information.)

            Four Common Pitfalls of Test Automation Projects

            How to avoid the common pitfalls of test automation projects?

            After helping out with test automation projects for a number of different organizations, I have identified several common pitfalls of test automation projects that I often see.

            Avoiding making these common mistakes will certainly accelerate the project momentum and make the automation experience more rewarding. The first two suggestions address the managerial pitfalls while the other two address the technical pitfalls.

            Always treat test automation projects as development projects

            Often, test automation is seen as “nice-to-have”. Therefore, it does not receive the attention required to take the fullest advantage of it. Therefore, test automation projects often slip and the company never enjoys the benefits of test automation.

            In some cases, the team even becomes frustrated with test automation and hesitates to invest in test automation again. And when it is time to invest in it they are not sure where to begin and costs money. So, what are some common pitfalls of test automation projects and to avoid falling into them.

            To make your test automation project effective, always approach test automation projects as development projects.

            • Assign a product owner or project manager
            • Depending on the development methodology your company deploys, come up with a project plan or project milestones just like you would for any other development project.
            • Dedicate at least one to two people to the test automation team. Since test automation is also a kind of development project, ideally hire or arrange someone who has development experiences to be the lead programmer for the project.
            • Create a design of the test framework or test architecture before coding your automated tests. Without a proper design, the development process and maintenance will be a pain.

            Have the product development team collaborate on test automation

            In every organization that I have helped with, the test automation team is separated from the product development team. And collaboration between the teams is minimal or non-existant. Test automation should be a joint effort of the product development team and the test automation team.

            This helps improve the software’s testability and reduce test automation overhead thus easing the architecture design and future maintenance.

            Invest time in result reporting

            When we talk about test automation, most people focus on the test execution and miss the result analysis and reporting part. Test automation is not just about performing the test steps; implementing a good result reporting component helps you find bugs more effectively. Just having “success” and “fail” as the report messages does not help diagnose the actual problems too much. And testers need to repeat the tests manually to find the bugs.

            In addition, create a scale of error severity so that the team can easily identify critical and major bugs. This can also help the automation tool to determine if the error is severe enough to terminate the test. For example, in cases where data correctness is not critical, even if data validation errors are detected by the tool, the test should continue until it hits a critical bug.

            Implement test set up and tear down procedures

            Test set up and tear down procedures are usually missed out for test automation. People tend to forget about them because when we execute the tests manually, the set up and tear down are so seamless and subtle that we don’t see a need to implement them for automation.

            But in fact, not implementing the automation code to handle set up and tear down will have greater impacts than most people expect. For example, the browser cache may preserve the state of the website under test and, without clearing the cache, you may get incorrect results back. Another example, if there are multiple instances of the same application under test running on the same machine, the tool may have troubles identifying which one to run tests with.

            (Note: This blog has been updated with new information)

            What to Include in a Software Testing Traceability Matrix

            A Software Testing traceability matrix is an essential tool for any thorough software tester. It should be referenced throughout the entire software development life cycle to bring transparency and completeness to software testing efforts.

            Software Testing Requirements for Traceability Matrix

            In simple words, a testing requirements traceability matrix is a document that traces and maps user requirements, usually requirement IDs from a requirement specification document, with the test case IDs. The purpose of this document is to make sure that all the requirements are covered in test cases so that nothing is missed.

            The traceability matrix document is prepared to show clients that the coverage is complete. It usually includes the following columns: requirement, baseline document reference number, test case/condition and defect/bug ID. Using this document the person can track the Requirement based on the Defect id.

            Adding a few more columns to the traceability matrix gives you a good test case coverage checklist.

            Types of Traceability Matrices

            1. Forward Traceability: Mapping of requirements to test cases.
            2. Backward Traceability: Mapping of test cases to requirements.
            3. Bi-Directional Traceability:  A good example of a bi-directional traceability matrix used in software testing is the references from test cases to basis documentation and vice versa.

            A forward traceability helps us see which requirements are covered in which test cases? Or whether a requirements is covered at all.

            A forward traceability matrix ensures that we are building the right product.

            A backward traceability matrix helps us see which test cases are mapped against which requirements.

            This will help us in identify if there are test cases that do not trace to any coverage item. If the test case does not trace to a coverage item, it is either not required and should be removed, or else a specification like a requirement or two should be added. Therefore, this backward traceability is also very helpful if you want to identify that a particular test case is covering how many requirements.

            A backward traceability matrix ensures that we are building the product right.

            A bi-directional traceability matrix contains both forward and backward traceability.

            Why use software testing traceability matrices?

            The traceability matrices are the answer to the following questions when testing any software project:

            • How is it feasible to ensure, for each phase of the SDLC, that I have correctly accounted for all the customer’s needs?
            • How can I certify that the final software product meets the customer’s needs? It lets us make sure requirements are captured in test cases.

            Disadvantages of not using traceability matrices include the following:

            • More defects in production poor or unknown test coverage.
            • Discovering bugs later in the development cycle resulting in more expensive fixes.
            • Difficulties planning and tracking projects.
            • Misunderstandings between different teams over project dependencies, delays, etc…

            Benefits of using traceability matrices include the following:

            • Making it obvious to the client that the software is being developed as required.
            • Ensuring that all requirements are part of the test cases.
            • Ensuring that developers are not creating features that no one has requested.
            • Making it easy to identify missing functionalities.
            • Making it easy to find out which test cases need updating if there are change requests.

            How to create a traceability matrix

            1. Open Excel to create Traceability Matrix:
            2. Define following columns:
              1. Use case ID / requirement ID.
              2. Use case / requirement description.
              3. One column for each test case.
            3. Identify all the testable requirements in granular level from requirement document. Typical requirements you need to capture are as follows:
              1. Used cases (all the flows are captured)
              2. Error Messages
              3. Business rules
              4. Functional rules
              5. Software requirement specifications
              6. Functional requirement specifications
            4. Identity all the test scenarios and test flows.
            5. Map Requirement IDs to the test cases. Assume (as per below table), Test case “TC 001” is one flow or scenario.  SR-1.1 and SR-1.2 are covered .
            6. Now from below table you can easily identify which test cases cover which requirements and which test cases need to update if there are any change requests.
            Requirement IDRequirement DescriptionsTC 001TC 002TC 003
            SR-1.1User should be able to do this. x
            SR-1.2User should be able to do that. x
            SR-1.3On clicking this, the following message should appear. x
            SR-1.4 x
            SR-1.5 x x
            SR-1.6 x
            SR-1.7 x

            This is a very basic traceability matrix format. You can add more columns and make it more effective. Here are some columns you should consider adding:

            • ID
            • Assoc ID
            • Technical Assumptions
            • Customer Needs
            • Functional Requirement
            • Status
            • Architectural/Design Document
            • Technical Specification
            • System Component
            • Software Module
            • Test Case Number
            • Tested In
            • Implemented In
            • Verification
            • Additional Comments

            Here is another simple forward traceability matrix that we used on a recent project in Excel format.

             

            Note: This blog post has been updated with new information.