Skip to main content
replaced http://sqa.stackexchange.com/ with https://sqa.stackexchange.com/
Source Link

Here some points about I have discovered:

  1. Sikuli can not select by 100% text match. So it is extremely difficult to use it in financial applications cause there are not too many different GUI elements, but lots of similar buttons, lists, tables... So how could you select specific string (by its contents) in table with 1000+ rows (only 25 are in a visible area, the question about lists & tablesthe question about lists & tables) with tool that works by text recognition. Even if you will find the way to scroll to the item you need here comes the problem to distinguish row with "Economic Community of West African States" from "Economic Community of East African States". With maximum recognition strength 0,99 they are still the same.

  2. Sikuli is unpredictable. Some GUI elements can change their skins, colors, images (here is an example of transparency in windows GUI, so the autotest was broken just because of changed background):

The same object still different colors

  1. Sikuli is fast to learn. Need just half of a day to create the first test (navigation through several windows, selecting values in drop down lists, generating report)

  2. Sikuli tests look like comix. In native Sikuli IDE test looks like comix, someone can like that but I prefer text instructions :)

Sikuli test looks like this in Sikuli IDE

  1. Sikuli is good for testing UI with high requirements in usability. E.g. mobile applications, simple web applications where the icons should be easy to distinguish, easy to find. If Sikuli (with default recognition strength) will make a mistake in finding icon, field etc. that means that (most likely) design of them is not that good (so even user could mismatch GUI items).

When Sikuli (image recognition) is better than Selenium (objects description)

  1. Need to check changes in interface
  2. Working with graphical interface (icons, buttons with images...) that should be very clear to user
  3. There is no easy access to objects properties (e.g. remote desktop. I'm using it in this case)

Here some points about I have discovered:

  1. Sikuli can not select by 100% text match. So it is extremely difficult to use it in financial applications cause there are not too many different GUI elements, but lots of similar buttons, lists, tables... So how could you select specific string (by its contents) in table with 1000+ rows (only 25 are in a visible area, the question about lists & tables) with tool that works by text recognition. Even if you will find the way to scroll to the item you need here comes the problem to distinguish row with "Economic Community of West African States" from "Economic Community of East African States". With maximum recognition strength 0,99 they are still the same.

  2. Sikuli is unpredictable. Some GUI elements can change their skins, colors, images (here is an example of transparency in windows GUI, so the autotest was broken just because of changed background):

The same object still different colors

  1. Sikuli is fast to learn. Need just half of a day to create the first test (navigation through several windows, selecting values in drop down lists, generating report)

  2. Sikuli tests look like comix. In native Sikuli IDE test looks like comix, someone can like that but I prefer text instructions :)

Sikuli test looks like this in Sikuli IDE

  1. Sikuli is good for testing UI with high requirements in usability. E.g. mobile applications, simple web applications where the icons should be easy to distinguish, easy to find. If Sikuli (with default recognition strength) will make a mistake in finding icon, field etc. that means that (most likely) design of them is not that good (so even user could mismatch GUI items).

When Sikuli (image recognition) is better than Selenium (objects description)

  1. Need to check changes in interface
  2. Working with graphical interface (icons, buttons with images...) that should be very clear to user
  3. There is no easy access to objects properties (e.g. remote desktop. I'm using it in this case)

Here some points about I have discovered:

  1. Sikuli can not select by 100% text match. So it is extremely difficult to use it in financial applications cause there are not too many different GUI elements, but lots of similar buttons, lists, tables... So how could you select specific string (by its contents) in table with 1000+ rows (only 25 are in a visible area, the question about lists & tables) with tool that works by text recognition. Even if you will find the way to scroll to the item you need here comes the problem to distinguish row with "Economic Community of West African States" from "Economic Community of East African States". With maximum recognition strength 0,99 they are still the same.

  2. Sikuli is unpredictable. Some GUI elements can change their skins, colors, images (here is an example of transparency in windows GUI, so the autotest was broken just because of changed background):

The same object still different colors

  1. Sikuli is fast to learn. Need just half of a day to create the first test (navigation through several windows, selecting values in drop down lists, generating report)

  2. Sikuli tests look like comix. In native Sikuli IDE test looks like comix, someone can like that but I prefer text instructions :)

Sikuli test looks like this in Sikuli IDE

  1. Sikuli is good for testing UI with high requirements in usability. E.g. mobile applications, simple web applications where the icons should be easy to distinguish, easy to find. If Sikuli (with default recognition strength) will make a mistake in finding icon, field etc. that means that (most likely) design of them is not that good (so even user could mismatch GUI items).

When Sikuli (image recognition) is better than Selenium (objects description)

  1. Need to check changes in interface
  2. Working with graphical interface (icons, buttons with images...) that should be very clear to user
  3. There is no easy access to objects properties (e.g. remote desktop. I'm using it in this case)
added 27 characters in body
Source Link
Ivan Gerasimenko
  • 2.3k
  • 4
  • 27
  • 47

Here some points about I have discovered:

  1. Sikuli can not select by 100% text match. So it is extremely difficult to use it in financial applications cause there are not too many different GUI elements, but lots of similar buttons, lists, tables... So how could you select specific string (by its contents) in table with 1000+ rows (only 25 are in a visible area, the question about lists & tables) with tool that works by text recognition. Even if you will find the way to scroll to the item you need here comes the problem to distinguish row with "Economic Community of West African States" from "Economic Community of East African States". With maximum recognition strength 0,99 they are still the same.

  2. Sikuli is unpredictable. Some GUI elements can change their skins, colors, images (here is an example of transparency in windows GUI, so the autotest was broken just because of changed background):

The same object still different colors

  1. Sikuli is fast to learn. Need just half of a day to create the first test (navigation through several windows, selecting values in drop down lists, generating report)

  2. Sikuli tests look like comix. In native Sikuli IDE test looks like comix, someone can like that but I prefer text instructions :)

Sikuli test looks like this in Sikuli IDE

  1. Sikuli is good for testing UI with high requirements in usability. E.g. mobile applications, simple web applications where the icons should be easy to distinguish, easy to find. If Sikuli (with default recognition strength) will make a mistake in finding icon, field etc. that means that (most likely) design of them is not that good (so even user could mismatch GUI items).

When Sikuli (image recognition) is better than Selenium (objects description)

  1. Need to check changes in interface
  2. Working with graphical interface (icons, buttons with images...) that should be very clear to user
  3. There is no easy access to objects properties (e.g. remote desktop. I'm using it in this case)

Here some points about I have discovered:

  1. Sikuli can not select by 100% text match. So it is extremely difficult to use it in financial applications cause there are not too many different GUI elements, but lots of similar buttons, lists, tables... So how could you select specific string (by its contents) in table with 1000+ rows (only 25 are in a visible area, the question about lists & tables) with tool that works by text recognition. Even if you will find the way to scroll to the item you need here comes the problem to distinguish row with "Economic Community of West African States" from "Economic Community of East African States". With maximum recognition strength 0,99 they are still the same.

  2. Sikuli is unpredictable. Some GUI elements can change their skins, colors, images (here is an example of transparency in windows GUI, so the autotest was broken just because of changed background):

The same object still different colors

  1. Sikuli is fast to learn. Need just half of a day to create the first test (navigation through several windows, selecting values in drop down lists, generating report)

  2. Sikuli tests look like comix. In native Sikuli IDE test looks like comix, someone can like that but I prefer text instructions :)

Sikuli test looks like this in Sikuli IDE

  1. Sikuli is good for testing UI with high requirements in usability. E.g. mobile applications, simple web applications where the icons should be easy to distinguish, easy to find. If Sikuli (with default recognition strength) will make a mistake in finding icon, field etc. that means that (most likely) design of them is not that good (so even user could mismatch GUI items).

When Sikuli (image recognition) is better than Selenium (objects description)

  1. Need to check changes in interface
  2. Working with graphical interface (icons, buttons with images...) that should be very clear to user
  3. There is no easy access to objects properties (e.g. remote desktop)

Here some points about I have discovered:

  1. Sikuli can not select by 100% text match. So it is extremely difficult to use it in financial applications cause there are not too many different GUI elements, but lots of similar buttons, lists, tables... So how could you select specific string (by its contents) in table with 1000+ rows (only 25 are in a visible area, the question about lists & tables) with tool that works by text recognition. Even if you will find the way to scroll to the item you need here comes the problem to distinguish row with "Economic Community of West African States" from "Economic Community of East African States". With maximum recognition strength 0,99 they are still the same.

  2. Sikuli is unpredictable. Some GUI elements can change their skins, colors, images (here is an example of transparency in windows GUI, so the autotest was broken just because of changed background):

The same object still different colors

  1. Sikuli is fast to learn. Need just half of a day to create the first test (navigation through several windows, selecting values in drop down lists, generating report)

  2. Sikuli tests look like comix. In native Sikuli IDE test looks like comix, someone can like that but I prefer text instructions :)

Sikuli test looks like this in Sikuli IDE

  1. Sikuli is good for testing UI with high requirements in usability. E.g. mobile applications, simple web applications where the icons should be easy to distinguish, easy to find. If Sikuli (with default recognition strength) will make a mistake in finding icon, field etc. that means that (most likely) design of them is not that good (so even user could mismatch GUI items).

When Sikuli (image recognition) is better than Selenium (objects description)

  1. Need to check changes in interface
  2. Working with graphical interface (icons, buttons with images...) that should be very clear to user
  3. There is no easy access to objects properties (e.g. remote desktop. I'm using it in this case)
added 40 characters in body
Source Link
Ivan Gerasimenko
  • 2.3k
  • 4
  • 27
  • 47

Here some points about I have discovered:

  1. Sikuli can not select by 100% text match. So it is extremely difficult to use it in financial applications cause there are not too many different GUI elements, but lots of similar buttons, lists, tables... So how could you select specific string (by its contents) in table with 1000+ rows (only 25 are in a visible area, the question about lists & tables) with tool that works by text recognition. Even if you will find the way to scroll to the item you need here comes the problem to distinguish row with "Economic Community of West African States" from "Economic Community of East African States". With maximum recognition strength 0,99 they are still the same.

  2. Sikuli is unpredictable. Some GUI elements can change their skins, colors, images (here is an example of transparency in windows GUI, so the autotest was broken just because of changed background):

The same object still different colors

  1. Sikuli is fast to learn. Need just half of a day to create the first test (navigation through several windows, selecting values in drop down lists, generating report)

  2. Sikuli tests look like comix. In native Sikuli IDE test looks like comix, someone can like that but I prefer text instructions :)

Sikuli test looks like this in Sikuli IDE

  1. Sikuli is good for testing UI with high requirements in usability. E.g. mobile applications, simple web applications where the icons should be easy to distinguish, easy to find. If Sikuli (with default recognition strength) will make a mistake in finding icon, field etc. that means that (most likely) design of them is not that good (so even user could mismatch GUI items).

When Sikuli (image recognition) is better than Selenium (objects description)

  1. Need to check changes in interface
  2. Working with graphical interface (icons, buttons with images...) that should be very clear to user
  3. There is no easy access to objects properties (e.g. remote desktop)

Here some points about I have discovered:

  1. Sikuli can not select by 100% text match. So it is extremely difficult to use it in financial applications cause there are not too many different GUI elements, but lots of similar buttons, lists, tables... So how could you select specific string (by its contents) in table with 1000+ rows (only 25 are in a visible area, the question about lists & tables) with tool that works by text recognition. Even if you will find the way to scroll to the item you need here comes the problem to distinguish row with "Economic Community of West African States" from "Economic Community of East African States". With maximum recognition strength 0,99 they are still the same.

  2. Sikuli is unpredictable. Some GUI elements can change their skins, colors, images (here is an example of transparency in windows GUI, so the autotest was broken just because of changed background):

The same object still different colors

  1. Sikuli is fast to learn. Need just half of a day to create the first test (navigation through several windows, selecting values in drop down lists, generating report)

  2. Sikuli tests look like comix. In native Sikuli IDE test looks like comix, someone can like that but I prefer text instructions :)

Sikuli test looks like this in Sikuli IDE

  1. Sikuli is good for testing UI with high requirements in usability. E.g. mobile applications, simple web applications where the icons should be easy to distinguish, easy to find. If Sikuli (with default recognition strength) will make a mistake in finding icon, field etc. that means that (most likely) design of them is not that good.

When Sikuli (image recognition) is better than Selenium (objects description)

  1. Need to check changes in interface
  2. Working with graphical interface (icons, buttons with images...) that should be very clear to user
  3. There is no easy access to objects properties (e.g. remote desktop)

Here some points about I have discovered:

  1. Sikuli can not select by 100% text match. So it is extremely difficult to use it in financial applications cause there are not too many different GUI elements, but lots of similar buttons, lists, tables... So how could you select specific string (by its contents) in table with 1000+ rows (only 25 are in a visible area, the question about lists & tables) with tool that works by text recognition. Even if you will find the way to scroll to the item you need here comes the problem to distinguish row with "Economic Community of West African States" from "Economic Community of East African States". With maximum recognition strength 0,99 they are still the same.

  2. Sikuli is unpredictable. Some GUI elements can change their skins, colors, images (here is an example of transparency in windows GUI, so the autotest was broken just because of changed background):

The same object still different colors

  1. Sikuli is fast to learn. Need just half of a day to create the first test (navigation through several windows, selecting values in drop down lists, generating report)

  2. Sikuli tests look like comix. In native Sikuli IDE test looks like comix, someone can like that but I prefer text instructions :)

Sikuli test looks like this in Sikuli IDE

  1. Sikuli is good for testing UI with high requirements in usability. E.g. mobile applications, simple web applications where the icons should be easy to distinguish, easy to find. If Sikuli (with default recognition strength) will make a mistake in finding icon, field etc. that means that (most likely) design of them is not that good (so even user could mismatch GUI items).

When Sikuli (image recognition) is better than Selenium (objects description)

  1. Need to check changes in interface
  2. Working with graphical interface (icons, buttons with images...) that should be very clear to user
  3. There is no easy access to objects properties (e.g. remote desktop)
added 309 characters in body
Source Link
Ivan Gerasimenko
  • 2.3k
  • 4
  • 27
  • 47
Loading
added 370 characters in body
Source Link
Ivan Gerasimenko
  • 2.3k
  • 4
  • 27
  • 47
Loading
added 140 characters in body
Source Link
Ivan Gerasimenko
  • 2.3k
  • 4
  • 27
  • 47
Loading
added 130 characters in body
Source Link
Ivan Gerasimenko
  • 2.3k
  • 4
  • 27
  • 47
Loading
Source Link
Ivan Gerasimenko
  • 2.3k
  • 4
  • 27
  • 47
Loading