ISTQB Certification Exam Preparation

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 https://www.dropbox.com/s/75mvs49cmyspt8s/istqb_foundation_level_syllabus_2011.pdf

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: https://www.dropbox.com/s/28s2q6thn9siqiv/Software%20testing-%20An%20istqb-iseb%20foundation%20guide%202nd%20edition.pdf

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:
http://www.softwaretestinggenius.com/categoryDetail?catId=164
http://www.softwaretestinghelp.com/istqb-testing-certification-sample-question-papers-with-answers/
Following is another link of few practice questions and they are really helpful in understanding the concepts and exam preparation. https://www.dropbox.com/s/ozlf5hd1n2kc4c4/Practice%20Questions.rar

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.

Simultaneous and Concurrent Users

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 https://groups.google.com/forum/#!topic/LR-LoadRunner/fZFjXlgwZqk with James Pulley (http://www.linkedin.com/in/loadrunnerbythehour) 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 (http://www.wilsonmar.com/) 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 Certification Exam Registration in Pakistan

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 (http://www.pearsonvue.com/) 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

• 

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

• 

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

• 

• 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

  • 
  • 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 (http://www.pearsonvue.com/contact/asiapac/).The 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.

Key Elements of a Successful Functional Testing Project

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.

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.

VuGen Script Verification

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,

                          

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.

Checkpoints

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.

VuGen Scripting

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.

Parameterization
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.
Correlation
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.
Transactions
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.
Actions
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 Test Scenarios Selection

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.

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.

Mobile Apps Types

Mobile apps type is bit confusing topic and I have observed different people have different opinions on this topic. Many people mixed the mobile apps types with its categories like Social Media apps, Gaming Apps, Utility Apps, Banking apps etc. and few know the concept but they limit to only two types of apps (Native and mobile Browser apps). In this post, I will try to explain all major types of mobile apps with their features which differentiate them from each other.

                             

First of all, let me clarify there are 3 types of mobile apps, Native, Mobile Web Based and Hybrid apps. Following is the brief explanation of each of these,

Native Mobile Apps

Applications which are installed on your mobile device and you can access them at any time without internet connection is called Native Mobile Apps. Gaming apps (e.g. Angry Birds) is an example of Native mobile apps. Mobile device memory and configurations are very important for such apps as they stored complete app data within device.

Mobile Web Apps

Applications which are designed and developed for mobile devices and are only accessed through mobile web browser are called mobile web apps. Although you can open any web app/site on your mobile browser but design and alignment issues will give you an idea whether its mobile browser specific app or desktop browser web app. Another difference between the mobile and desktop web apps is, mobile apps URL usually starts with ‘m’ which indicates it’s a mobile version of the app. For example “m.yahoo.com” and “m.gmail.com” are mobile web apps version of these sites. As all such apps data comes from the server and device memory have no impact on these apps. Moreover, separate PSDs are designed for these mobile versions of the apps to accommodate all its content on mobile screens.

Hybrid Mobile Apps

Such mobile applications which are installed on mobile device but they required to connect to internet to fetch their content. Instant Messengers (Skype), Social media apps (Facebook, Twitter) and E-commerce apps are example of such apps. These apps are also called client-server apps as their data comes from the server. Device memory is partially involved in such applications just for the installation as app data comes from the server.

Following table will describe differences in above mentioned types of mobile apps.

Feature	Native App	Hybrid App	Mobile Browser App
Development Tools	Objetive-C, Java, C	HTML, CSS, Javascript, Mobile development Frameworks (Phone Gap)	HTML, CSS, JavaScript
Distribution	App Store/Market	App Store/Market	Internet
Development Speed	Slow	Moderate	Fast
Application Maintenance	Difficult	Moderate	Low
Device Access	Full Access	Full Access	Partial Access

Configuring Monitors in LoadRunner Controller

Monitors are configured in LoadRunner Controller to check the specific parameters behavior during the load test. LoadRunner Controller possesses wide variety of monitors like Run-time, Transaction, Web Resource, System Resource, Network, Firewall, Web Application Server, Database Server Resource etc. monitors. Some of these monitors are automatically configured and their statistics are displayed as you execute your test but for most of them, you need to configure them.  In this blog post I will share steps by step approach to configure Windows Resources monitors (method is quite similar to configure any other monitor as well).

Following two main steps are involved in configuring Windows Resource monitors in Controller,

• Adding the monitored server machine
• Adding Resource Measurement

Adding Monitored Server Machine

Following steps are involved in adding monitored machine,

1. Open LoadRunner Controller
2. Select System Resource Graphs
3. Double click on Windows Resources
4. Right click on Windows Resource Graph area
5. Select “Add Measurements”
6. Add the Monitored Server machine

• Click on Add button
• Enter machine name or IP
• Select its platform
• Click on “OK” button

Monitored machine should be added and displayed in “Monitored Server Machine” window.

Adding Resource Measurement

Once you have added monitored machine, now you need to follow below steps to add its monitors whose behavior you want to check during the load test.

1. Click on “Add…” button to add all the above Resource Measurements
2. It will ask for the Username and Password if monitored system is not on the same network

3. You can also add additional details of any Resource Measurement by double clicking on it and selecting its component

4. Click on “OK” button once all the required resources are configured.

 

 

Defects Documentation Practices

The main purpose of software testing is to identify as many defects as possible. Although various documents like test plan, test scenario matrix, test cases matrix etc. are developed during any application testing but it’s the defect report on which everybody emphases the most. In one of my of previous blog post, I have discussed defect report components to make it easy for all the stake holders to utilize it. In this blog post I will share defect report documentation practices to effectively document the defect reports.

Bad Practices

Although defect report is the crux of a testing activity but normally it consider as the last document prepared during the process. I observe people following this as a protocol to leave the defect report preparation till end of the testing cycle. I also used to practice the same in my early days in this profession. Following are some of approaches practiced for defects documentation,

• Don’t bother about defects reporting unless test cases execution is completed
• Note one liner defect description if it found it during test cases writing and execution
• Just take the screenshots of defects to document it during defect reporting phase

There are various disadvantages of each of these practices like,

• One need to execute all steps again to effectively document the defect
• Few defects are missed out in the process because they were not documented properly
• Test cases execution and defects documentation take more time
• Defects information is only available at the end of the test cycle

Best Practice

All these techniques are practiced but the one which I found the best is to document the complete defect as you find it. Start preparing the defect report during the test scenario and test cases writing phases. This technique has various advantages like,

• More than 50% defects are documents before starting the test execution
• Its decrease the test cases execution and defect reporting time
• No defects are missed out because they are documented as they are experienced
• Defects are well documented as you have just experienced it and executed its steps
• One can show his effort/progress to his team lead one any stage and can get the idea of defects severity