Tuesday, 25 February 2014

Software Testing into a High-Performance Organization

How to Turn Software Testing into a High-Performance Organization
http://www.sqatester.com/images/pix.gif
___________________

http://www.sqatester.com/images/pix.gif




I
ntroduction

Testing is often looked upon by many as an unmanageable, unpredictable, unorganized practice with little structure. It is common to hear questions or complaints from development such as:

-What is testing doing?
 
-Testing takes too long
 
-Testers have negative attitudes
 

Testers know that these complaints and questions are often unfair and untrue. Setting aside the development/testing debate, there can always be room for improvement. The first step in improving strategy and turning a test team into a higher performance test team is getting a grasp on where you are now! You want to know:

-What testing is effective?
 
-Are we testing the right things at the right time?
 
-Do we need a staffing upgrade?
 
-What training does our team need?
 
-How does the product team value the test effort?
 

In this article we provide a framework for assessing your team, including: how to plan for an assessment, how to execute the assessment and judge your current performance, what to do with the information, and how to chart an improvement plan toward higher performance.

The Test Process Assessment

The goal of doing a test process assessment is to get a clear picture of what is going on in testing, the good things, the problems, and possible paths to improvement. Fundamentally, a test assessment is a data gathering process. To make effective decisions we need data about the current test process. If done properly; the assessment will probably cross many organizational and management boundaries.

It is important to note when embarking upon such an assessment that this effort is much larger than the test team alone. Issues will arise over who owns quality as well as what is the goal of testing? It is also important to note that a possible result of the assessment is that work may actually increase. There may be:

-More demands for documentation
 
-More metrics
 
-More responsibility for communication and visibility into testing
 

For such an assessment process to succeed requires:

-Executive sponsorship
 
-A measurement program
 
-Tools to support change
 
-An acceptance of some level of risk
 
-Avoidance of blaming testing for project-wide failures
 
-Commitment about the goal of testing
 
-An understanding of testing or quality assurance across the product team
 
-Responsibility for quality
 

Components of a Test Strategy - SP3

A test strategy has three components that need to work together to produce an effective test effort. We have developed a model called SP3, based on a framework developed by Mitchell Levy of the Value Framework Institute. The strategies (S) components consist of:

-People (P1) - everyone on your team
 
-Process (P2) - the software development and test process
 
-Practice (P3) - the methods and tools your team employs to accomplish the testing task
 

Phase 1 Pre-Assessment Planning:
 The goals for this phase are to set expectations, plan the project, set a timeline, and obtain executive sponsorship. The actions that occur in phase 1 include meeting with the management of various groups, laying out expectations for the results of the process, describing the plan, and establishing a timeline. The intended result is to obtain agreement on expectations and buy-in on the assessment process and follow-up commitment for improvement. The phase 1 deliverable is a schedule and a project plan.

In phase 1 it is important to:

-Get executive buy-in
 
-Make a schedule and stick to it
 
-Give a presentation of what you are doing, why and what you hope to get out of it
 
-Make a statement of goals or outline of work as a commitment
 
-Make a scope document a pre-approval/budget deliverable
 

It is important to note up front that assessment is only the beginning of the process.

Phase 2-Information Gathering:
 The goal of phase 2 is to develop interview questions and surveys which become the backbone of your findings. Actions in phase 2 include gathering documentation, developing interview questions, and developing a test team survey. The result of this phase is that you will be ready to begin your assessment using the documentation, interview questions, and test team survey. The deliverables include complete development process documentation, interview questions, and the tester survey.

Examples of the documentation to be collected include: SDLC documentation, engineering requirements documentation, testing documents (test plan templates and examples, test case templates and examples, status reports, and test summary reports). Interview questions need to cover a wide range of issues, including (but not limited to): the development process, test process, requirements, change control, automation, tool use, developer unit testing, opinions about the test team from other groups, expectation of the test effort, political problems, communication issues, and more.

Phase 3-Assessment:
 The goal of phase 3 is to conduct the interviews and develop preliminary findings. Actions include gathering and reviewing documentation, conducting interviews, sending out and collecting the surveys. As a result of this phase there will be a significant amount of material and information to review.

Phase 4-Post-Assessment:
 The goal of phase 4 is to synthesize all of the information into a list of findings. Actions include reviewing, collating, thinking, forming opinions, and making postulations. The result of this phase is that you will develop a list of findings from all of the gathered information, reviewed documentation, interviews, and the survey. The phase 4 deliverable is a list of findings, collated survey answers, collated interview responses, a staff assessment, and a test group maturity ranking.

The findings can be categorized into:

-People
 
- Technical skills
 
- Interpersonal skills
 
-Process
 
- Documentation
 
- Test process
 
-SDLC
 
- Practice
 
- Strategy
 
-Automation
 
- Environment
 
- Tools
 
More subcategories may also be developed to suit your needs.

Phase 5-Presentation of findings with project sponsor, executive sponsor and team:
 The goal of phase 5 is to present preliminary findings to executives and the project sponsor, and to obtain agreement on the highest priority improvement areas. It is important in this phase to be prepared for a very different interpretation of the findings than you perceived. The deliverable for phase 5 is an improvement roadmap.

Phase 6 -Implementation of Roadmap:
 The goal of phase 6 is to establish goals with timelines and milestones and sub tasks to accomplish the tasks agreed upon for improvement. The action of phase 6 is to develop a schedule for implementation of the improvement plan. It is helpful at this point to get some aspect of the project implemented immediately so people can see tangible results right away-even if they are the smallest or easiest improvement tasks. The deliverable for phase 6 is implementation of items in the roadmap for improvement according to the developed schedule.

Conclusion

A test strategy is a holistic plan that starts with a clear understanding of the core objective of testing, from which we derive a structure for testing by selecting from many testing styles and approaches available to help us meet our objectives. Performing an assessment helps to provide the "clear understanding" and "understanding of the core objective of testing". Implementing the resulting roadmap for improvement can help to substantially improve the performance of your software testing organization and help to solidify your test strategy.

Wednesday, 12 February 2014

SAP Bank Analyzer Implementation Strategy -High Level Implementation / Overview (High level Process)



 SAP Bank Analyzer –

This article will explain best approach and Implementation approach for the SAP Bank Analyzer solutions, upgrade or integration. Recently I've had opportunity to work on two demo solutions for a banking system SAP Bank analyzer implementation within risk and profit analyses team and a short term test strategy development for rapid SAP bank analyzer implementation within an investment bank.

This article will explain best approach to implement SAP Bank Analyzer solution 8.0 or  upgrade from or integration. Recently we worked on two demo solutions for a banking risk system SAP Bank analyzer implementation within risk and profit analyses team and a short term test strategy development for rapid SAP bank analyzer implementation within an investment bank.


In next couple of blogs we will detail an effective way to test SAP Bank analyzer and its individual components.

 - SAP BA - Objectives in upgrade and in new Implementation Solution Architecture to  future looking business Architecture      
      

As IS Approach- There could be two scenarios either – Accounting IFRS implementation or risk architecture – see below diagram for both .. the Accounting IFRS implementation (accounting consequence, FSPL scenarios)



B) Risk architecture scenario



 
Transformation, and loading process (ETL process).  The SDL saves, consolidates, and manages the original data. At the same time it provides interfaces to additional operational systems.
The primary objects of the Source Data Layer (SDL) and their scenario versions are a flexible way of saving master data, flow data, and market data. They also group this data into units that belong together logically from a business perspective. This ensures that the Bank Analyzer components that are linked to the SDL have a standard, consistent data source.In addition to storing primary object data, the SDL provides the following primary objects functions for applications linked to it:
 See SDN for more detail

●     Access to source data
●     General functions for source data layer
●     Methods for source data
●     General access to corrections
●     Tools
 
Integration
The SDL provides both the central original data basis and a part of the underlying infrastructure for linked applications. It is therefore a key element in ensuring the consistency of data and results.
 <To be updated soon) - if you need detail document, please email your request

 Category 1 - Business transactions

  • Post external business transactions
  • Update secondary business Transactions

Category 2 - Date valuation
 
  • Key date valuation for all financial positions
  • Financial Positions for Period (PICC) event processing etc
  • Update costing for period before GL and during transferring GL documents
  • Calculation for all PICC
  • Balance carry forward etc..  Create FT and BT, Period Open( Previous year),Set the posting date,register contract, Open new fiscal and End-of -day processing before you click on Execute BCF

Category 3 – SAP GL Postings

  • GL Connector and document generation – Journal and document review and finance reconciliation of the GL, Profit centre and any material code posting review
  • Balance processing step 1 - (SV)
  • Balance processing step 2 - (ATP)

Testing of the accounting for FI with Aggregation (AFI) for Accounts Results before RDL and GL
Category 1 – position management
  • Generate Finance Instruments position
  • Aggregate Financial Transactions
  • Prepare Business Transactions for Aggregation
  • Process Reassignments for Business Transactions
  • Aggregate Business Transactions
  • Aggregate Current Accrual Results
  • Process Reassignments for Accrual results
  • Aggregate Retroactive
  • Accrual Results
  • Derive Application Events for source data aggregation

Imported Sub-Ledger Documents (ISD) for Results
 ISD sub-ledger import
- Please email if you need full info ....
 




 

Saturday, 8 February 2014

Planning review process in test management

1. Reviews
Terms

Audit, IEEE 1028, informal review, inspection, inspection leader, management review, moderator, review, reviewer, technical review, walkthrough.
1.1 Introduction
A successful review process requires planning, participation and follow-up. Training providers will need to ensure that test managers understand the responsibilities they have for the planning and follow-up activities. Testers must be active participants in the review process, providing their unique views. They should have formal review training to better understand their respective roles in any technical review process. All review participants must be committed to the benefits of a well-conducted technical review. When done properly, inspections are the single biggest, and most cost-effective, contributor to overall delivered quality. An international standard on reviews is IEEE 1028.
1.2 The Principles of Reviews
A review is a type of static testing. Reviews frequently have as a major objective the detection of defects. Reviewers find defects by directly examining documents.
The fundamental types of reviews are described in section 3.2 of the Foundation Level Syllabus (version 2005) and are listed below in chapter 6.3.
All types of review are best executed as soon as the relevant source documents (documents which describe the project requirements) and standards (to which the project must adhere) are available. If one of the documents or standards is missing, then faults and inconsistencies across all documentation cannot be discovered, only those within one document can be discovered. Reviewers must be provided with the document to be reviewed in adequate time to allow them to become familiar with the contents of the document.
All types of documents can be subjected to a review, e.g. source code, requirements specifications, concepts, test plans, test documents, etc. Dynamic testing normally follows a source code review; it is designed to find any defects that cannot be found by static examination.
A review can lead to three possible results:
·                                 The document can be used unchanged or with minor changes
·                                 The document must be changed but a further review is not necessary
·                                 The document must be extensively changed and a further review is necessary
The roles and responsibilities of those involved in a typical formal review are covered in the Foundation Syllabus, i.e. manager, moderator or leader, author, reviewers and scribe. Others who may be involved in reviews include decision makers or stakeholders, and customer or user representatives. An additional optional role sometimes used in inspections is that of a reader, who is intended to paraphrase sections of the work product in the meeting. In addition to review roles, individual reviewers may each be assigned a defect-based role to look for particular types of defect.
More than one of the review types may be employed on a single product. For example, a team may hold a technical review to decide which functionalities to implement in the next iteration. An inspection might then be performed on the specifications for the included functionalities.
1.3 Types of Reviews
The Foundation Syllabus introduced the following types of review:
·                                 Informal review
·                                 Walkthrough
·                                 Technical review
·                                 Inspection
Hybrids of these types of reviews may also occur in practice, such as a technical review using rule sets.
1.3.1 Management review and audit
In addition to the types mentioned in the Foundation Syllabus, IEEE 1028 also describes the following types of review:
·                                 Management review
·                                 Audit
The key characteristics of a management review are:
·                                 Main purposes: to monitor progress, assess status, and make decisions about future actions
·                                 Carried out by or for managers having direct responsibility for the project or system
·                                 Carried out by or for a stakeholder or decision maker, e.g. a higher level manager or director
·                                 Checks consistency with and deviations from plans, or adequacy of management procedures
·                                 Includes assessment of project risks
·                                 Outcome includes action items and issues to be resolved
·                                 Participants expected to prepare, decisions are documented
Note that test managers should participate in and may instigate management reviews of testing progress.
Audits are extremely formal, and are usually performed to demonstrate conformance to some set of expectations, most likely an applicable standard or a contractual obligation. As such, audits are the least effective at revealing defects.
The key characteristics of an audit are:
·                                 Main purpose: provide independent evaluation of compliance to processes, regulations, standards etc.
·                                 A lead auditor is responsible for the audit and acts as the moderator
·                                 Auditors collect evidence of compliance through interviews, witnessing and examining documents
·                                 Outcome includes observations, recommendations, corrective actions and a pass/fail assessment
1.3.2 Reviews of particular work products
Reviews may be described in terms of the work products or activities that are subject to reviews, such as:
·                                 Contractual review
·                                 Requirements review
·                                 Design review
o                                                        preliminary design review
o                                                        critical design review
·                                 Acceptance review / qualification review
·                                 Operational readiness review
A contractual review may be associated with a contract milestone, and would typically be a management review for a safety-critical or safety-related system. It would involve managers, customers and technical staff.
A requirement review may be a walkthrough, technical review or inspection, and may consider safety and dependability requirements as well as functional and non-functional requirements. A requirement review may include acceptance criteria and test conditions.
Design reviews are typically technical reviews or inspections, and involve technical staff and customers or stakeholders. The Preliminary Design Review proposes the initial approach to some technical designs and tests; the Critical Design Review covers all of the proposed design solutions, including test cases and procedures.
Acceptance reviews are to obtain management approval for a system. This is also referred to as a Qualification Review, and is normally a management review or audit.
1.3.3 Performing a formal review
The Foundation Syllabus describes six phases of a formal review: planning, kick-off, individual preparation, review meeting, rework and follow-up. The work product to be reviewed should be appropriate for the qualification or the reviewer, e.g. a Test Plan for a Test Manager, a business requirements or test design for a Test Analyst, or functional specification, test cases or test scripts for Technical Test Analyst.
1.4 Introducing Reviews
In order for reviews to be successfully introduced into an organization, the following steps should occur (not necessarily in this order):
·                                 Securing management support
·                                 Educating managers about the costs, benefits and implementation issues
·                                 Selecting and documenting review procedures, forms and infrastructure (e.g. reviews metrics database)
·                                 Training in review techniques and procedures
·                                 Obtaining support from those who will be doing reviews and having their work reviewed
·                                 Executing pilot reviews
·                                 Demonstrating the benefit of reviews through cost savings
·                                 Applying reviews to the most important documents, e.g. requirements, contracts, plans etc.
Metrics such as reducing or avoiding cost of fixing defects and/or their consequences may be used to evaluate the success of the introduction of reviews. Savings may also be measured in elapsed time saved by finding and fixing defects early.
Review processes should be continually monitored and improved over time. Managers should be aware that learning a new review technique is an investment – the benefits are not instant but will grow significantly over time.
1.5 Success Factors for Reviews
There are a number of factors that contribute to successful reviews. Reviews need not be difficult to perform, but they can go wrong in various ways if factors such as these are not considered.
Technical factors
·                                 Ensure the defined process for the review type is followed correctly, particularly for more formal types of review such as inspection
·                                 Record the costs of reviews (including time spent) and benefits achieved
·                                 Review early drafts or partial documents to identify patterns of defects before they are built into the whole document
·                                 Ensure that the documents or partial documents are review-ready before starting a review process (i.e. apply entry criteria)
·                                 Use organization-specific checklists of common defects
·                                 Use more than one type of review, depending on objectives, such as document cleanup, technical improvement, transfer of information, or progress management
·                                 Review or inspect documents on which important decisions will be made, for example, inspect a proposal, contract or high level requirement before a management review authorizing major expenditure on the project
·                                 Sample a limited subset of a document for assessment not clean-up
·                                 Encourage finding the most important defects: focus on content not format
·                                 Continuously improve the review process
Organizational factors
·                                 Ensure managers allow adequate time to be spent on review activities, even under deadline pressure
·                                 Remember, time and budget spent are not in proportion to the errors found.
·                                 Allow adequate time for rework of defects identified by reviews
·                                 Never use the metrics from reviews for individual performance appraisal
·                                 Ensure that the right people are involved in the different types of review
·                                 Provide training in reviews, particularly the more formal review types
·                                 Support a review leader forum to share experience and ideas
·                                 Ensure everyone participates in reviews and everyone has their own documents reviewed
·                                 Apply the strongest review techniques to the most important documents
·                                 Ensure a well-balanced review team of people with different skills and backgrounds
·                                 Support process improvement actions must be supported to address systemic problems
·                                 Recognize improvements gained through the review process
People issues
·                                 Educate stakeholders to expect that defects will be found and to allow time for rework and rereview
·                                 Ensure the review is a positive experience for the author
·                                 Welcome the identification of defects in a blame-free atmosphere
·                                 Ensure comments are constructive, helpful and objective, not subjective
·                                 Do not review if the author does not agree or is not willing
·                                 Encourage everyone to think deeply about the most important aspects of the documents being reviewed


SAP S/4HANA -Financial Services for Intelligent Enterprise - IFRS

About Us- SAP TAO Ltd - IT Consulting & Services

 SAP TAO Ltd - IT Consulting & Services SAP TAO is a specialist provider of SAP and Non SAP software development and SAP Enterprise int...