Archive

Archive for January, 2015

Why I should do UAT (User Acceptance Testing) ?

January 28, 2015 Leave a comment

UAT is the client view (end-user), so the most important tests will be here. I know that you can be a developer that started in QA automation area and you probably don’t like to do these tests and you don’t see the value of them, but as a professional of QA you should be concerned with the client point of view and his expectations with the quality of the product. Remember QA is the area of the quality and it is not only about a pattern and it is about testing as a client.

Reduce chances of error in LIVE Environment: Some scenarios you only discover in the phase UAT. Maximum possible scenarios are identified and tested before software moved to LIVE environment.

Increase User Satisfaction: You can test usability and real performance only in this type of test, because here you can test according with the device, real environment, etc. UAT provides full-fledge access of software to user, which gives him a lot of confidence as well as satisfaction to allow him to test the software that soon he will be using in a LIVE environment.

Reduce risk of regulatory & other compliance: You want to be sure that any mistakes even the most simple not will be forgotten. Some scenarios are discovered only in this phase (Don’t forget that you are working with humans, so if you want to have absolutely sure that nothing was forgotten, it is better test). As in UAT, the system is tested on maximum business scenarios; the risk of regulatory and other compliances that may bring penalties in term of financial impact, opportunity loss or customer dissatisfaction can be minimized.

Reduce Time: You can reduce the time of the teste in this phase, because you will have more knowledge to know if some scenarios are duplicated or not. In new/automated system, there is a chance that the system has automated some business processes along with some changes in existing processes, which might have increased some process steps found to be unnecessary or wasting time in the LIVE environment, UAT allows users to identify those unnecessary steps before going into the LIVE environment, it allows organizations to save time by reducing process steps that may take time in the LIVE environment and incur extra costs.

Business reputation: Quality is reputation, if your client discover a small bug in your application, the client confiability will fall together with the quality of your product. For this reason the client point of view is the most important test. If due to software solution, organization is unable to provide the services to its customer or provide the services with delay or somehow impact customer by giving wrong figures or showing wrong transaction in customer’s account, this may blow the business reputation and definitely results in customer dissatisfaction, and with this, the company may lose a good amount of business that was successfully in hand having the legacy system in place.

Bye guys 🙂

Sources:

http://www.batimes.com/articles/uat-tips-and-templates.html
https://www.develop.com/training-course/user-acceptance-testing-for-business-analysts

How choose the order of the browsers that I will be testing ?

January 25, 2015 Leave a comment

By testing your web application using a variety of web browser types, you better emulate the UI experience of your users who may run different browsers. For example, your application might include a control or code in Internet Explorer that is not compatible with other web browsers. By running your coded UI tests across other browsers, you can discover and correct any issue before it impacts your customers.

To discover what is the priority that you should test the browsers is simple, but you have a lot of points to worry.

– Hardware differences

– Monitor resolution settings

– Browser and computer preferences

Usage of each browser 

What is the time that you have ?

When you will be the release ?

 

top 10 browsers to test?

  1. Chrome 39
  2. Internet Explorer 11
  3. Firefox 35
  4. Internet Explorer 10
  5. Chrome 38

 

Usage share of desktop browsers for December 2014
Source Chrome Internet
Explorer
Firefox Safari Opera Other
Stat Counter 49.7% 24.6% 18.0% 4.7% 1.5% 1.6%
W3Counter 42.5% 17.6% 15.6% 14.6% 3.2% 6.5%
Wikimedia 48.1% 17.5% 16.7% 4.8% 1.5% 11.4%
Net Applications 22.7% 59.1% 11.9% 5.0% 0.9% 0.4%

 

How to measure the order of the browsers ?

The ideal is you focus in the most usage browser first and after you can think about the others. So, let’s imagine that you have 4 weeks to test all browsers and you take 1 week to test all the scenarios in one browser. You need to choose the first week to test in the most used browser for your end user, and the second week for the second most used and so on.

This is the ideal in the most of cases, but of course everything depends of how many people you have to help you with the tests, the date of the release, and the other points I already told.

 StatCounter-browser-ww-monthly-200807-201412

 

 

 

 

 

 

 

Tips: 

– Don’t Overestimate neither Underestimate a browser version.

– If you are looking for just mainstream use, StatCounter has a really nice graph to show you what browser you should test.

 

Tools & emulators that you can use:

  • The Browser Sandbox
  • BrowserShots.org
  • CrossBrowserTesting.com
  • SauseLabs

 

Thank you guys ! See you next week 🙂


Source
http://crossbrowsertesting.com/browsers-to-test/

http://en.wikipedia.org/wiki/Usage_share_of_web_browsers

https://msdn.microsoft.com/en-us/library/jj835758.aspx

http://www.digitalfamily.com/tutorials/test-your-website-in-differen-web-browsers/

http://gs.statcounter.com/#desktop-browser-ww-monthly-200807-201412

Basics gestures for calabash-android

January 20, 2015 Leave a comment

Hi guys, today I will post just some basics and very basics commands from the Calabash android API (0.5.5):

– tap_mark(“query”)

– touch(“query”)

– double_tap(“query”)

– perform_action(“touch_coordinate”, center_x, center_y)

– perform_action(“double_tap_coordinate”, center_x, center_y)

– long_press(“query”, options)

– drag (“query”)

– pan_left(options)

– pan_right(options)

– pan_up(options)

– pan_down(options)

– pan (“query”)

– flick_left (options)

– flick_right (options)

– flick_up (options)

– flick_down (options)

– flick (“query”)

– flash(“query”)

– pinch_out (options)

– pinch_in (options)

– pinch (“query”)

– find_coordinate (“query”)

– tap_when_element_exists (“query”)

– long_press_when_element_exists (“query”)

– query_result? (“query”)

 

See you on Wednesday !

Font: https://github.com/calabash/calabash-android/blob/master/ruby-gem/lib/calabash-android/touch_helpers.rb

What is the difference between an interface and abstract class?

Hi guys, I am without internet in my house until 19th 😦
Because of this, I will post some interesting things, but nothing that I wrote. (Because I am without time/internet). Sorry, for this !

Interface

An interface is a contract: the guy writing the interface says, “hey, I accept things looking that way“, and the guy using the interface says “OK, the class I write looks that way“.

An interface is an empty shell, there are only the signatures (name / params / return type) of the methods. The methods do not contain anything. The interface can’t do anything. It’s just a pattern.

E.G (pseudo code):

// I say all motor vehicles should look like this:
interface MotorVehicle
{
void run();


int getFuel();
}

// my team mate complies and writes vehicle looking that way
class Car implements MotorVehicle
{


int fuel;


void run()
{


print("Wrroooooooom");
}


int getFuel()
{
return this.fuel;
}
}

Implementing an interface consumes very little CPU, because it’s not a class, just a bunch of names, and therefore there is no expensive look-up to do. It’s great when it matters such as in embedded devices.

Abstract classes

Abstract classes, unlike interfaces, are classes. They are more expensive to use because there is a look-up to do when you inherit from them.

Abstract classes look a lot like interfaces, but they have something more : you can define a behavior for them. It’s more about a guy saying, “these classes should look like that, and they have that in common, so fill in the blanks!”.

e.g:

// I say all motor vehicles should look like this :
abstract class MotorVehicle
{

int fuel;

// they ALL have fuel, so why not let others implement this?
// let's make it for everybody


int getFuel()
{

return this.fuel;
}


// that can be very different, force them to provide their
// implementation
abstract void run();

}

// my team mate complies and writes vehicle looking that way
class Car extends MotorVehicle
{
void run()
{
print("Wrroooooooom");
}
}

Implementation

While abstract classes and interfaces are supposed to be different concepts, the implementations make that statement sometimes untrue. Sometimes, they are not even what you think they are.

In Java, this rule is strongly enforced.

See you next week !

Font: http://stackoverflow.com/questions/1913098/what-is-the-difference-between-an-interface-and-abstract-class

%d bloggers like this: