Archive for the ‘Hypothesis-based Testing’ Category

« Older Entries

Quality injection – Scientific validation of requirements

Monday, August 9th, 2010
domain knowledge. One of our Japanese customer threw a challenge – “How
can you use HBT/STEM to scientifically validate requirements without knowing
the domain deeply?” .
The core aspect of HBT is to hypothesize potential defect types that prove that
they do not exist. These are identified by keeping in mind the end users and
the technology used to construct the system. So how do you apply this to
validate a pre-code artifact?
We commenced by identifying the various stakeholders for requirement
document and then identified key cleanliness attributes. These cleanliness
attributes if met would imply that the requirements was indeed clean. We were
excited by this. We then moved and identified potential defect types that would
impede these cleanliness attributes/criteria.
Lo behold, the problem was cracked and we then identified the various types
and the corresponding evaluation scenarios for validating the requirements/
architecture document. We came up with THIRTY+ defect types that required
about 10+ types tests conducted over TEN quality levels with a total of SIXTY
FIVE major requirement evaluation scenarios to validate a requirement.
What we came up is not yet-another-inspection-process that is dependent on
domain knowledge, but a simple & scientific approach consisting a set of
requirement evaluation scenarios that could be applied with low domain skill to
ensure that the requirement/architecture can indeed be validated rapidly and
effectively. These ensure that the requirement document is useful to the various
stakeholders over the software lifecycle and does indeed satisfy the intended
application/product attributes.
We now have a unique solution “Clean Requirements Solution” that is an
adaptation of HBT to validate requirements.

Validating early stage pre-code artifacts like requirement document is challenging. This is typically done by rigorous inspection and requires deep domain knowledge. One of our Japanese customer threw a challenge – “How can you use HBT/STEM to scientifically validate requirements without knowing the domain deeply?” .

The core aspect of HBT is to hypothesize potential defect types that prove that they do not exist. These are identified by keeping in mind the end users and the technology used to construct the system. So how do you apply this to validate a pre-code artifact?

We commenced by identifying the various stakeholders for requirement document and then identified key cleanliness attributes. These cleanliness attributes if met would imply that the requirements was indeed clean. We were excited by this. We then moved and identified potential defect types that would impede these cleanliness attributes/criteria.

Lo behold, the problem was cracked and we then identified the various types and the corresponding evaluation scenarios for validating the requirements/ architecture document. We came up with THIRTY+ defect types that required about 10+ types tests conducted over TEN quality levels with a total of SIXTY FIVE major requirement evaluation scenarios to validate a requirement.

What we came up is not yet-another-inspection-process that is dependent on domain knowledge, but a simple & scientific approach consisting a set of requirement evaluation scenarios that could be applied with low domain skill to ensure that the requirement/architecture can indeed be validated rapidly and effectively. These ensure that the requirement document is useful to the various stakeholders over the software lifecycle and does indeed satisfy the intended application/product attributes.

We now have a unique solution “Clean Requirements Solution” that is an adaptation of HBT to validate requirements.

Tags: , ,
Posted in Hypothesis-based Testing, STEM | No Comments »

We demystified the automation puzzle. Relentless validation tamed!

Monday, June 28th, 2010

A large global provider of BI solutions has a product suite that runs on five platforms supporting thirteen languages with each platform suite requiring multiple machines to deliver the BI solution. The entire multi-platform suite is released on single CD multiple times a year.

The problem that stumped them was “how to automate the final-install validation of multi-platform distributed product”. They had automated the testing of the individual components using SilkTest, but they were challenged with “how to unify this and run off a central console on various platforms at the same time”.

Considering each platform-combination took about a day, this required approximate two months of final installation build validation, and by the time they were done with this release, the next release was waiting! This was a relentless exercise, consuming significant QA bandwidth and time, and did not allow the team to do things more interesting or important.

The senior Management wanted single-push-button automation -identify what platform combination to schedule next, allocate machine automatically from the server farm, install and configure automatically, fire the appropriate Silk scripts and monitor progress to significantly reduce time and cost by lowering QA bandwidth involved in this effort. After deep analysis, in-house QA team decided this was a fairly complex automation puzzle and required a specialist! This is when where we were brought in.

After an intense deep-dive lasting about four weeks, we came up with a custom master-slave based test infrastructure architecture that allowed a central console to schedule various jobs onto the slaves, utilizing a custom developed control & monitoring protocol.  The solution was built using Java-Swing, Perl, Expect and adapters to handle Silk scripts. Some parts of the solution where on Windows platform while some on UNIX.  This custom infrastructure allowed for scheduling parallel test runs, automatic allocation of machines from a server farm, installing appropriate components on appropriate machines, configuring them and finally monitoring the progress of validation through a web console.

This test infrastructure enabled a significant reduction of the multi-platform configuration validation. The effort reduced from eight weeks to three weeks. We enjoyed this work simply because it was indeed a boutique work fraught with quite a few challenges. We believe that this was possible because we analyzed the challenging problem from wearing a development hat and not the functional test automation hat.

Tags: , , ,
Posted in Case-studies, Hypothesis-based Testing | No Comments »

Validation Suite – An innovative way to leveraging test assets & reducing cost of validation

Monday, June 28th, 2010

The test lifecycle produces rich set of assets-strategy, test scenarios/cases, defects, scripts, test data. Other than using these to validate the current release of product, how are these significantly leveraged in the future? How do these assets enable faster ramp-up, de-skilling, optimize testing? Patterns have been used as a method to extract experience and enable a normal person to behave like an experienced person. Sadly, patterns are not commonplace in test engineering.

Validation Suite is a product from STAG that is similar to patterns. Based on HBT (Hypothesis Based Testing) methodology, it enables identifying potential defect types for common features/construction-components along with a common validation strategy consisting of Quality Levels, Test Types and finally a list of common test scenarios/cases/data. The intent is to ensure that we do not start all over again, and leverage the experience typically encoded as tacit knowledge in the individuals.

STAG has applied this to create specific validation suites in the areas of eLearning, ERP, Bluetooth and Mobile applications. These can reduce the cost of validation by 30% and reduce ramp-up time significantly. The key business benefits are (1) Fast ramp-up (2) Readymade test strategy (3) Higher product quality (4) Faster time-to-market and (5) Lower validation cost.

Validation suite for your product can be created by mining your test assets by applying the HBT methodology to create a structured and rich asset base that provides significant leverage subsequently.

Tags: , , ,
Posted in Hypothesis-based Testing | No Comments »

How many “negative test cases” should there be?

Thursday, April 29th, 2010

Before we answer the question let us ensure that we have common understanding of what is positive or negative test cases. In HBT, positive test cases are those whose input values are valid, while a negative test case is one with at least one of the test inputs (i.e. Test data) being incorrect (i.e. out of specification).

The objective of positive test cases is “conformance” while the objective of negative test cases is “robustness”. If a majority of test case are positive, then it implies that we are primarily interested in conformance i.e. ensuring the system handles correct inputs well. This we know is not sufficient, as accidental incorrect inputs should not result in unexpected possibly risky/dangerous behaviour. Hence we need test cases that are indeed “negative”.

So, coming back to the question, what is a good enough distribution of positive and negative test cases? Any quick answer like 75% should not be trusted as they have no basis. So, how do we answer this question? Step back now and look at the number of inputs for a given test case, the clue is there. For example at a lower level of testing, where say we are validating a screen, the number of inputs may be many as the screen may be populated. As we go up the testing level, e.g. Testing a feature that uses a few screens, the test data is not the various individual inputs on the screen, but aggregate data (think like a record) and these may be fewer in number compared to the earlier levels.

Having understood that the number of test data (or inputs) at lower levels is far higher than those at the higher levels, it is only logical to conclude that the number of negative test cases at lower levels. Now how much should that be?  To answer his finally without resorting to magic (!), let us illustrate with simple example. If there are 5 inputs and each input has six possible values (3 positive i.e. valid and 3 negative i.e. invalid) then using simple combinatorial math, we can see that there be (minimally) 3*5=15 negative test cases and (minimally) 5 positive test cases. In this case the 15/(15+5)= (75%) of test cases are negative.

In closing, understanding the number of inputs and clear understanding of what an input at a testing level is (The STEM Core concept “Input granularity principle” of HBT methodology helps in understanding as what an input at a level is) it is possible to quickly estimate the minimal number of negative test cases. This is very useful in quickly ascertaining whether the test cases are conformance and robustness oriented.

This is covered in “HBT.10: Effective review of test cases”, a title in our HBT Series of workshops

Tags: , , , ,
Posted in HBT Series of Workshops, Hypothesis-based Testing, STEM | No Comments »

Requirements traceability is “Necessary but not sufficient”

Thursday, April 29th, 2010

When asked about “how do you know that your test cases are adequate?”, the typical answer is Requirement Traceability Matrix(RTM) has been generated and that each requirement does indeed have test cases.

Is this logic strong enough? Unfortunately NO! Why? Assume that each requirement had just one test case. This implies that we have good RTM i.e. each requirement has been covered. What we do know is that could there additional test cases for some of the requirements? So RTM is a necessary condition but NOT a sufficient condition.

So, what does it take to be sufficient? If we had a clear notion of types of defects that could affect the customer experience and then mapped these to test cases, we have Fault Traceability Matrix (FTM as proposed by HBT). This allows us to be sure that our test cases can indeed detect those defects that will impact customer experience.

Note that in HBT potential defects types are mapped to the Cleanliness Criteria derived earlier. Cleanliness criteria are those that have to be met to ensure that customer has a good experience with the system.

This is covered in “HBT.10 : Effective review of test cases”, a title in our HBT Series of workshops.

Tags: , , ,
Posted in HBT Series of Workshops, Hypothesis-based Testing, STEM | No Comments »

Effectiveness and Efficiency of test cases

Thursday, April 29th, 2010

Given that we have set of test cases, we would like then them to be effective. What does “effective” mean? Effectiveness of test cases is the ability of the test cases to be able to detect (or uncover) the defects that can affect the customer experience.  So a clear understanding of what *types of defects* are we looking for and a mapping of the test cases to these test cases would enable a scientific way of assessing effectiveness.

What is efficiency? It is ensuring that we execute the test cases in as short a time as possible with optimal effort and no more.  Understanding (1) the priority or business importance of test cases, (2) knowing what test cases to execute in what part of the lifecycle (3) clear segregation of test cases by various types of tests and levels enables to optimize testing and become efficient.

This is covered in our HBT Series of workshop “HBT.10 : Effective review of test cases”.

Tags: , ,
Posted in HBT Series of Workshops, Hypothesis-based Testing, STEM | No Comments »

Landscaping – A STEM Core concept to understanding system & expectations

Thursday, April 29th, 2010

Understanding a system is non-linear process i.e. we have derive a lot of questions that are interconnected and then seek answers individually and then connect the various answers.

Landscaping is a core concept in STEM (STAG Test Engineering Method) that powers HBT (Hypothesis based testing) that lists the various aspects related to the system, customer, marketplace, technology and forces one to connect these concepts. What emanates is like an interesting web of information (aka Mindmap) that enables you to come up with intelligent questions and there enable rapid understanding.

For example, connecting marketplace, with requirements and end-users, one can arrive at the question: “What are the various markets that we are planning to deploy our system and in these markets, who are the various kinds of end user types and what does each one from the system?

To quote a specific instance, a two-liner requirement spawned 40+ questions rapidly, that when clarified allowed us to understand the requirement in about an hour. In fact, this uncovered issues in the product being built, as certain aspects of the requirements were completely missed by the developers in their implementation. It is to be noted that our ability to identify questions and therefore understand were not due our domain skills, it was purely due to the application of HBT methodology powered by the defect detection technology(STEM) to the problem at hand.

This is covered in “HBT.2: Rapid Understanding of customer expectations”, a title in our HBT Series of workshops.

Tags: ,
Posted in HBT Series of Workshops, Hypothesis-based Testing, STEM | No Comments »

Launching two new HBT series of workshops in MAY 2010

Wednesday, April 21st, 2010

STAG is launching two new workshops in the “HBT Series” in May 2010. We thank our participants of Robust Test Design workshop conducted in Chennai, for suggesting that we come with a new workshop for “How to understand customer expectations rapidly” . Thank you!

The workshops are:

  1. Rapid understanding of customer expectations  on May 27, 2010 at Bangalore and on June 7 at Chennai.
  2. Effective review of test cases  on May 28, 2010 at Bangalore and June 8, 2010 at Chennai.

Workshop details:

Rapid understanding of customer expectations (1-day workshop)

Objective: How to rapidly understand expectations/requirements of the software to be validated in a scientific manner.

Target audience: Test manager, Project manager, Test lead, Test Engineers

To test effectively, estimate correctly, a good understanding of the software/application is very important. The act of understanding is a high maturity skill requiring multiple skills. Domain knowledge is seen as a critical enabler to good understanding. Good documentation of the requirements is also a key ingredient. In real life however, the available documentation of requirements/specifications always lacks the details required for effective testing, and is typically not in sync with the software/system being built. Therefore the test staff with their domain knowledge is expected to come up with good questions and clarify the missing elements and understand the intended behaviors. This is easier said that done, as deep domain knowledge is typically a scarce commodity.

This workshop takes a scientific approach to “act of understanding the intentions or expectations” by identifying key elements required of any requirement/specification and identifying a personal process powered by scientific concepts to ensure that we rapidly understand the intentions and identify the missing elements.

The first two stages of Hypothesis-based testing(HBT) methodology focuses on “Understanding expectations” and “Understand context”, this is powered by the “Business Value Understanding” discipline of STEM, the underlying defect detection technology that powers HBT. This discipline employs seven scientific concepts to enable that the various aspects to understand the expectations can indeed be done in a scientific manner.

This has been successfully used by STAG in its engagements to rapidly identify questions to understand expectations. To quote a specific instance, a two-liner requirement spawned 40+ questions rapidly, that when clarified allowed us to understand the requirement in about hour. In fact, this uncovered issues in the product being built,  as certain aspects of the requirements were completely missed by the developers in their implementation. It is to be noted that our ability to identify questions and therefore understand were not due our domain skills, it was purely due to the application of HBT methodology powered by the defect detection technology(STEM) to the problem at hand.

The topics covered in this workshop are:

  • How to create the big picture and get a good overall view (Landscaping)
  • Identifying end users and their needs
  • Identifying business requirements and  corresponding technical requirements
  • Identifying critical attributes and ensuring that they are testable
  • Understanding the usage patterns/operational profile
  • Identifying business risks and prioritization
  • Understanding intended behaviors for designing test scenarios/cases
  • Formulating cleanliness criteria

The participants will be able to create a User type list, Requirement list, Operational profile, Interaction matrix, Cleanliness criteria  and key questions to understanding expectations at the end of this workshop.

The delivery style will be application oriented, an application will be used to illustrate the concepts and the process of doing.

Each participant will be given a HBT cookbook (NEW!) in addition to the workshop slide set and application case study.

Effective review of test cases (1-day workshop)

Objective: How to assess effectiveness, completeness, consistency and future automation-ability of test cases.

Target audience: Test leads and Test engineers

Test effectiveness is a function of the quantity and quality of test scenarios/cases. The difficult  aspect is assessing if the designed scenarios/cases are indeed adequate. As always, a deep domain and technical knowledge is seen as a critical aspect to effectively review the test scenarios/cases. The challenging part is that deep domain/technical skills is always in short supply.

This workshop teaches a scientific approach to assess the quality of test scenarios/cases by applying a goal centered to testing – “What types of defects should I detect”?. Commencing with identification of potential defect types that will impact the customer experience, the designed scenarios/cases are analyzed for fault coverage in addition to requirements coverage. HBT powered by STEM has a clear structure for effective test scenarios/cases (TS/TC) and this is the basis for assessment of the scenarios/cases. The STEM Test Case Architecture (STEM-TCA) architecture slices the scenarios/cases is multiple ways and allows one to see the gaps in the designed scenarios/cases. For example STEM-TCA requires TS/TC to be segregated by potential defect types and then by quality levels and then by test types, by conformance vs robustness, by importance and other attributes. This approach enables a scientific enquiry process and allows one to assess rapidly and effectively without totally relying on the domain knowledge.

STAG has used this successfully in its boutique service offering of “Test case re-engineering” in its engagements to increase coverage(i.e. defect finding ability)  significantly with its customers. One such interesting work is listed in our blog “Re-architecting  test assets increases test coverage by 250%.” In addition, STAG  has used these concepts to assess completeness of TS/TC for its Japanese customers in their “Diagnostics &  control” solution offering.

At the end of workshop you will able to review the designed scenarios/cases rapidly & effectively enabling you to “produce better bait” to catch the fish! I.e defect defects. The information content of test scenarios/cases plays a vital part of in embarking on successful automation to improve efficiencies. Moving from effectiveness, the workshop will be also enable assessing the efficiency aspect of the testing I.e how can I order and deliver design  assets that will enable faster testing. This is addressed in the assessment of TS/TC on the  automation-fitness aspect.

The topics covered in this workshop are:

  • Understanding the goal of TS/TC i.e. what types of defects should we detect?
  • Assessing basic completeness using RTM(Requirement traceability matrix)
  • Understanding the caveat of RTM i.e. it is necessary but sufficient enough
  • Creating fault traceability matrix
  • Understanding the STEM-TCA
  • Identifying information needed for assessment
  • The personal assessment process for effectiveness and efficiency of TS/TC
  • Understanding the distribution of conformation-oriented(positive) vs robustness (negative)oriented over the various levels of test
  • Limitations of black box techniques
  • What information related to internal aspects of the software do I need to know i.e. how to use white box techniques effectively
  • Metrics that are useful to substantiate the assessment like Test breadth, Test depth and Test granularity

The participants will be able to a create clear assessment report with appropriate metrics   to judge the efficacy and efficiency aspects  at the end of this  workshop.

The delivery style will be application oriented implying test scenarios/case of an real-life application will be used to illustrate the concepts and the process of doing.

Each participant will be given a HBT cookbook (NEW!) in addition to the workshop slide set and application case study.

Both these workshops are limited to a maximum of 25 participants on first-come basis. Email learning at stagsoftware dot com for registration or for more information. We are excited about launching these two unique workshops and look forward to interacting with you.

Click here to download the HBT Series of Workshops brochure.

Tags: , , , , ,
Posted in HBT Series of Workshops, Hypothesis-based Testing, STEM | No Comments »

Large scale migration of automation suite – “Scaling the peak”

Thursday, April 15th, 2010

The customer in focus provides data integration software and services that empower organizations to access, integrate, and trust all its information assets, giving organizations a competitive advantage in today’s global information economy. As the independent data integration leader, the customer has a proven track record of success helping the world’s leading companies leverage all their information assets to grow revenues, improve profitability, and increase customer loyalty.

The customer had a large base of automated test scripts (1300) in Rational Visual Test (VT) and a single license of the  Visual Test on a dedicated machine – a risky affair considering that the Visual Test is no more supported and relies on a older version of Windows. They decided to de-risk this to support the newer versions of products and also get rid of limitations existing in the existing test script suite. Some of the limitations of existing automation suite were: (1) Manual dependency to get the scripts run in suite against any new build released,(2) Non-existence of tool support for Visual Test (3) Limitations with respect to support on other flavors of windows operating system and support for internationalization (i18N) (4) Limitations in the framework to extend the scripts with new functional changes and (5) Difficulty in building competency on Visual Test. The management decided to migrate these VT scripts to Borland Silk Test Suite.

Now came the challenges that we had to solve. The test suite was large with only the script available and no documentation on the test cases. They were keen that the performance of the new suite in SilkTest be considerably enhanced. Technically the test suite was intensely data-driven with huge data set to drive the test suite. The automation run was l-o-n-g, ranging from 24-36 hours, necessitating that a robust recovery mechanism be in place to ensure uninterrupted runs with minimal baby-sitting. Since it was a new investment, the management was keen that the automation framework is indeed flexible so that new test cases could be added to the suite quickly. Finally, the suite had to cater to the different language packs of the product.

Phew – It was real challenge “scaling the peak”, and we had our share of issues of encountering bad weather, storms, landslides, but heck we made it! As always, the journey was arduous, but the rush of adrenalin after reaching the peak was great. We must confess that the journey would not been possible without the wholesome support and cooperation from the customer – Thank you.

Now the details of the climb! We had to analyze the large VT suite to understand the structure, flow, data inter-relationship and the finer nuances. Remember that we only had the scripts machine to try and understand! The key learning points and the action items were:

1. Build an effective data-driven mechanism to provide the flexibility to add and maintain test data in external SQL tables.

2. Implement robust delivery mechanism to enable the scripts to run uninterrupted for long durations, upwards of 24 hours.

3. Support for internationalization to enable testing of English and Japanese language packs via external language property files.

4. The ability to add new test cases to the existing framework to support new features and application changes with 50% less effort.

We  approached  the problem of scaling the peak, by firstly going through a strong intellectual process of technical problem analysis and  devising a library-based & data-driven framework and subsequently putting together a factory-driven approach to rapidly code the scripts.  Once we architected the custom framework, we  identified with the “good principles of development”,  such as  avoiding global variables, avoiding hardcoded information, level & depth of documentation, language coding conventions, and finally object referencing and de-referencing strategies. The development process was iterative with multiple milestones identified and acceptance criteria clearly identified.

A skeletal team of architects and specialists got cracking on the problem,  making the first move to built a flexible and robust automation framework. They also commenced development of common library components, that will be used to by the larger extended team later. Once the architecture custom framework was in place, coding standards were enforced, and then these activities of coding the framework and the library components were done. At this point, a larger  team was assembled, each of them was assigned a certain set of scripts  to be converted from VT to SilkTest. The act of coding the newer SilkTest scripts was individually done on developer machines, code-reviewed  and then later integrated on a test  machine,  and tested by running this on the target  application. We did encounter a stormy climb, with myriad integration issues  popping up,  each of them was solved and we continued to make good progress.

The D-day came and we were delighted to hoist the flag on the peak!  We had covered good ground,  generating approximately 50,000 LOC with about fifth of that constituting the framework level component code. The cool air at the peak was refreshing and sweet! -  We had  reduced the cycle time by approximately 80%  i.e.  from FIVE days to just ONE day,  were able to long runs of 24 hours without issues, switched language pack with ease and were able to add a new set of 120 test cases quickly enough. In the  subsequent two months of intense usage only about five issues were reported, which were  fixed.

This was a unique project, where  we had  to migrate automation code from one commercial tool to another with constraints of documentation and machine availability. It was indeed a pleasure to work with a demanding customer, who worked closely with us  to help us understand the product and the VT automation, and also making available a dedicated integration machine with the lone VT server machine.

We have always enjoyed challenges, and we thank the customer for giving us the opportunity and reposing trust in us. This is the fun-part of being a test boutique!

Tags: , , , , , ,
Posted in Case-studies, Hypothesis-based Testing, STAG | No Comments »

“The quality race” – STEM wins

Thursday, April 15th, 2010

A large German major with a mature QA practice is seeking new ways to improve its test practice. It all starts with a talk  delivered at this company on “The Science & Engineering of Effective Testing” to its senior management staff and test practitioners in the company. We are amazed at the interest in this topic (75+ people attend the talk) and the enthusiastic response – we are deeply humbled.

A few weeks after this, the management decides to experiment with STEM-based approach to testing. They identify about twenty five people (a small subset of their QA team) to be trained on the new way of testing. We are delighted and conduct a 5-day workshop with intense application orientation, to enable them to understand STEM. The company then decides to conduct a bold experiment- a pilot to evaluate STEM powered approach to testing vis-a-vis their way of testing. They identify a product that is in use for a few years with consumers across the world. They decide to have two five-member identical teams consisting of similar mix of experience levels of people, each given a timeframe of one month to evaluate the new release of this product. These two teams are  kept apart to ensure a controlled experiment and the countdown starts. We wait with bated breath…

The month is slow for us, but it flies for the two teams. Enormous data has been generated and the management analyses them thoroughly to spot the winner. A month later we are called by the senior management. We are sweating, have we won? A few minutes later, it is clear that STEM is a winner. The STEM powered team has designed 3x test cases compared to the non-STEM team and  uncovered 2x number of defects! The icing on the cake is that the couple of defects uncovered by the STEM powered team are “residual defects” i.e. they have been latent in the product for over a year (Remember Minesweeper game on Windows) and one of them corrupts the entire data in the database. Now the discussion steers to effort/time analysis – Does application of STEM require more effort/time? The team has conclusive evidence that it is not significant, implying STEM has enabled them to think better,  not work longer or more.

What enabled the STEM powered team to win the “Race of quality” ? The answers are given by the team itself, and we are delighted, as we have believed in them, and have seen results when we implement them. The top three reasons are: (1) The notion of Potential Defect Types (PDT) is powerful as it forces the team to hypothesize what can go wrong and enable them to setup a purposeful quality goal (2) PDT forces a thorough understanding of the customer expectations and the intended behavior of the product (3) PDT ensures that test design creates adequate test cases, thus eliminating defect escapes and paving the way for robust software.

The STAG team is delighted as their customer acknowledges the effectiveness of the STEM based approach. The team is convinced that STEM powered approach is a winner and is raring to run the marathon, with the customer also cheering them to win!

A heartfelt “Thank you” to the STEM powered team and the innovation-centered Senior Management of the company.

Tags: , , , , ,
Posted in Case-studies, Hypothesis-based Testing, STAG, STEM | No Comments »

« Older Entries