Pinscher Testing

“How can I best get up the mountain?” – Just climb upwards, and don’t think about it! Friedrich Nietzsche

Page 2 of 8

Run Selenium Grid on Microsoft Edge browser

To run your tests on Microsoft Edge browser need to download IEDriverServer.exe and MicrosoftWebDriver.exe

Microsoft WebDriver download

IEDriverServer.exe 64 bit Windows IE

IEDriverServer.exe 32 bit Windows IE

 

Selenium Grid Node start with:

java -jar selenium-server-standalone-last_version.jar -role node -nodeConfig nodeconfig.json -Dwebdriver.edge.driver=”C:\Program Files (x86)\Microsoft Web Driver\MicrosoftWebDriver.exe”

Set nodeconfig.json:


{
  "capabilities":
  [
    {
      "seleniumProtocol":"WebDriver",
      "browserName":"MicrosoftEdge",
      "maxIstances":1
    }
  ],
  "configuration":
  {
    "proxy": "org.openqa.grid.selenium.proxy.DefaultRemoteProxy",
    "maxSession": 5,
    "port": 4447,
    "register": true,
    "registerCycle": 5000,
    "hubPort": 4444
    "hubHost": "ip_hub"
  }
}

 

Happy testing on Microsoft Edge!;)

share me!:))Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someonePrint this page

SonarQube and Jenkins

SonarQube is an open platform to manage code quality. As such, it covers the 7 axes of code quality:

  1. Architecture and Design
  2. Duplications
  3. Unit Tests
  4. Complexity
  5. Potential bugs
  6. Coding rules
  7. Comments

SonarQube has got a very efficient way of navigating, a balance between high-level view, dashboard, TimeMachine and defect hunting tools. This enables to quickly uncover projects and/or components that are in Technical Debt to establish action plans.

More than 20 programming languages are covered through plugins.

Get Started in Two Minutes.

  • After download of SonarQube server, sonarqube-downloads
  • #On Windows, execute – C:\sonarqube\bin\windows-x86-xx\StartSonar.bat
    #On other operating system, execute – /etc/sonarqube/bin/[OS]/sonar.sh console
    SonarQube host url = http://localhost:9000
  • Install a Database (we choose MySql on Mac OS)
    brew install mysql
    mysql.server restart (or from System Preference -> MySQL -> Start MySQL Server)
    create user ‘sonarqube’@’localhost’ identified by ‘sonarqube’;
    create database sonarqube;
    grant all privileges on sonarqube.* to ‘sonarqube’@’localhost’; (assign to user create the DB)
    use sonarqube; (check)
    show tables; (check)
  • Install SonarQube Plugin (* purchase plugins)
    Sonar-Installing-Plugin
  • On Jenkins install the plugin for SonarQube
    sonarqube-jenkins-plugin so to set SonarQube Runner and SonarQube on Jenkins Configuration
  • In sonar-scanner.properties let’s set the values for the DB created to SonarQube
  • Continue in SonarQube and Gradle for Android (an example)

sonaqube-jenkins1

 

 

 

 

sonarqube-jenkins2

 

 

 

Happy Automatic Static Testing with SonarQube;)

share me!:))Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someonePrint this page

SonarQube and Gradle for Android

SonarQube is an open platform to manage code quality. As such, it covers the 7 axes of code quality:
1. Architecture and Design
2. Duplications
3. Unit Tests
4. Complexity
5. Potential bugs
6. Coding rules
7. Comments

Gradle is an open source build automation system that builds upon the concepts of Apache Ant and Apache Maven and introduces a Groovy-based domain-specific language (DSL) instead of the XML form used by Apache Maven of declaring the project configuration. Gradle uses a directed acyclic graph (“DAG”) to determine the order in which tasks can be run.
Gradle was designed for multi-project builds which can grow to be quite large, and supports incremental builds by intelligently determining which parts of the build tree are up-to-date, so that any task dependent upon those parts will not need to be re-executed.

To integrate SonarQube and Gradle in an Android project you need set the build.grade file of the feature in this way:

buildscript {
    repositories {
        ....
    }
    dependencies {
        ....
        classpath 'org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:1.2'
    }
}
subprojects {
    ....
    apply plugin: "sonar-runner"
    sonarRunner {
        sonarProperties {
            properties["sonar.sources"] += "src/main/java"
        }
    }
}

task clean(type: Delete) {
    ....
}

allprojects {
    repositories {
        ....
    }
}

and build.gradle file of the app in this way:

apply plugin: "sonar-runner"
....

android {
    compileSdkVersion 23
    buildToolsVersion "23.0.1"
dataBinding {
        	enabled = true
    	    }
sonarRunner {
        sonarProperties {
            property "sonar.host.url", "http://localhost:9000"
            property "sonar.projectKey", "org.sonarqube:java-gradle-simple"
            property "sonar.projectName", "App Demo SonarQube"
            property "sonar.projectDescription", "App Demo SonarQube Description"
            property "sonar.projectVersion", "1.0"
            property "sonar.projectBaseDir", "app/src/main/java"
            property "sonar.working.directory", "build/sonar"
            property "sonar.scm.provider", "git"
        }
    }
....

Happy Static Testing with SonarQube!;)

share me!:))Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someonePrint this page

Smartphone Test Farm for iOS

Apple with Xcode 7 introduces UI Testing as new features of the existing XCTest framework.

The UI Testing advantages are:
– Easy UI recording
– Performance Test
– Code Coverage

ui-testing-videos-wwdc2015

With UI Testing it is possible to run tests on physical devices and simulators.
Instead of running the tests in series to n devices connected to the MAC through this script you will be able to run the tests in parallel on n device attached (in the example we perform the tests in parallel on four devices at a time).
We must create in this specific case four job for the execution of tests on the devices.

Jenkins job “Smartphone Test Farm iOS”


#!/bin/bash

set -e

job_name="iOS UI Testing Tests - App Example"
num_jobs=4

function log {
echo "[$(date)] $1"
}

#Read attached devices
devices=$(instruments -s devices | grep -v Simulator | cut -f2 -d\[ | cut -f1 -d\] | grep -v - | tail -n +2)

if test -z "$devices"; then
log "Warning! no devices found"
exit 1
fi
j=0
for i in $devices; do

job_id=$(( $j % ${num_jobs} ))

log "Doing device id: $i"
curl -X POST "https://jenkins_url/job/${job_name}_${job_id}/build" --data-urlencode json="{\"parameter\": {\"name\":\"devices\",\"value\":\"${i}\"}}"
j=$(($j + 1));
done

log "Invocked jenkins without errors"

 

#N Jenkins job to execution of tests “iOS UI Testing Tests – App Example”

scan –scheme “example_scheme” –destination ‘id=’${devices}

scan is part of fastlane: connect all deployment tools into one streamlined workflow.
scan uses the latest APIs and tools to make running tests plain simple and offer a great integration into your existing workflow, like fastlane or Jenkins.
scan-fastlane

share me!:))Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someonePrint this page

STF – Smartphone Test Farm for Android

STF (or Smartphone Test Farm) is a web application for debugging smartphones, smartwatches and other gadgets remotely, from the comfort of your browser.

Installation:
1. git clone https://github.com/openstf/stf.git
2. brew install rethinkdb graphicsmagick zeromq protobuf yasm pkg-config
3. npm install -g stf
4. git config –global url.https://github.com/.insteadOf git://github.com/
5. npm install
6. npm link
7. rethinkdb
8. stf local –public-ip http://IP_address
9. http://IP_address:7100/#!/devices

Happy Testing with STF!;)

STF

share me!:))Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someonePrint this page

Winium – Windows Phone Testing

Winium, as Appium, is an open source test automation tool, Selenium-based tool, for testing Windows Phone Apps on Emulators.
Winium is an alternative to Coded UI, test automation tool of Visual Studio Enterprise.

In the project that you want to test you just need to add the reference to Winium.StoreApps.InnerServer, run the following command in the Package Manager Console of Visual Studio:
Install-Package Winium.StoreApps.InnerServer

At the source code following add lines to be called on the UI thread after visual root is initialized:
AutomationServer.Instance.InitializeAndStart();

For each element that you want test need to add this instruction:
AutomationProperties.AutomationId = “loginpage” AutomationProperties.Name = “loginpage” (for example you want to scroll login page).

If you want to write tests in Python you need to install Python and Selenium Package:
pip install selenium (selenium-python-installation)

Download and Start Winium Server (Winium.StoreApps.Driver.exe):
Winium.StoreApps.Driver.zip

and run tests. (python test_register_form.py).

Test Register Form with Winium, example:


# coding: utf-8
import unittest
import os

from selenium.webdriver import Remote
from selenium.webdriver.common.by import By
from selenium.webdriver.common.keys import Keys

class TestMainPage(unittest.TestCase):
desired_capabilities = {
"app": os.getenv('APPX', '') #we take appx from env and from a job on jenkins (see under test)
}

def setUp(self):
self.driver = Remote(command_executor="http://localhost:9999",
desired_capabilities=self.desired_capabilities)

def test_content(self):
driver = self.driver

#close keyboard
#name_login.send_keys(Keys.RETURN)
login_page = driver.find_element_by_id('loginPage')
login_page.click()

button_register = driver.find_element_by_id('RegisterBtn')
button_register.click()

#step 1
name = driver.find_element_by_id('name')
name.send_keys("nametest")
name = driver.find_element_by_id('surname')
name.send_keys("surnametest")
credential_page = driver.find_element_by_id('credentialPage')
credential_page.click()
button_next = driver.find_element_by_id('nextbutton')
button_next.click()

#step 2
phone = driver.find_element_by_id('phone')
phone.send_keys("0123456789")
email = driver.find_element_by_id('email')
email.send_keys("testemail@wind.it")
contact_page = driver.find_element_by_id('contactPage')
contact_page.click()
button_next = driver.find_element_by_id('nextbutton')
button_next.click()

#step 3
otp = driver.find_element_by_id('otp')
otp.send_keys("4444")
otp_page = driver.find_element_by_id('otpPage')
otp_page.click()
button_next = driver.find_element_by_id('nextbutton')
button_next.click()

#step 4
#switch on/off
privacy = driver.find_element_by_id('privacy')
privacy.click()
button_next = driver.find_element_by_id('nextbutton')
button_next.click()

#step 5
password = driver.find_element_by_id('password')
password.send_keys("passwordtest")
conferma_password = driver.find_element_by_id('confermapassword')
conferma_password.send_keys("passwordtest")
password_page = driver.find_element_by_id('passwordPage')
password_page.click()
button_next = driver.find_element_by_id('nextbutton')
button_next.click()

def tearDown(self):
self.driver.quit()

if __name__ == '__main__':
unittest.main()

 

Jenkins job to creation APPX (execute windows batch command):
nuget restore ExampleApp.sln
MSBuild /t:Clean,Build /p:Configuration=Release

Winium.StoreApps

Happy testing on Windows Phone Apps!;)

share me!:))Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someonePrint this page

The Test Tower

The Software Quality Assurance (SQA) is intended to ensure that the software conforms to quality standards defined and is a continuous process that accompanies the entire life cycle of the product.
The most relevant quality measures of the software can be grouped as follows:

Is that for which it was designed – Functional requirement
No unexpected behavior – Functional requirement

Performance – Non-functional requirement
Safety -Non-functional requirement

The QA is the one that processes the testing strategy for the Team and, consequently, for the company in which he works.

The capabilities required to QA are various, such as maintaining governance during test development, collaborate with other professionals, know how to communicate, able to move in changing scenarios that present increasingly different functionality.
Everything, always keeping a clear objective to ensure product quality.
We conclude that the QA is architect of the testing process.

The first step which underpins the entire testing process is the definition of the User Acceptance Criteria (UAC) that establish the proper operation and completion of the product.
More specifically, the UAC is a set of instructions, which specify the functional requirements and not of the product, by defining the concept of quality of the same. The UAC constitute our “Definition of Done” in respect of an Epic, Feature and Story.
The definition of UAC allows the Team to figure out when it’s done and not to forget important borderline issues.
The UAC are produced through collaboration between developers, testers, and product owner and are created before the development, during the planning phase.
UAC are expressed at high levels (conceptual, not detailed) and then in the form that works best for the Team (keep it minimal).

During Kick off, QA and developer, in a 10-15 minute session must explicate the User Acceptance Test (UAT) in order to define the behavior of the system and ensure the realization of the product as expected.
The QA and developers agree, also, the tests to implement, sometimes also including the product owner and the other stackeholder.
The implementation of the test takes place during development (ideally test-first).
It is considered appropriate to build a Map of User Acceptance Test automatic and/or manual in order to improve the testing and development process. They will be designed at the level of User Tests, Unit Tests, Integration Tests, Alpha/Beta Tests, Exploratory Tests, Performance Tests, Security Tests, and Static Tests.
So that QA does not become a bottle neck the quality should be the responsibility of the company and the Team.

Why “Test Tower” instead of “Test Pyramid”?
Because the pyramids are the XXVII century A.C.

ahahahah - no!

 

 

 

 

 

The test pyramid is a concept developed by Mike Cohn, described in His Book “Succeeding with Agile”.
The pyramids of testing allow you to see which test levels to be performed and highlight the amount of tests for each type.
Over the years we have been developed various types of testing pyramids, but now we wonder if we still need to see the testing through a pyramid.

As well as products developed by companies that are revolutionizing the behaviors and habits of people (social networks, search engines, online reservations, online shopper, car-bike sharing, online services) go towards quality and focus on it to differ from continuous rising competitors, even the testing has to go in that direction. One must speak of towers, towers where testing are not important quantities for each level but the quality of each test for each level!

Instead of displaying the levels and types of tests through the pyramids I prefer to take inspiration from the palaces and towers (Unicredit Tower), populating the city where I live for a while, Milan.

Test Tower

 

 

 

 

 

 

 

 

 

As mentioned in the first part of this article, it is essential to clearly define the User Acceptance Criteria for PO, UX, Team Manager, and convert them to User Acceptance Tests.
Is essential, also, do the following:

  • Define a set of User Tests with the UX department, before and after the development of the Feature.
  • Create Unit Tests and Integration Tests, backend and frontend and from backend to frontend (EndToEnd Tests).
  • Create user groups who want to try out the product with Feature realized, internally and/or externally of the company.
  • Minimize Exploratory Tests but remember that the software is full of surprises. No matter how careful or skilled you are, when you create software it can behave differently than you intended. Exploratory testing mitigates those risks.

Remember that Performance, Security and Static Tests will highlight other critical aspects of the produced Feature, up to rethink it completely.
Finally, the CI (Continuous Integration) allow control of the Feature to every Build.

Finally, although it is important to define the amount of tests to be performed for each test level (Test Pyramid), the quality of each single test for each level of testing and careful planning of the testing process and strategy will lead to Products high quality (Test Tower).

 

Giuseppe Cilia, Quality Assurance Engineer at Wind Digital S.P.A., Milan.

share me!:))Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someonePrint this page

Keep It Functional, an iOS Functional Testing Framework

KIF, Keep It Functional, is an iOS integration test environment. It allows easy automation of iOS applications, taking advantage of the attributes of accessibility that the operating system provides to people with visual impairments.
KIF builds and tests using XCTest, a standard test target. The testing is conducted synchronously in the main thread allowing for greater complexity and logic of composition.

context(@"in saved AdPage", ^{
   it(@"remove saved ad by action button in row", ^{
      tap(@"Search") _then
      wait_default_time _then
      tap_item_in_collection_view(SBTResultsCollectionView, 2) _then
      wait_view(adTitle_app) _then
      tap(SBTSaveAdButton) _then
      tap(@"Favourites") _then
      wait_default_time _then
      tap(@"Modify") _then
      wait_default_time _then
      tap(SBTSavedAdCellRemoveAdButton) _then
      wait_default_time _then
      wait_absence_of_view(adTitle_app) _end
   });
});

…where tap, wait, tap_item_in_collection_view, wait_absence_of_view are described here:
KIFUITestActor.h

share me!:))Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someonePrint this page

Kiwi, a Behavior Driven Development library for iOS development

Kiwi is a Behavior Driven Development library for iOS development.
The idea behind Kiwi is to have unit tests readable and simple to implement.
The tests are written in Objective-C and run in Xcode to provide a test environment that is as unobtrusive and simple as possible in terms of test execution and error reporting.

#import "Kiwi.h"
#import "ChangeSearchParameterViewController.h"
#import "ChangeSearchParameterViewController+SBTPrivate.h"

SPEC_BEGIN(KiwiChangeSearchParameterTests)

describe(@"Change search parameter controller", ^{
   context(@"when created", ^{
       NSManagedObjectContext *moc = [Model setupCoreDataStackWithInMemoryStoreAndLoadConfiguration];
       Search *search = [Search baseObjectInContext:moc];
       
       id fakeDelegate = [KWMock mockForProtocol:@protocol(ChangeSearchParameterViewControllerDelegate)];
       
       ChangeSearchParameterViewController *changeSearchParameterViewController = [[ChangeSearchParameterViewController alloc] initWithSearch:search];
       changeSearchParameterViewController.delegate = fakeDelegate;
       
       it(@"should not be nil", ^{
           [[changeSearchParameterViewController should] beNonNil];
       });
       it(@"should has delegate equal to fakeDelegate", ^{
           [[fakeDelegate should] equal:changeSearchParameterViewController.delegate];
       });
       context(@"when dismissed", ^{
           it(@"should call delegate", ^{
               [[fakeDelegate should] respondToSelector:@selector(changeSearchParameterDidFinish:modifiedSearch:changedParameters:)];
               [[fakeDelegate should] receive:@selector(changeSearchParameterDidFinish:modifiedSearch:changedParameters:)];
               [changeSearchParameterViewController notifyDelegateAndDismiss];
           });
       });
   });
});

SPEC_END

Kiwi site

share me!:))Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someonePrint this page

Acceptance Criteria and Acceptance Test

The first step which underpins the entire testing process is the definition of Acceptance Criteria (AC) that establish the correct operation and completion of the product.
More specifically, the AC is a set of instructions, which specify the functional requirements and not the product, defining the concept of quality of the same. The AC constitute our “Definition of Done” relative to an Epic, Feature and Story.
The definition of the AC allows the team to figure out when it’s done and not to forget important borderline.
AC are produced through collaboration between developers, testers and product owner and are created before the development, during the planning phase.
AC are expressed at high levels (conceptual, not detailed) and then in the form that works best for the team (keep it minimal).

During the Kick off QA and developer in a session of 10-15 minutes should achieve the Acceptance Test (AT) in order to define the behavior of the system and ensure the realization of the product as expected.
QA and developers agree, also, the tests to implement, sometimes also including the product owner and the other stackeholder.
The implementation of the test takes place during development (ideally test-first).

It is considered appropriate to build a Map of Acceptance Test automatic and / or manual to improve the process of testing and development. They will be designed at the level of Unit Testing, Integration Testing, End to End Test, UI Test and Boundary Test.
A basic rule during the writing test, especially when we talk about Unit Test, often difficult to understand, is to assign a meaningful name so that the QA and the developer can then maintain them. So once defined the test or set of tests anyone can test the story, feature or epic.

share me!:))Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someonePrint this page

Page 2 of 8

Powered by WordPress & Theme by Anders Norén