Archive for May, 2013

SAP BW 7.3 Certification: An Approach to get Success!

May 27th, 2013

SAP BW 7.3 Certification: An Approach to get Success!


I recently passed my certification with 97% and want to share my experience as well as preparation techniques with those, who want to be certified in BW7.3

In this blog, I will share with you the textbooks, preparation and the certification test experience for BW7.3 Certification exam.

C_TBW55_73 is the certification offered by SAP to test the knowledge in the area of Business Intelligence.  It verifies knowledge in modelling as well as data management with SAP BW 7.3 and BI 4.0.

Exam Details

The total duration of the exam is 180 minutes. It is divided into 10 sections spanning across BW & BI with BW having maximum weightage around 70 – 75% and BI around 25 – 30%. Below is the deep dive into the sections, topics in the descending order of weightage.

  • InfoProviders – 20 – 25%
  • Data Modelling – 10 – 12%
  • Reporting Tools – 10 – 12%
  • Administration & Performance – 10%
  • Data Flows – 10%
  • Source Systems – 10%
  • Fundamentals – 8 – 9%
  • BI Platform – 7 – 8%
  • BODS – 6 – 7%
  • InfoObjects – 5%

Sections with Higher Complexity:

Out of the 10 sections listed above, challenging and in depth questions will be from those listed below. These questions test your understanding of the concepts as well as your practical experience.  The sections are listed below in the descending order of complexity:

1) Administration & Performance

2) InfoProviders

3) Data Modelling

4) Data Flows

Majority of the questions are scenario based and it is recommended to read the question thoroughly before answering. Main focus is on InfoCubes, DSOs, MultiProviders, InfoSets and Master Data Characteristics. Have a thorough understanding about each and every detail about them to ensure success in these areas as they cover at least 50% of the overall weightage.

Books required for the above sections are:

BW310 (Units 3, 4, 6, 8 and 9) & BW330 (Units 5 to 9).

Practical knowledge is highly recommended.

Sections with Low to Medium Complexity:

The questions that come from the below listed sections are generally with low to medium complexity and high level knowledge shall be enough to pass through:

1) BI Platform


3) Reporting Tools

4) Fundamentals

5) Source Systems

6) InfoObjects

Books required for these sections:

BO100, BODS, 310 (Units 1, 2, 5 and 7) & 330 (Units 1, 2, 4, 10 & 11).

Refer Exam Domain, SDN for topics such as delta management, open hub destinations, managing BI roles, authorizations and publications. Questions on these sections verify the basic understanding such as use cases, compatible sources of various BOBJ reporting tools etc. and are very straight forward.

Final Summary

Overall, here is the quick summary:

1)      Level of difficulty greatly depends on ones efforts towards the preparation

2)      Read all the books provided thoroughly, recommended at least 3 end to end readings.

3)      Read every detail in the books BW310 & BW330, do not skip any topics

4)      Practise your exercises

5)      Utilize the “Flag for review” option in the exam for the questions which you are not sure. This gives you a chance to focus only one those marked, later during your review

6)      Take quizzes and exams in Exam Domain which prepares you for the real exam and also helps identify areas which you need more focus

7)      Visit SDN for examples and detailed explanation for topics which you feel there is no adequate detail in the books.

About Author:

HG is a Sr. SAP BI resource and has completed her training under IIBS SAP BI program. She can be reached through IIBS front desk, if needed.

Additional resources:–modeling-and-data-management-with-sap-bw-73–sap-bi-40-g/topic-areas/

Software Testing: Blunders to Avoid

May 24th, 2013

Software Testing: Blunders to Avoid

Source: Internet

With software defects and bugs being widespread and unprecedented, Software Testing today is a major component in the software development life cycle to ensure that the application is free from any defects before it can be released. Although testing is a never ending process which needs to be carried throughout the development process, however; many software testers still make some mistakes during the testing phase.

1. No Dedicated/Professional Tester
Many software testing firms lack a dedicated software tester and testing is either done by developers or by business analysts. With a tight testing deadline, developers will rush through the testing process and overlook “semantic or syntactic bugs” as such bugs can only be detected by a professional tester. Thus, it is important to have a dedicated team of professional testers in the organization.

2. Inadequate time for testing
Delays in the upstream phases such as the design or implementation phase results in a shortened timeframe for testing. Thus, in order to meet the testing deadline, testers rush through the process and this result in buggy software. The need to give sufficient time for testing and advised testing firms to re-plan the product’s release when a project is delayed.

3. Start testing after coding and UT (Unit Testing) is completed
In order to reduce 20 to 30 per cent defects in an application, testers should begin testing the application once there is a requirement. The agile methodology, instead of testing the functions according to the expectations of the programmer, the requirements are being fulfilled as specified. The requirements should flow at the same time in the development team as well as the testing team, thus testing firms are suggested to follow Waterfall or V nidel methodology.
4. Not implementing traceability across the life cycle
Although, testers don’t need to measure 100 per cent coverage, however whatever measure has been made should be done objectively and scientifically. Thus, it is vital to use a Test Management System (TMS) and to apply two – way traceability.
5. Not analyzing the defects found in any of the testing to determine the cause
Only after identifying the root cause of the defect, a tester can fix the problem. Thus a  Root Cause Analysis will help in reducing the number of defects in the upcoming software releases. The RCA analysis should be conducted not only at the end of the release but also after each test phase.