After successfully attempting the ISTQB certification exam, I received many emails, calls and requests from my acquaintances regarding guidance of the certification in last few days. So, in this blog post I am going to share the material and few tips to prepare for the ISTQB certification exam as I promised in second last blog post ISTQB Certification Exam Registration in Pakistan.

ISTQB certification Foundation level (CTFL_001) exam is a 1 hour long computer based test (CBT) consists of 40 MCQs and all having same weightage without negative marking. You need to answer at least 26 (65%) questions correctly to pass the exam and get the certification. It’s not a very hard figure for a foundation level exam but it’s not easy as well due to very similar answer options for every question.
For exam preparation, I will suggest following two preparation methods:
1. ISTQB Book Reading
2. Solve Practice Questions

ISTQB provides following syllabus book for the foundation level exam

All the exam questions are based on this book topics. But topics are not covered in details in this book and mostly mentioned in bullets only. I tried to study this book but loose interest in beginning. One of my friends shared another ISTQB book (which is probably paid one) and it contains same contents but in more details and in a very interesting way. You can download this book from here:

There are 6 chapters in this book and exam questions are divided among these 6 chapters as per their importance. Please find below list of chapters and questions distribution:


I will recommend first thoroughly read this book and solve all its exercise and practice questions. It will take you approximately 3-4 hours to completely read a chapter and grasp its concepts.
Once you have completed the book reading then try to solve as many practice questions as possible. You can get few Practice questions from following links:
Following is another link of few practice questions and they are really helpful in understanding the concepts and exam preparation.

Once you have studied the ISTQB book and have solved the practice question, you can confidently attempt the exam and can pass it with good score. Best of luck for your ISTQB certification exam and please let me know if you need further information. I am waiting to hear back from my readers regarding their successful ISTQB certification attempt.


Academic discussions are always great source of learning and enhancing your knowledge. Few days back, I had a discussion with a colleague regarding difference between Concurrent and Simultaneous users. Mostly such discussion ended up without a conclusion as there isn’t any bookish definition of these.

Concurrent and Simultaneous users are performance testing terms which are very frequently used interchangeably. Very few people are aware of their difference. My point was, users performing same activity at the same time are concurrent users while users performing different activities on same application at same time are simultaneous user. But my colleague had different view point.

To verify our point of view, we ask Google and almost all the links were seconding my point of view but then we find a post!topic/LR-LoadRunner/fZFjXlgwZqk with James Pulley ( comment and he seconds my colleague’s point of view. As James is an authority in performance testing and its never easy to object his view point. Then we reached to Wilson Mar ( and he also confirmed my friend’s and James Pulley’s view point.

So the conclusion is, user’s accessing same application functionality at same time are simultaneous users and we can implement this concept in LoadRunner with Rendezvous point insertion. While concurrent users are those accessing same application different features at same time.

That was really a fun activity and we both really enjoyed it.

How often you do such educational discussions and what you learn from them?

ISTQB (International Software Testing Qualification Board) is the most prestigious software testing qualification certification organization around the globe. It has issued more than 300, 000 certifications in 70 countries worldwide with approximately 12, 000 certifications per quarter.  ISTQB has three levels of certification: Foundation, Advanced and Expert Level. Passing the ISTQB certification is an honor for a tester which not only ensures he/she has the knowledge and skills of the field and also opens up doors for new opportunities.

It’s nice to see IT specialist in Pakistan including QA/QC professional are focusing on certifications. I know many people want to be certified but give up the race due to unavailability of some basic information like registration and preparation material of the certification. Few days ago, I went through the process of registering myself for the ISTQB certification and thought to share my experience with my readers which might be useful for them. Following is the step by step process of scheduling the ISTQB Foundation Level certification exam in Pakistan.

    1. Go to Pearson VUE ( website who conducts the ISTQB certification exam in Pakistan
    2. Now register yourself to Pearson VUE website. But you would be surprised there is a Sign In link available but not the Registration
    3. To register, click on Sign In and select Information Technology (IT) as Category and iSQI as Testing Program


    4. Click on “Create a web account.” Link and complete your profile

    5. Click on “Schedule Your Exam Now” link

  • ISTQB_02
  • 6. Select the Exam (CTFL_001) and its language (English)

  • ISTQB_03
  • 7. Locate the test centre by providing the Country, City and Province (from optional Country drop down) and click on “Search” button

  • ISTQB_04
  • 8. Select your preferred test center (Al- Khawarizmi Institute of Computer Science as other four are India based) and click on “Next” button.

    9. Select the test date and time (this can be rescheduled as well before 24 hours of the test date as I have done this few times

    • ISTQB_05
    • 10. Click on Next button to submit the payment ( EUR 150 )through your credit card and complete your registration process.


    • But unfortunately you will not be able to submit the certification fee as it will give you invalid credit card error. The reason is, unluckily Pearson VUE does not accept any payment from Pakistan unless you verify your credit card by calling at one of its regional office ( other way is to go to Pearson VUE test center and submit the registration fee there. But they will first convert Euro into dollars and will charge you approximately 5+ from the open market dollar rate.

      So what are you waiting for? Follow the above steps and get registered for the most renowned testing certification of the world. In my subsequent blog post, I will share the ISTQB preparation guidelines and its study material.

Effective planning is key for the success of any software development project especially the one on which various teams are working concurrently. I studied few project management courses during my university days but I always had some gut feeling these are nothing except waste of my time and money. But now I can clearly see the impact of effective planning in my professional career.

Testing is a fundamental part of SDLC which ensures software is developed as per requirements. Effective test planning and execution is extremely important to achieve activity desired results. Many testers directly start testing the application without any planning which leads to ineffective test results hence project failure. Based on my experience, I will share few guidelines which will help my fellow testers to effective plan and execute any functional testing project.

Functional test

Test Requirement Gathering through a Questionnaire

Testing starts from test requirements. First of all you need to understand the application test scope, test environment, output documents, test inputs etc. Best way to get all this information is to forward a questionnaire to concerned person and get their response on it.

Application and Domain knowledge

Once all the requirements are collected, next step is to thoroughly understand the application and its domain. This is the one concerned area, which need lots of attention but unfortunately is being overlooked and causing lots of projects failure. Any application effective testing can never be performed without in-depth understanding of the application and its domain.

Test Cases Writing

Most stakeholders sometimes even software testers considered test cases writing as time wasting activity and prefer ad-hoc testing. They believe test cases are just waste of time and we can wisely spend this time in execution and can find more defects. But let me tell you, this strategy doesn’t work especially when you are testing a large and complex system. Test cases provide you the track of execution and you don’t need to focus on non-testing aspects (e.g. remembering which conditions are tested and which are left etc.) while testing. Various studies and experiments have proved you can find more defects by writing test cases rather than ad-hoc execution.

Defect Management Tool

Defect reports are prepared in various formats like MS Excel sheets, MS Word docs and defect management tools. Defect management tools are normally commercial and many stakeholders preferred MS Excel or Word formats for defect reporting but it hides defect reports visibility. Being a tester you might not have the veto right for defect reporting mechanism selection but at least you can suggest stakeholders for better option.

Planning is mandatory to achieve any activity desired results and same is the case with software testing project. You can never get desired test results without implementing a clearly defined test strategy and above guidelines will help you to develop such test strategy.

In my last blog post I shared VuGen scripting best practices; here I will share few guidelines which will help performance testers to effectively verify their developed script. It’s strongly recommended to verify your script before using it in actual test to make sure it’s prepared correctly and able to fulfill all the requirements. Following are few methods which can be followed for VuGen script verification,

                           VUGen Script Verification

Reply with Extended Log Enabled

First script verification method is to reply the script with extended log enabled. This option provides script details in reply log and most of the anomalies can be found easily. Extended log option enables performance tester to view the system state in detail through following logs,

Parameter Substitution: It logs the parameters and the values used when the Vuser script runs

Data Returned by Server: Log all information sent from server to Vuser

Advance Trace: Logs all of the Vuser messages and functional calls

Verification with Application Input Data

It doesn’t mean that you script is flawless if you don’t find any issue in reply log with extend log options enabled. You script can never be acceptable if it’s not submitting inputs to Application server. So another verification test could be to submit some test data through your script and validate it’s submitted on application server or not.


VuGen supports image and text verification. You can insert checkpoint on various images and texts and reply the script. If your test passed, it means your script is successfully executing these areas of application.

Custom Messages

Another approach is to insert custom messages at specific code locations and check whether these messages are executing during reply or not? They can also certify your recorded script is successfully executing.

Baseline Test

Once you have verified the script through one or more of the above methods, one final test could be to run a baseline test with 5 users from controller and verify the server log. If this this test is also passed, it means you have successfully developed the script and its ready for real drama.

Virtual User Generator (VuGen) is a HP tool used for scripting the user actions which are used in LoadRunner and Performance Center to run the performance tests. Like other best performance testing tools VuGen has also script recording feature. Although a performance tester can record complex user actions through VuGen recording feature, but a recorded script is always a starting point for creating more robust and realistic user actions. Being a good performance tester you need to manually incorporate different user actions in your test script. Following is the brief list of modification which are mostly required once you have recorded user actions.


Recorded script only contain single user inputs and running the same test under heavy loads means you are running the same user multiple times. You need to parameterize such values which change with different users. Login with different users could be one such example.
Dynamic recorded values which changed on every iteration will fail the recorded script on replay. VuGen provides the automatic and manual correlation features to correlate such dynamic values and run the test smoothly.
One of the most desirable outcomes of the performance testing activity is to check the response time of all the user actions. VuGen facilitate its users to enclose all the user actions within transactions for which they want to check the response time.
Although this is not mandatory to insert multiple actions within your script but they make your script more structured. Further, user actions which you don’t want to test under heavy loads (like login and logout) can be placed in Vuser_init and Vuesr_end actions respectively and the user business scenarios can be placed in Action section as its only iterate in controller.
Rendezvous Points
Quite often we encounter situations where we need to simulate all the test users simultaneously to stress test that particular user action. VuGen makes this very simple by inserting Rendezvous point before this user action which will stop all the arriving user at this point and execute them concurrently.

Performance testing is conducted to identify and eliminate the application under test (AUT) performance bottlenecks. Different activities (requirement gathering, scenario selection, scripting, workload model, test execution, analysis and reporting) are involved in performance testing and perfect execution of all of these is mandatory to achieve desired test results. As performance testing is a complex and time-taking activity, you can’t test each and every application scenario (unlike functional testing) in it. You select most important scenarios only, which can highlight more performance bottlenecks in AUT. It’s basically works similar to Pareto’s principle which states 80% of the issues are due to 20% of causes.

Scenario New

Selecting any additional scenario or missing out the one can greatly affect your test effort and results. Proper planning and consensus from all stakeholders is required before formally start working on AUT scenarios scripting.

In this post, I will share few guidelines which will ensure you are selecting all the necessary performance test scenarios without adding any additional or missing any important scenario. Following is the list of scenarios which you should include in your performance test,

  1. Most Frequently Accessed Scenarios: Application scenarios which are mostly accessed by end users. As such scenarios will affect maximum users they must be included in load test. For example, browsing product catalog in an E-commerce web application.
  2. Business Critical Scenarios: Application scenarios where application core features exists. For example, purchasing a product is a business critical scenario in an E-commerce application.
  3. Resource Intensive Scenarios: Such scenarios which are expected to consume more system resources as compared to others. For example, order placement will be most resource intensive scenario in an E-commerce web application.
  4. Contractually Obligated Scenarios:  Application scenarios for which company has contracted to provide hassle free services. These scenarios might not be used very frequently but they can create huge business loss in case of failure. For example, company claims its home page loads within 3 seconds.
  5. Stakeholders Concerning Scenarios: Stakeholders could be more concerned on AUT new features impact on its overall performance.
  6. Time Dependent Frequently Accessed Scenarios: Time dependent scenarios which are executed very frequently but on certain occasions only. For example, viewing monthly pay roll slip on an online payroll application.
  7. Technology Specific Scenarios: These are the scenarios which are specific to AUT selected technology. For example, uploading a file through FTP server could be an example of technology specific scenario.