Extract the common code into a separate helper class (not a test class). Then have both test classes instantiate the helper and call its method to do the common task.
You could extract the common code into a base class, but base classes tend to become tangled or bloated as different subclasses demand different behavior from the base class.
I was wondering if anyone know why the WebDriver command: .windowMaximize() doesn't put the window of the browser (Chrome on MAC in my case) in fullscreen? The window is re-sized to fit in only half of my screen.
Is there anyway to tackle this problem? maybe by setting by myself dimensions with the command .windowSize() but the problem with that is that it will be only set for the screen I use at the moment and so I will have to change if I launch my script on a different screen.
We have several "testers" who are involved in manual testing and test automation, but all of that part-time. Some of them are not really interested in testing and test automation as a field and lose interest in test automation and improving testing skills pretty quickly.
How should we deal with them?
That depends on why you have uninterested testers.
If this situation exists because you are bad at hiring people, then you need to get better at attracting and hiring folks who want to work hard and be professional testers.
If this situation exists because you pay poorly, you might need to pay more to attract better people.
If this situation exists because you treat your "testers" (it's telling that you put the word in quotes) like second-class citizens, then you may need to treat them more professionally.
Knowing how to "deal" with almost anything requires first understanding how you got there.
Is it okay to have a part-time not-motivated tester?
"Okay" is always a business decision.
I've seen some companies who decide that they don't really care enough to pay and hire real, professional QAers. For them it appears that part-time, uninterested testers check the checkbox well enough.
Other companies value testers and do things differently.
Is there anything we can do to raise their interest in testing and test automation?
Again it depends.
The answers ranges from "No, there's nothing you can do", to "Fire them all and hire full-time professionals" with everything in between.
I sometimes come across bugs that do not have enough information to reproduce the bug, or worse, understand what the issue is in the first place. Usually, business analysts, rookie QAs & sometimes developers write nonsensical bugs like this. Contrived (for simplicity) examples -
Ex.1 I see a server error when I open this webpage, for this user. The username and password is xyz.
Me: Does the page give more info about the server error ? Did you check the network inspector of your browser ?
Ex.2 I open the ecommerce webpage & add items item1 & item2 to shopping cart. Then, I see that the underlying CartService's api call getCartTotal response has Item 1 discount=0%. This is wrong. In ItemPriceService call getItemPrice(theItem) we have Item 1 = {$50, discount 10%} & Item 2 = {$100, discount = 0%}.
Me : So, you meant to say that in the shopping cart, any discounted item is priced at its regular full price. (...and the rest of the info in your bug report is the underlying details of the bug)
Due to such bugs, I often have to waste time in chatting with the bug reporters to understand & reproduce such bugs. How do I deal with such poorly documented bugs ?
Some solutions I think might help. Do you see any issues in these solutions ?
Save 2-3 poorly documented bugs somewhere & make current employees & new candidates try to figure out what the basic issue is & how to reproduce it. Then, show them the well documented version of the bugs to understand how much pain others go through in understanding the bugs. I will have to ask management to do implement this solution.
Create general guidelines for bug reporting, perhaps even specific guidelines for api testing, UI, database etc.
Reject the bug saying that its not clear what the issue is.
This is probably not a design pattern but more like an organizational/structural pattern.
When having a big test codebase and following the Page Object pattern for WebDriverJS/Protractor testing, we've found out that having a complex Page Object defined as a node "package" (directory with index.js as a main entry point) with child page object exposed through the parent one proved to be quite convenient.
For example:
- page.po
- index.js
- subPage1.po.js
- subPage2.po.js
where index.js defines a parent page object exposing child page objects as object fields:
var subPage1 = require("./subPage1.po"),
subPage2 = require("./subPage2.po"),
var ParentPage = function () {
// some fields here
// child page objects
this.subPage1 = new SubPage1(this);
this.subPage2 = new SubPage2(this);
};
module.exports = new ParentPage();
Usage:
var parentPage = require("page");
parentPage.someField.click();
parentPage.subPage1.someChildPageField.sendKeys("Test!");
I am working on a project, on that project developers are doing a very good job that we hardly find the bugs on that application. Everything is running very smoothly client is very happy with the developers. but now client think that we are not reporting bugs & we are not doing anything which is not true Now how to handle this situation. How to explain this thing to the client.
The following should work. I've used the class name for the login button instead of using XPath (seems more appropriate here) + always use explicit waits never Thread.sleep!
//Instantiate Firefox Driver
//Go to CV Library Website
var driver = new FirefoxDriver();
driver.Navigate().GoToUrl("https://www.cv-library.co.uk/");
WebDriverWait wait = new WebDriverWait(driver, TimeSpan.FromSeconds(15));
IWebElement loginButton = wait.Until(ExpectedConditions.ElementToBeClickable(By.ClassName("nav-login")));
loginButton.Click();
//Verification that specified page opens
var loggedInHeader = wait.Until(ExpectedConditions.ElementIsVisible(By.Id("cand-login-tabs")));
Assert.IsTrue(loggedInHeader.Displayed, "Unable to access page");
According to Creating user keywords:
User keywords can be created in test case files, resource files, and test suite initialization files.
So I'm wondering what's the best practice regarding this.
I'm organizing my tests in one file per website page I'm testing. I also have Resource file for library importing and global variables, and one __init__ file per tests file to include test setup and teardown.
Where in this structure would higher level keywords fit?
I'll like to point you to Karate which is also a BDD framework with some advantages over REST-assured. I would recommend you evaluate this tool as well.
Here is a detailed comparison document, that hopefully will be useful - as you may be able to use the same points to compare with UFT as well.
Disclaimer: I am the dev.
edit: I've been asked to summarize the contents of the link which is the comparison of Karate vs REST-assured, so here are the main points:
The classic tool for testing of interative non-GUI applications is called expect. It comes from the Tcl world but Ruby equivalents are available as well: