ISTQB Foundation level exam Tips

I cleared my ISTQB Foundation level sometimes back and below are some of the tips I can give you:

1. The sample Questions will only give you the feel of the questions. Go thru the 5/6 sets of questions provided above and this will help. Original question sets will be similar but not exactly the same.

2. Go thru the syllabus quite a few times. Many questions will come from there..(see the other post in this section for syllabus pdf)

3. Some questions will come from glossary.(see the other post in this section for Glossary pdf)

4. From Static testing if you can remember the defintions and properties of reviewer, inspector etc you will get quite a few questions.

5. Finally If you study completely the second book,I can assure you that you can clear the exam very easily.

Links for download
Chapter 1: ISEB Foundation Syllabus – Chapter 1
Chpater 2: ISEB Foundation Syllabus – Chapter 2
Chapter 3: ISEB Foundation Syllabus – Chapter 3
Chapter 4: ISEB Foundation Syllabus – Chapter 4
Chapter 5: ISEB Foundation Syllabus – Chapter 5
Chapter 6: ISEB Foundation Syllabus – Chapter 6

The link of sample exams in SQAT: (Register an account in SQAT for Free for practice tests)

QTP TIP – Common QTP File extensions

Here are the list of common QTP file extensions:

  • QTP Script File – .mts  ( mercury test script)
  • QTP Local Repository – .bdb  ( berkely database)
  • Shared Repository – .tsr ( test shared repository)
  • Load test configuration file – Default.cfg
  • Load test configuration file  – Default.usp
  • Test.Tsp -Test Settings File
  • -Test Parameters file
  • Default.xls – Datatable ( Excel file)
  • – contain the resources associated information like function library, recovery, shared repository
  • Recovery Scenario – .qrs
  • Function library – .vbs / .qfl / .tst
  • Test Batch – .mtb
  • Action Template – .mst ( mercury shared template)
  • Virutal Object –  .vot  ( virtual object template)
  • lock.lck – Created when the QTP test is open

QTP TIP – the random selection WebRadioGroup option

1, randomly select the drop-down options:
‘Get the number of options
t = Browser (“Browser”) Page (“User Management”). WebRadioGroup (fingerprint authentication). GetROProperty (“items count”)
‘Get a random index of the item
b = RandomNumber (0, t2-1)
‘Set random option
Browser (“Browser”). (“User Management”). WebRadioGroup (fingerprint authentication) Select “#” & b

2, printout options
m = m2 = Browser (“Browser”) Page (“User Management”). WebRadioGroup (fingerprint authentication). GetROProperty (“value”)
MsgBox m

QTP Code – randomly select the drop-down box option

1, randomly select the drop-down options:
‘Get the number of drop-down options
t = Browser (“Browser”) Page (“User Management”). WebList the (landing type). GetROProperty (“items count”)
‘Random selection drop-down option
Browser (“Browser”) Page (“User Management”). WebList the (landing type). Select RandomNumber (0, t-1)

2, print, select the drop-down option values
‘Get the selected drop-down option values
m = Browser (“Browser”) Page (“User Management”). WebList the (landing type). GetROProperty (“selection”)
‘Print drop-down option values
MsgBox m

5 Boundary Value Analysis Examples

Bounday value analysis is a test case design technique in software testing. This covers the known areas of frequent problems at the boundaries of software component input ranges. Experience has shown that the boundaries of input and output ranges of a software component are common locations for errors that result in software faults. Boundary value analysis assists with the design of test cases that will exercise these boundaries in an attempt to uncover faults in the software during the testing process.Applying boundary value analysis you have to select now a test case at each side of the boundary between two partitions. The boundary value analysis can have 6 text cases: n, n-1, n+1 for the upper limit and n, n-1, n+1 for the lower limit. The best way to learn boundary value analsysis is by going though some examples. In this artticle we will cover 5 such examples of BVA:


1) Order numbers on a purchase control system can range between 10000 and 99999 inclusive. Which of the following inputs might be a result of designing tests for only valid equivalence classes and valid boundaries?

a) 1000, 50000, 99999
b) 9999, 50000, 100000
c) 10000, 50000, 99999
d) 10000, 99999, 100000

2) An input field takes the year of birth between 1900 and 2004
The boundary values for testing this field are
a. 0,1900,2004,2005
b. 1900, 2004
c. 1899,1900,2004,2005
d. 1899, 1900, 1901,2003,2004,2005

3) To test the password field which accepts minimum of 6 characters and Maximum of 12 Characters.
To satisfy Boundary value, tester will have to write Test Cases considering values from  Valid region and each Invalid Region and Values which define exact boundary.
For our example we require 5 Test Cases
1. Consider password length less than 6
2. Consider password of length exactly 6
3. Consider password of length between 7 and 11
4. Consider password of length exactly 12
5. Consider password of length more than 12

4) More complex example:

For example, if a purchase is in the range of $5 up to $60 has no discounts, a purchase over $60 and up to $150 has a 5% discount, and purchases of $151 and up to $400 have a 10% discounts, and purchases of $401 and above have a 15% discounts.

Now we can identify 4 valid equivalence partitions and 1 invalid partition as shown below.

Invalid partition=$0.01%

Valid partition(No Discounts)=$5-$60

Valid partition(5%)=$60-$150

Valid partition(10%)=$151-$400

Valid partition(15%)=$401 and above

From this above example we can identify the boundary values of each partition. We assume that two decimal digits are allowed.

Boundary values for Invalid partition: 0.00
Boundary values for valid partition(No Discounts): 5, 60
Boundary values for valid partition(5% Discount): 61, 151
Boundary values for valid partition(10% Discount): 151,400
Boundary values for valid partition(15% Discount): 401, Max allowed number in the software application

5) Input should be greater than equal to 10 and less than 50″

Probably you will write something like

if (input >=10 AND input <50)>10 AND input <50> Input value 10 in invalid now.

input <=10 AND input <50> Input value 9 is valid now.

input >=10 AND input <=50 —–> Input value 50 is valid now

input >=10 AND input >50 —–> Input value 49 is invalid now

Because it is very easy to introduce defects at boundaries, boundary values are important. So for the above example, at the minimum we should have following test cases for boundaries

9, 10, 11 and 48, 49, 50

lower_boundary – 1, lower_boundary, lower_boundary + 1 and upper_boundary – 1, upper_boundary, upper_boundary + 1

5 Simple Steps of Software Test Estimation





New here? Like us on Facebook to stay updated of new posts. Plus, if you think your friends or followers will enjoy this post, please share on Facebook or Twitter using the buttons above.

For Effort estimation in testing there can be various approaches. In this article, we will discuss some of the basic steps you always need to follow.
1) Past project experience: This is most probably the most basic thing you need first. Try to identify something similar that you have worked on in the past or that someone you can talk with has worked on in the past. In each project, the time, it takes to develop a test case or to do execute each test case is different. So if you do not have any experience on working on such a project, you may estimate too low or high.

2) Write down a work breakdown structure: List down all the activities you need to perform in this project such as test plan preparation, test case design, test data prep and test execution, etc. Again from step #1 identify the various tasks and activities that were involved in the past work and map them to the new work you are planning. As part of this identified places where there is something new to you and seek help from someone who has had experience with those activities and tasks. Have that person to identify things you have missed. Allocate time to each of these tasks based on the volume of work. For example, if you need to write 100 test cases for a project, and it takes 30 minutes to write a test case, then put 3000 minutes or 3000/60 = 50 hours (also called person hours, man hours) for the task test case creation Similarly fill up all the task hours.

3) Put some contingency plan: Try to remember the problems and issues that you may have run into the past project and how much those problems and issues helped or hurt the original schedule. Then as you are looking over things, ask yourself questions such as: (1) what happens is someone’s family member dies, and they have to deal with that, (2) what happens if someone is sick, (3) what happens if someone leaves the organization for someplace else, (4) what happens if equipment and gear are not delivered on time, (5) what happens if a deliverable is delayed or the quality is not sufficient.
Add the impact of those problems and issues into what you remember from the past work. Remember it is always better to over estimate than putting less time. On the top of estimation in step 2 put some buffer hour based on the risks you have identified. So it can be 10% to 30% of the total effort. For example, in the step #2 you have total effort found 1000 Person Hours then put another 30% on the top of that, and the test effort would become 1300 PDs.

4) Perform a top down Estimation: Now above we have found the effort of testing using a bottom of approach. However, when you put that in a project plan, the overall estimation will be even more because of the external dependencies or activity other than testing. So until a code is delivered you cannot start your testing. For example, Module A might be delivered on 23 Feb by the Dev team where as the test case writing and test data prep for Module, A is done on 20th February. In this situation, though you are 100% ready for testing, but you cannot start the test as the code would not be ready. So test execution for that module would take 3 more days than what you estimated originally. Similarly add all those dependencies, and you will see your overall test estimation become more than your bottom-up estimate. Generally, this will be 10 to 20% more than what you estimated before.

5) Review and approval: Finally, walk through your estimations with a couple of people, having them review them. If possible try to do a simulation with pencil and paper, drawing some diagrams about how things fit together, concentrating on deliverables and timing. Remember there are different kinds of deliverables such as documents (formal and informal), decisions, reviews, and actual testing work that result in documents (test reports, service reports documenting defects, etc.)

New here? Like us on Facebook to stay updated of new posts.

What is Localization Testing?

What is localization of an application?
First of all, we need to know what the meaning of localization of an application is before we deep dive into the concept of localization testing. Localization is a development process where we modify the application for a particular region. This may involve a change to the language texts and even some changes in the application behaviors based on the local culture needs. Generally, when the product is stable in the current version, we go for localization.
What is Localization Testing?

Now once the application is customized for a local version we need to do some testing to make sure all the changes are fine and as per the requirement specification. Now following areas are typically tested in localization testing:

a) UI testing

This is the major area of testing for a localized application. Some of the important areas need to be checked in the UI testing are:
1) The localized version must have the same look and feel of the original version.
2) All the text appearing on the UI must be translated to the local language.
3) Generally the translated text gets extended. So we need to make sure it does not make the GUI look bad. So it is often observed that dialog box, etc. in the localized version is little bigger than the original version.

b) Culture/locale-specific and language/region-specific areas

1) A localization tester should think about the target region’s ‘Character Sets’ and ‘Keyboard Layouts because there is guaranteed to be a major distinction between original version’s and the localized version’s character sets and keyboard layouts. So consideration needs to be given towards tiny areas, for example, hot keys, uppercase and lowercase conversion, garbled translation, etc.

2)  Application Functionality: The localized version must have exactly the same functionality as the original version. To make sure this, the usual functionality tests need to be executed. Setup and upgrade tests need to be run in the localized test environment. Application and Hardware compatibility tests should also be planned in accordance with the products target region.

3)Documentation Consistency: When delivering a localized product it must be ensured that localized documentation (manuals, online help, context help, etc.) is provided.

Things that have to be checked are:
1. The standard of the language translation.
2. The completeness of the interpretation.
3. Verbiage is utilized consistently in all the documents and application User interface.

Top 4 challenges of non functional testing

In any software testing project, we do broadly two types of testing – functional testing and non functional testing.

Functional testing is done by using the functional specifications provided by the client or by using the design specifications like use cases provided by the design team. On contrary the non functional testing is quite complex and often subjective as opposed to functional testing. Here the client tries to document what they expect from the system in terms of how fast, how efficiently, how safely, etc.
Now in this article we will check some of the common challenges of non functional testing:

1. Requirements are too subjective:
In many cases, the non functional requirements are too generic and subject to interpretation. Like people may say, “application must response quickly when the user makes a search” or “the application must be secure” etc. Now while doing the testing, this kind of requirement is a big challenge, and we need to quantify that. For example, the first requirement can be restated in this way: the application must response in three seconds while 100 concurrent users make a search into the system. Like this all the other requirements needs to be quantified before we start doing any testing.

2. Infrastructure overhead: Second challenge is simulating a production like environment. If in production, you are having 200 machines running, then what should be the ideal load of the test environment. Should we have 100 machines configured, which would give a realistic performance results during performance testing. So in this 100 machine test bed if we get a result of six seconds for a user’s search, then can we say in production with 200 machines the response time would be three seconds as per the requirement.

3.  How many concurrent users:
Again as we mentioned in the point #1, it is not enough to say I want the application to return a user’s search result within three seconds. If 1 user does that search at that point, then three seconds is fine. However, how about 1000 users are going to perform the same operation say login to the system at the start of the day. Of course, that time the memory and CPU utilization would be much higher and consequently, the response time would be much lower. So while designing non function test cases you always need to consider the number of concurrent users for a particular transaction.

4. Test Data:
This is one of the biggest challenges. Two things you need to determine while running performance, load and stress this kind of non functional testing. First, the data volume you need to load in your test environment. If the production had 100 terabytes of data, how much data do we need in the test system? More data will have more impact on performance. Because the database insert would take more time. Second, the data variation is also important. If you use a data where the update, insert, delete operations are not happening, then definitely it would take less time. Furthermore, if you use the same type of data or same data again and again, then the system would simple cache it and in a next run, the data will be fetched from the cache, and the response time would be much lower. So you need to have a production like data volume based on your test infrastructure alone with a good data variation.

Differences between Smoke test and Sanity Test

Smoke test: The origin of smoke test is from hardware industry where you turn on a new piece of hardware for the first time and make sure it does not end up catching fire and smoke. In Software industry that term becomes quite popular and here when a new build comes or you are moving your application to a new environment for testing you check the major functions of the application without getting into too deep. So in other words a Smoke test is designed to touch every part of the application in a cursory way.

If the smoke test fails, you can’t do the sanity test. It usually happens when an application program has many external dependencies, smoke testing may find problems with it (such as missing libraries).

It should be ideally performed on each build with a predefined set of scripts. On average it should not take more than an hour or so as it is shallow and wide.

Sanity Test: Once the application passes the smoke test you need to perform the sanity test on the build. A Sanity testing is a cursory testing; it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. A Sanity test is usually unscripted. So you have your best experienced tester who would check the major functions of the application and certify the application is ready to move to the next level (such as UAT or Production etc)

See the Wikipedia articles linked below



What is the difference between Regression Testing vs Retest?

This is one of the mostly commonly asked question in any software testing interview. In this article I will explain what is the difference between regression testing and retesting.

Regression Testing is the execution of all or a select group of test cases that have passed on the earlier build or release of the application under test so that you can validate, the original functions and features are still working as they were in the past.
The test cases we use are derived from the functional specification, the user manuals, user tutorials, and defect reports in relation to corrected problems.

First regression test should be done using functional test cases to make sure no new defect has been introduced. In addition, we repeat some of the tests using a performance tool, to see how a new version handles, with regards to time and memory usage.

In most of the organization, the regression testing is incremental. So as we add new functionality, or correct a defect, we add test cases, which are included in subsequent rounds of regression testing.

In addition to new software releases at our end, we repeat the tests when MS introduces a new service pack, and to check ongoing compatibility for supported legacy operating systems.

As you can probably see from the above, automation is the key for regression testing. If you haven’t gone down the automation route yet, regression testing is a good time to consider it. Manual regression testing tends to get more expensive with each new release.

Some of the possible failure of a regression test could be due to new functionality, changes in other applications or hardware that interfaces to your app. or even changes in the environment, like updated browser, security updates, or maybe a change in the screen controls.

Retesting is the execution of one or a set of test cases, which previously failed due to a suspected defect in the software which now is documented as being remedied.
However, the fix may introduce fault elsewhere in the software. The way to detect these “unexpected side effects” of fixes is to do regression testing as mentioned above.

So on the conclusion, in retesting we need to check the defects that have been logged by the tester and fixed by the developer. We need to test if that particular bug has been fixed but in regression testing, we need to check if that has been fixed or not and also make sure that change in code by the developer to fix that particular bug has not left any impact on any other phase of application. So regression testing is a kind of testing the whole scenario after fixation of every bug.