I think your suggestions are very good, it is always good to have clear guidelines. Though they should not be set in stone and should be used as a guideline and not as a rule.
In order to reproduce the issue I want as much information as possible. A screenshot can tell a thousand words. Some people make only a screenshot of the part they think ...
I will answer/go through your points one by one and will try to add some valuable information in addition to your useful & precised description.
Color usage in images: Highlighting becomes critically important when creating bugs related to GUI. Regarding the color, we have been using Red (R =255, G=B=0) and Blue (R=G=0, B=255) color only for ...
Images for bug reports should:
contain all the information needed. So for browser screenshots use the whole browser window so people can see the browser, browser version and any toolbars that reflect installed tools and any footer toolbars that show info.
not contain irrelevant information. I am not a fan of the whole desktop screenshot as it includes too ...
There are multiple ways to get a screenshot depending on whether you need a full page screenshot, whether the page requires some inputs to get the expected state and which device you are trying to simulate.
For instance changing the size of the window is not enough to simulate a mobile device since you'll also have to consider the pixel ratio and in some ...
I haven't tried it but I remember seeing it in a YouTube video I watched years ago. Kohsuke Kawaguchi's talk Jenkins Selenium Meetup: Kohsuke Kawaguchi on how Jenkins + Selenium = Love at around the 18 minute mark.
You could use recheck-web for visual testing. It doesn't use screenshots (i.e. it is not pixel-based), but maps web GUIs to a special data model. This enables you to detect visual regressions, including non-visible changes such as CSS properties or hyperlink targets. It is built upon the principle of Golden Master Testing, so there is no need to write and ...
Capture the screenshot and store it in the specified location.
An object in memory is also a valid location. The word location does not only mean a file location on disk. Thus one could argue that the word "location" could reference a ...
You can do this manually, or create for example Appium script to do this for you on cloud device labs.
Crossbrowsertesting could be a fit for you, they have quite simple "test recorder and they support Visual Testing.
They all have free trials, so it could fit your short-term needs :)
Amazon AWS Device farm
I asked the SideeX team and received information that they currently do not support print screen function, but they will "consider this feature further in the future versions"
Meanwhile, I have found Kantu that support print screens creation: https://a9t9.com/kantu/docs#screenshot
Moreover they also supports integration with Jenkins and drag and drops to ...
how reliable can it be - would it depend on the browser, resolution and other parameters of the test machine setup?
I can answer this part. I am using Kantu for visual testing, and the tests do not depend on the resolution (the software and its image recognition algorithms account for that). So I can create a test on machine A and move it over to a very ...
HtmlUnit does not have screenshot function, as the page is not rendered.
Here is the feedback from the developers on a similar question:
HtmlUnit is a headless browser, and makes no attempt to render
content. This is the reason that the HtmlUnitDriver does not support
the TakesScreenshot interface.
If you need to take screenshots, then I'd ...
There is no specific method to note the stepname,you will have to explicitly mention the stepname.
To get the time you can use the Date Class
Steps to get the screenshot:
WebDriver driver = new FirefoxDriver();
/* Taking the screenshot */
File scrFile = ((TakesScreenshot)driver).getScreenshotAs(OutputType.FILE);
/* Saving the screenshot ...
At our company we use screenshots quite rarly for bug reports, mostly only to show visual errors as a screen can tell more than 1000 words. To highlight we normally use green for correct behavior and a blue (or torquise) to highlight non-correct behavior - this comes due two points:
Better contrast to the GUI
Avoiding red/green blindness problems
But of ...