Rapidly understanding the usage profile

April 29th, 2010

Understanding the rate and number of transactions probably on a real system is critical to ensure that the system is designed well and later sized and deployed well. Good understanding of the business domain is seen as a key enabler to arrive at the usage profile.

Operational profiling (A STEM core concept) is a scientific way to quickly arrive at a real life profile of usage. Good understanding of this concept alleviates the problem of lack of deep domain knowledge to understand the usage profile. This core concept consists of these key aspects:

  1. Mode – Represents a time period of usage e.g. End of month, where the usage patterns are distinctive and different.
  2. Key operations (features/requirements) used
  3. Types of end users associated with the key features/requirements
  4. Number of end users for each type of users
  5. Rate of arrival of transactions

In short, for a given mode, identify the end users types and their key operations and then identify the number of users for each type of user and then identify the rate of arrival of transaction. Employing this core concept allows us to think better and ask specific questions to understand the marketplace and the usage profile in a typical and worst-case scenario.

This allows us to get a better understanding of the usage and helps in identifying business risks and derive an effective strategy.

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, STEM | No Comments »

Landscaping – A STEM Core concept to understanding system & expectations

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

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”

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

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 »

10x reduction in post release defects – Finest experience of applying STEM

April 15th, 2010

This is about one of the finest experiences that STAG had with a global chip major where the early implementation of STEM yielded significant results. Our engagement with them was to setup an effective validation practice for their porting level API for video decoders. The customer had a great technical team and were involved in both development and QA. The challenge that they faced with their complex product that involved both hardware and software and later system integration on multiple real time OS on various platforms, was that of high defect escapes i.e. post-release field defects.

We spent about a month understanding their domain and the associated technologies. Post this, a detailed analysis yielded interesting data – test cases were primarily conformance oriented, coverage of test cases was suspect, escaped defects seem to propagate from early stages and finally the process of validation was loose.

Having understood the types of defects that were being found and the post-release defects, we figured out the various types of probable defects and the various combinatorial aspects that need to be considered to form a test case. We then staged the validation as consisting of three major levels, the first one at API level, then the next one at a system level, and the last level made up of a customer-centric level that involved using reference applications.

Applying the STEM approach to test design, the test cases were developed, yielding about 6000 test cases at level one and about 800 at the subsequent levels. Also, whereas the ratio of +ve vs –ve test cases was earlier towards the +ve side, after our re-design, the ratio shifted to 60%:40% at the lower level and about 85% :15% at the higher levels. Moreover, the test cases increased in number significantly by a factor of 1000%, allowing for a larger and deeper net to catch many more serious defects. Over the next 9 months, the rate and number of defects detected increased dramatically, resulting in post-release issues reducing by a jaw-dropping 10x times.

Once we solved the test effectiveness problem and increased the yield of defects, the focus shifted to streamlining the process by setting up proper gating in the test process and creating a centralized web based test repository, and finally setting a strong defect analysis system based on Orthogonal Defect Classification (ODC) method. This enabled a strong feedback system, resulting in shifting the defect finding process to earlier stages of SDLC and thereby lowering cycle time. Complementing this, we focused on setting up a custom tooling framework for automating this non-UI based software resulting in a significant cycle time reduction – an entire cycle of tests on a platform took less than 15 hours of time!

This has been one of the finest experiences that we had with STEM, and was a clear winner for STEM implementation. This was only possible because of the very mature engineering management staff of the customer, who were focused on systemic improvement and had systematic improvement goals.

What is to be noted is that our test team was NOT a team with significant depth of experience on the particular product domain. Applying STEM at a personal level, the team was able to understand what was necessary and sufficient for effective validation and complemented the strong technical team with mature defect-oriented thinking. This was an early case study for us to establish that a STEM based approach provided us with the right thinking skills for defect finding, rather than resort to a domain centric approach to defect finding.

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

Re-architecting test assets increases test coverage by 250%

April 15th, 2010

This company is an innovative online banking solution provider, having three major products catering to over 100 top financial institutions(FI) of the world including the top five FI in the world. They have a very successful product line, growing rapidly, with major releases approximately every year, incorporating new features to cater to the various needs of the market place. As the code base evolved, the test assets were also modified to reflect the changed product. The challenge faced was that the most of the test cases were passing and the rate of uncovering new defects was low.

The product became huge and the company decided to re-architect the product in order to enable rapid feature addition with low risk. That is when the company decided to re-look at its test assets and re-architect the same to increase the test coverage, improve defect finding ability and ensure that the test assets were future-proof. It had about 8000 test cases then.

We were chartered to analyze the existing test cases for completeness and modifiability and re-architect the same after filling the gaps and to ensure that the future test cases were easily pluggable. Applying STEM, we performed a thorough assessment of the existing test assets and discovered holes in the same. Using the STEM Test Case Architecture (STEM-TCA), we re-engineered the test cases by firstly grouping them into features, then by levels of tests and segregating into various types of tests and then finally by separating into positive and negative test cases. During this process of fitment of existing of test cases into the STEM-TCA, we uncovered quite a few holes. These were filled by STAG by designing 5000 test cases additionally. Not only did the STEM-TCA increase the test coverage by uncovering the missing test cases, it also provided a sharper visibility of the quality as the test cases were well organized by specific defect types. This improved the test coverage by about 250% and the technical management staff were confident about the adequacy of test assets and were also convinced about its future upgradeability and maintainability.

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

STAG clears the ISO 9001:2008 surveillance audit

April 15th, 2010

STAG Software was certified by TÜV NORD – One of the world’s largest international inspection organization in Germany, for applying the management system – EDeN, in accordance with the ISO 9001:2008 standards, early 2009. The certificate provides for the scope of “Provision of Software Test Engineering Services, Training and Consultancy Services to Produce Clean Software”.  Last month, we successfully cleared the surveillance audit for the same.

Excellence Delivery Network or EDeN, goes beyond the typical quality system. It ensures every activity of different functions in STAG are focused towards delivering excellence by being customer focused, highly responsive (agile), result-oriented.

Tags: ,
Posted in STAG | No Comments »

IP Solutions from STAG

April 15th, 2010

STAG is a test boutique -  we have some unique IP solutions to enable your engineering team to do their jobs validate better. These solutions are delivered by STAG using a consultative approach ensuring effective deployment to yield real business results.

Some of the solutions are:

  1. A method for validating requirements – Enabling organization to ensure that requirements are indeed clean and thereby lower validation time, effort and costs
  2. Scientific architecture validation – Enabling organization to validate design and ensuring it can meet the promise of the delivered software.
  3. A method for LSPS (Load, Stress, Performance & Scalability) validation- Enabling your organization to setup a scientific system for validation LSPS aspects of software/system.
  4. UT/IT assessment – Enable your organization to setup an effective early stage validation practice
  5. Test strategy & planning – Enabling the organization to setup a result-oriented strategy formulation and scientific  effort estimation

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

NEW! HBT Series of Workshops

April 15th, 2010

From the inception, STAG has been passionate in transforming people, conducting specialized workshops on test engineering. The Knowledge Services division provides corporate and retail education solutions. Recently STAG has launched the “HBT Series of workshops”. All these workshops have been developed using the HBT methodology, and provides a scientific way to doing things. The delivery style is application oriented, ensuring participants are shown application of these concepts and try the same in the workshop.

The various titles in the HBT Series of workshops are:

  1. HBT – A engineering approach to producing clean software (4d)
  2. Rapid understanding of customer expectations
  3. Purposeful test strategy and planning
  4. Practical test effort estimation
  5. Robust test design
  6. Devising meaningful measurements
  7. Result oriented automation
  8. Intelligent regression testing
  9. Effective review of test strategy/plan
  10. How to review test cases effectively
  11. Effective developer testing
  12. LSPS testing (Load, Stress, Performance & Scalability)
  13. RRE Testing (Robustness, Reliability & Endurance)

.. our workshops delivers results

We trained a large set of developers of large US financial major, with a specific objective of enhancing development delivery quality. A few months later, we were delighted  to hear from the CTO that defect escapes from Dev to QA has dropped by 30%. Mind you, this is the developer community doing testing!

A second instance was a that of IT division  of a Australia-based bank where we trained a large number staff and followed up with implementation. Their issue of elongation of acceptance  of product by their customer became history!  And the post-release support issues dropped over time.

Click here to download the HBT Series of Workshops brochure.

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

« Older Entries
Newer Entries »