Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - John Gimber

Pages: [1]
1
Quote
Automated testing is good — checking the basic functionality of a product at high speed and repeatedly.

Accessibility testing is good — making sure that the product is usable productively and comfortably by the maximum number of people.

Automated accessibility testing (AAT) is great and is seen as the “gold standard” by many, but some often curse this accessibility testing, thinking of it as a drag, or an expense that they just do not want to deal with. It is becoming more important than ever — lots of public sector agencies mandate it now and the recent WCAG (Web Content Accessibility Guidelines) 2.2 rule updates may be catching people out. So, the big question is “How do we do this without breaking the team, the product, and the bank?”

Read the full article on Medium.com

https://medium.com/p/3b72f950b1b5

2
Useful resources and links / Fail Fast, Succeed Faster...
« on: February 27, 2024, 10:45:46 AM »
Quote
Automated testing is a great way to speed up testing on a product. These automated tests can quickly grow in number, increasing test coverage and giving us the capability of trapping and reporting on issues and successes in our product far faster than if we were testing manually. Granted, there are setup costs — setting up the test framework and writing the tests, but once they are up and running… that’s where the unsung beauty of a testing strategy comes in.

Read the full article on Medium.com

https://medium.com/p/b36e5cb18e6f

3
So, you have a web page.
This web page contains a second page, embedded in an iframe.
How do you use Selenium to access the content within the iframe?



Well, it can be done, but it's not immediately obvious.

The xpath matching technique will work with the content it has in the main container page - but it won't see the content in the iframe page.

For example, if there is a form in the iframe contents, and it has a field called "origin"... Selenium won't be able to see it.  It can see as far as the iframe, but that's it.

Code: [Select]
WebElement myFrame = driver.findElement(By.xpath("codepath to iframe"));
driver.switchTo().frame(myFrame);

Now Selenium can access the form!

Code: [Select]
WebElement myOriginField = driver.findElement(By.xpath("//input[@id='origin']"));
myOriginField.sendKeys("Glasgow");

And in order to return to the main container page again...
Code: [Select]
driver.switchTo().defaultContent();

4
Selenium / Selenium Page Object Models For Beginners
« on: April 24, 2017, 08:13:02 PM »
Question 1.  What are Page Object Models?

A Page Object Model (POM), at its simplest, is a selenium file which specifically lets you control a single page of your website.

Question 2: Why use them?

Simply put, having the POM file defined means that you can code your tests, without your tests having to know exactly how your page is constructed.

Also, if there are any changes to the web page, then you only have to change the POM file once, and not change the x number of tests that cover that page.

Question 3: How can I use them?

Step 1: Define your POM file.  This is done by the following:
In the loginPOM.java file:
Define your controls on the page.  e.g. txtUsername, txtPassword, btnLogin, btnCancel.
Define some helper functions, e.g.
loginWithDetails(strUsername, strPassword) (which populates the username and password fields with the supplied values),
isLoginErrorShown() (which detects if a validation error is shown on the screen), etc.

Step 2: Define your tests.
In the loginTest.java file, for each test, instead of doing this:

Find username field.
Set field to “username”.
Find password field.
Set field to “password”.
Find <Login> button.
Click <Login> button.
Find the validation error message.
Check the validation error content… etc.

you can simply write

// Test 1: Invalid username/password
loginWithDetails(“baduser”, “badpassword”)
assertTrue(isLoginErrorShown())

// Test 2: Valid username/password
loginWithDetails(“gooduser”, “goodpassword”)
assertFalse(isLoginErrorShown())

So this makes the tests easier to read, and easier to write.

Going back to the “Why?” question, you can see that if the name of the “username” field changed, then (if each test was written out long-hand), each test would have to be recoded to use the new field name.  But when using the login POM, only the one function loginWithDetails() would need to be refactored to match the new name.  All of the unit tests that use the POM would be cheerfully oblivious of the change.

So… that is a very brief into to POMs, and why they are very useful.

5
Coffee lounge / A QA Engineer walks into a bar...
« on: March 21, 2017, 04:28:44 PM »
A QA Engineer walks into a bar.
Orders a beer.
Orders 0 beers.
Orders 99999999 beers.
Orders a lizard.
Orders -1 beers.
Orders a sfdeljknesv.

;)

6
Test tools / Bamboo (Continuous Integration)
« on: March 17, 2017, 09:10:50 PM »
Bamboo, provided by Atlassian, is a Continuous Integration (CI) system, which has been used to excellent effect for controlling testing of software automatically.

Bamboo can be downloaded from

There is a discussion on my Blog about The benefits of Continuous Integration.


7
Test tools / TestLink
« on: March 16, 2017, 01:32:44 PM »
From Wikipedia:

Quote
TestLink is a web-based test management system that facilitates software quality assurance. It is developed and maintained by Teamtest. The platform offers support for test cases, test suites, test plans, test projects and user management, as well as various reports and statistics.

For more info, visit:

TestLink can be downloaded from:

Basically, this web-based product works a treat for companies / individuals on a budget, but provides some pretty good functionality for running your testing / test team.

I have used this for several years to great effect.

Pros:
  • Free.
  • Supports testing, test management and reporting.
  • Can integrate with automated tools and auto-log results.
  • Web-based, so excellent for distributed teams.

Cons:
  • The upgrade process between versions can be fraught.

8
Test tools / Screenshot Captor
« on: March 16, 2017, 11:21:38 AM »
ScreenshotCaptor is an excellent tool that I have used for many years.

It is a useful tool for a tester, able to grab screens, parts of screens, provide annotations, etc., ready for inclusion in issue reports or user manuals.

It has been rock steady and I haven't detected any crashes in years.

This can be downloaded from https://www.donationcoder.com/Software/Mouser/screenshotcaptor/

9
Sometimes when you run SoapUI tests against a variety of different servers, some tests will only be required on specific servers, or will react differently on each server (e.g. datapaths, test data vs real data...)

A quick and dirty way to adapt your groovy assertion script to this is to detect the endpoint (which server is being used) and change the flow of the test in situ.

Here's a sample of code to do this:

Code: [Select]
thisEndPoint = context.getProperty("EndPoint")
log.info "- Project endpoint: $thisEndPoint"
if (thisEndPoint.contains("server1"))
{
    log.info "- This test is running against server 1."
    // Do the test that only works on server 1.
}
else
{
    log.info "- This test is running against server 2."
    // Do the test that only works on server 2.
}

10
So, coding in SoapUI.  Always fun.

I'm aware that it is possible to have project-wide groovy setup scrips, but these seem a bit limited, and won't run sometimes.

My challenge was to create some dates (for WSDL testing), then use these dates throughout the project (both in code, and directly inside the requests).

Here are the code examples of how I did it:

Setting the project-wide variables

OK, so I selected the Project root, and viewed the Project's [Custom Properties] tab.
I added each of the property names that I wanted to use, e.g.

dtToday (current date)
dtTomorrow (tomorrow)
dtNextWeekDay (the next available weekday after today)
dtNextSaturday (the next available Saturday)
dtNextSunday (the next available Sunday)

Setting the variables in code

I tried to create a Project setup script, but this failed with an error: "java.lang.NullPointerException: Cannot get property 'testSuite' on null object"

To get around this, I created a "First Test Suite" containing just a groovy script, and called it "Setup Script", imaginatively enough.

This contains:

Code: [Select]
import groovy.time.TimeCategory
def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context )

log.info "--------------------------------------------------------------------------------"
log.info "TEST SETUP"
log.info "--------------------------------------------------------------------------------"

// To read a project-wide variable:
// log.info context.expand('${#Project#dtToday}')

// To write to a project-wide variable:
// context.testCase.testSuite.project.setPropertyValue("dtToday","coo2")
// log.info context.expand('${#Project#dtToday}')

// To use inside a request...
// <TargetDepartureTime>${#Project#dtNextWeekDay}</TargetDepartureTime

use (TimeCategory)
{
// Get (today)
dtToday = new Date().format("yyyy-MM-dd'T12:00:00'")
context.testCase.testSuite.project.setPropertyValue("dtToday",dtToday)
log.info "Today = " + context.expand('${#Project#dtToday}')

// Get (tomorrow)
dtTomorrow = new Date() + 1.day
dtTomorrow = dtTomorrow.format("yyyy-MM-dd'T12:00:00'")
context.testCase.testSuite.project.setPropertyValue("dtTomorrow",dtTomorrow)
log.info "Tomorrow = " + context.expand('${#Project#dtTomorrow}')

// Get (nextWeekDay)
dt = new Date() + 1.day
weekday = dt[Calendar.DAY_OF_WEEK]
if (weekday == Calendar.SATURDAY)
{
dt += 2
}
if (weekday == Calendar.SUNDAY)
{
dt += 1
}
weekday = dt[Calendar.DAY_OF_WEEK]

dtNextWeekDay = dt.format("yyyy-MM-dd'T12:00:00'")
weekday = dt.format("EEEE")
context.testCase.testSuite.project.setPropertyValue("dtNextWeekDay",dtNextWeekDay)
log.info "Next Weekday = " + context.expand('${#Project#dtNextWeekDay}') + " ($weekday)"

// Get (nextSaturday)
dt = new Date() + 1.day
while (dt[Calendar.DAY_OF_WEEK] != Calendar.SATURDAY)
{
dt++
}
weekday = dt[Calendar.DAY_OF_WEEK]
dtNextSaturday = dt.format("yyyy-MM-dd'T12:00:00'")
weekday = dt.format("EEEE")
context.testCase.testSuite.project.setPropertyValue("dtNextSaturday",dtNextSaturday)
log.info "Next Saturday = " + context.expand('${#Project#dtNextSaturday}') + " ($weekday)"

// Get (nextSunday)
dt++
weekday = dt[Calendar.DAY_OF_WEEK]
dtNextSunday = dt.format("yyyy-MM-dd'T12:00:00'")
weekday = dt.format("EEEE")
context.testCase.testSuite.project.setPropertyValue("dtNextSunday",dtNextSunday)
log.info "Next Sunday = " + context.expand('${#Project#dtNextSunday}') + " ($weekday)"
}

log.info "--------------------------------------------------------------------------------"
log.info "TEST SETUP COMPLETED"
log.info "--------------------------------------------------------------------------------"

When I run this Groovy script, the log output is as follows:

Code: [Select]
Sun Mar 08 07:40:49 GMT 2015:INFO:--------------------------------------------------------------------------------
Sun Mar 08 07:40:49 GMT 2015:INFO:TEST SETUP
Sun Mar 08 07:40:49 GMT 2015:INFO:--------------------------------------------------------------------------------
Sun Mar 08 07:40:49 GMT 2015:INFO:Today = 2015-03-08T12:00:00
Sun Mar 08 07:40:49 GMT 2015:INFO:Tomorrow = 2015-03-09T12:00:00
Sun Mar 08 07:40:49 GMT 2015:INFO:Next Weekday = 2015-03-09T12:00:00 (Monday)
Sun Mar 08 07:40:49 GMT 2015:INFO:Next Saturday = 2015-03-14T12:00:00 (Saturday)
Sun Mar 08 07:40:49 GMT 2015:INFO:Next Sunday = 2015-03-15T12:00:00 (Sunday)
Sun Mar 08 07:40:49 GMT 2015:INFO:--------------------------------------------------------------------------------
Sun Mar 08 07:40:49 GMT 2015:INFO:TEST SETUP COMPLETED
Sun Mar 08 07:40:49 GMT 2015:INFO:--------------------------------------------------------------------------------

Accessing / reading project-wide variables in Groovy

So, we have a script which runs when the project is run (via Bamboo, or TestRunner, whatever).
That sets the dates, which we we can use in our tests.

Here is a section of code which would use this variable:

Code: [Select]
log.info context.expand('${#Project#dtToday}')
That picks up the project-wide property "dtToday" and prints it out.  Or puts it into a local variable for working with.

Accessing / reading project-wide variables in the SoapUI request

How do we use this value inside a SoapUI WSDL call?  Not too difficult.  Like this:

Code: [Select]
         <Departure>
            <TargetDepartureTime>${#Project#dtToday}</TargetDepartureTime>
            <EarliestDepartureLeeway>PT0M</EarliestDepartureLeeway>
            <LatestDepartureLeeway>PT120M</LatestDepartureLeeway>
         </Departure>

So you can see here we pipe in the project-wide property dtToday directly, and this gets expanded and sent as part of the test request.

Writing to project-wide variables in a Groovy script

To write information back out to the project-wide variable, we can use a line of Groovy code like this:

Code: [Select]
context.testCase.testSuite.project.setPropertyValue("dtToday","2015-03-08T15:45:00")
That will override any existing value and will be the new value to use.

11
Coffee lounge / New testing styles?
« on: April 26, 2014, 08:27:17 AM »
OK, a colleague sent this to me.  It's basically a suggested set of new testing styles that could be applied to projects that are a little... out of control...

The following testing programs will be implemented immediately as additions to the regularly scheduled regression testing:

  • Aggression Testing: Punching all developers with an open bug.
  • Confession Testing: All developers must admit what they either cannot do or have given up on.
  • Digression Testing: Developers must change the subject and ramble when the topic of bugs comes up.
  • Repression Testing: All developers must tell everyone who they secretly want to kill.
  • Oppression Testing: All developers will be required to work 24 hours a day until all bugs are fixed.
  • Depression Testing: All developers must explain which bugs make them sad, and why.
  • Succession Testing: Developers must be able to name the chain of command in the event that a PM dies.
  • Hessian Testing: QA will be done with a sack over your head.
  • Joe Pescian Testing: All functions to be tested by a hot-headed Mafioso.

12
The perception of QA staff varies enormously, as does the understanding of what skills we have, and what we can do within the companies we work for.

How well are you understood in your role, and how much opportunity do you get to spread your wings and exercise your skill and judgement?

(Thankfully at my current place I am fairly well understood, so job satisfaction is quite good!)

John.

13
Training / Testing Solutions Group
« on: May 22, 2013, 12:45:47 PM »
I have been trained at several levels:

ISTQB Foundation Course in Software Testing
ISTQB Intermediate Course in Software Testing
ISTQB Advanced Test Manager

I have attended all of these courses at Testing Solutions Group in Houndsditch in London, and I can say that they are a fantastic group with good training abilities.  I passed all of my courses with them first time, and cannot recommend them highly enough.

Testing Solutions Group Ltd
117-119 Houndsditch
London
EC3A 7BT
United Kingdom

http://testing-solutions.com/

Call +44(0)20 7469 1500
Fax +44(0)20 3411 8637

Training Enquiries: training@testing-solutions.com
Consultancy Enquiries: consultancy@testing-solutions.com
General Enquiries: enquiry@testing-solutions.com


My only other recommendation is that these training courses can be brutal due to the sheer quantity of stuff delivered / discussed.  Stay over if you can, rather than commute - though avoid the Liverpool St Travelodge just behind the training centre - that's pretty rank.

John.

14
Coffee lounge / Welcome to the QualityScape forum
« on: May 21, 2013, 09:14:19 PM »
Welcome to the QualityScape forum!

We aim to to provide a thriving community of testers and tester-challenged users.

Asl your questions, and maybe we can help...

John.

Pages: [1]