5 reasons to learn software testing theory

Quite often I meet colleagues who are wondering why should they learn software testing/development theory. A couple of times I was accused of being too focused on theory instead of practice. All of that made me think a lot on this question and I came to a couple of conclusions, which I’d like to share with you.

1. How can you know something is wrong if you don’t know how it should be?

All our (QA Engineers) work is about telling people what is not working as expected (this is related to software, processes, approaches and so on). There is no chance to be a good engineer without knowledge of how it should be. As a simple example, you won’t run a test case without strictly specified expected result, right? Of course, when we are talking about QA it’s not that easy and in many cases there is no only one ‘right’ way, but, nevertheless, understanding of how it should work can help us to avoid reinventing the wheel.

2. Remember the difference between QA and tester?

This is a fun point. I’m sure, you understand the difference between Software Tester and QA Engineer roles. We name ourselves QA Engineers in Linkedin (just checked through my contacts, no testers, only QAs). It is near to impossible to be a QA Engineer without understanding how things should work, what practices and approaches exist, what are pros/cons of each approach and so on. The main idea of this point is - if you want to be a QA Engineer, not just a Software Tester, - learn theory.

3. Theory is someone’s experience

Some people are saying that theory is too far from practice, this is the main reason why they don’t want to learn it. My answer to that would be - theory does not exist without practice. Practice always goes first, then people collect it into some model - theory. In other words, a theory is someone’s experience, collected and structured for you. So by learning theory you can avoid going through the evolution from the beginning, you can develop yourself and grow as QA faster.

4. Theory cannot be boring if you are excited about this area

Well, it actually can be quite boring. But! If you’ll not just read it in a passive way, but try to think how you’ll use it on your real project, it becomes exciting. Active reading is the main point here. Sometimes you don’t agree with the author, but even in this case, it is useful, because you understand your opponent better. So next time when you’ll read some boring theory book, try to consider if it’s relevant for your needs and realities and apply it on practice!

5. Theory is nothing without practice

And last, but for sure not least. If you are learning theory and not applying it in practice, probably, you wasted your time. The theory is there for us to use. Don’t afraid of it, don’t keep it pure and make it an axiom. Modify it, change it to your needs in the current situation and current project. This will help you to grow and get better all the time. And probably at some point, you’ll write your own book with your very own experience to make some people get bored :)

What do you think about theory? Share your opinion!

OkHttp - handy HTTP client for Java

One of my friends who is Java engineer suggested me to use this library. I really liked it, it allows you to implement your HTTP calls smoothly and without extra code :)

Find some examples of usage below (two first are taken from their documentation).

GET request: 

 OkHttpClient client = new OkHttpClient();  
 String run(String url) throws IOException {  
  Request request = new Request.Builder()  
    .url(url)  
    .build();  
  Response response = client.newCall(request).execute();  
  return response.body().string();  
 }  

POST request:

 public static final MediaType JSON  
   = MediaType.parse("application/json; charset=utf-8");  
 OkHttpClient client = new OkHttpClient();  
 String post(String url, String json) throws IOException {  
  RequestBody body = RequestBody.create(JSON, json);  
  Request request = new Request.Builder()  
    .url(url)  
    .post(body)  
    .build();  
  Response response = client.newCall(request).execute();  
  return response.body().string();  
 }  

This is my implementation of methods for HTTP calls.

 private JSONObject request(String path, String method, String body) throws ApiException {  
     Builder builder = new Request.Builder()  
       .url(baseUrl + path.replaceAll("^/", ""));  
     if (method.equals("POST")) {  
       builder.post(RequestBody.create(JSON, body));  
     }  
     else if (method.equals("DELETE")) {  
       builder.delete();  
     }  
     try {  
       Response httpResponse = httpClient.newCall(builder.build()).execute();  
       if (httpResponse.code() != 200) {  
         throw new ApiException(httpResponse.body().string());  
       }  
       String httpResponseBody = httpResponse.body().string();  
       System.out.println("ApiClient.request(" + path + "): " + httpResponseBody);  
       return (JSONObject)JSONValue.parse(httpResponseBody);  
     }  
     catch (IOException e) {  
       throw new ApiException(e.getMessage());  
     }  
   }  
   public JSONObject get(String resource, Map<String, String> params) throws ApiException {  
     return request(resource + "?" + urlEncodeUTF8(params), "GET", "");  
   }  
   public JSONObject post(String path, String body) throws ApiException {  
     return request(path, "POST", body);  
   }  

Charles: usage for native mobile application testing (IOS)

Mobile testing is new for me. I found extremely useful HTTP proxy tool Charles for monitoring traffic, which our mobile app sends/receives. It helped me to investigate bugs more deeply, not just their UI implication.

Set up Charles to see phone’s traffic

1. Install Charles on your computer.
2. Start Charles.
3. Make sure your phone and computer are connected to same WiFi network.
4. Find your network IP address in System Preferences -> Network.
5. Open WiFi settings on your phone: Settings -> WiFi -> {your WiFi network name} -> HTTP Proxy. Set proxy to Manual and enter your network IP address and Port (by default it’s 8888). Leave Authentication switched off.
   

   
6. Install root certificate on your IOS device, open following link in your phone browser: http://www.charlesproxy.com/getssl
7. In Charles add a domain which you want to monitor in Proxy -> SSL Proxying Settings; enable SSl Proxying:

9. Do any interactions in your app to make any HTTP calls, you should see a popup from Charles to confirm device usage.

Now you should see all calls, which your application makes and what are server responses.

Simulate Internet connection

First of all set up Charles on your computer (see steps above). To change your network connection settings do following steps:

1. In Charles open Proxy -> Throttle Settings. Enable throttling by checking check box:

2. Now you can select different throttle presets. You can set your custom network parameters or use ready settings like ‘3G’ throttle preset.

Useful article for setting up Charles with Android devices: http://jaanus.com/blog/2012/02/12/debugging-http-on-an-android-phone-or-tablet-with-charles-proxy-for-fun-and-profit/).

Enjoy your testing :)

Firefox driver - Unable to connect to host 127.0.0.1 on port 7055 after 45000 ms

CASE STUDY

My tests are written with Thucydides + Firefox Driver. Test suite is successfully running on my local machine. My task is to set up tests in CI on remote server. I’m using latest Webdriver and Firefox versions (Selenium documentation says they are compatible). Nevertheless, tests failed with “Unable to connect to host 127.0.0.1 on port 7055 after 45000 ms”.

SOLUTION

I faced this exception several times before. Every time I solved that issue by downgrading Firefox browser on my test environment and turning off automatic updates. This time it didn’t help. I tried several FF & Selenium versions without any success.

Then I found information that Firefox driver runs on 7055 port by default, if the port is busy it tries to run on 7054 or 7056 ports. So when those 3 ports are taken by some process - Webdriver won’t be able to start.

Indeed, I checked if those ports were taken using command:

lsof -i | grep 7055

It turned out that they were busy and this was a cause of the exception. I killed the processes on the named ports and my tests started running successfully.

So as a summary. I was using Thucydides + Firefox driver. In some cases when Thucydides work was interrupted unexpectedly it doesn’t finish it’s processes correctly. So some Firefox processes were hanging on mentioned above 7054-7056 ports and didn’t let driver start over again.

Hope this post will help someone to fix quite popular issue with Webdriver.

Sharing remote screen for Selenium tests monitoring

CASE STUDY

We have a big suite of Selenium tests. It is running on a remote continuous integration server (Jenkins). Some tests are successfully passing on the local machine but are always failing when running on the server. It was really difficult to find a cause of the failure on a remote server using only logs.

Task/goal: Find a way of graphical monitoring of the tests running process on the remote server.

SOLUTION

Short idea & results: We started sharing X display of a remote server over VNC to our local computers. This really helped, because now we can see what is going on with tests when they’re running on the remote machine and it is much easier to fix broken tests.

First of all install:

• Xvfb (on a remote server) - a server that performs all graphical operations in memory, not showing any screen output. From the point of view of the client, it acts exactly like any other server, serving requests and sending events and errors as appropriate. However, no output is shown.

• x11vnc (on a remote server ) - a Virtual Network Computing (VNC) server program. It allows remote access from a remote client to a computer hosting a X Window session and the x11vnc software, continuously polling the X server's frame buffer for changes

• VNC client (on a local machine) - a program that watches, controls, and interacts with a server. The client controls the server.

Follow the steps below:

1. Open your Jenkins project configuration page and make sure that this check-box is checked.

           Now Xvfb will start every time our project is building. Run a Jenkins project now.

2. Find a number of display on which your Jenkins job is running.

• in command prompt launch to your server via SSH and run a command: ps afx | grep vfb
• you should see something like this (in this case number of display is 2):   

 

3. Start x11vnc server on a display which you found in a previous step:

                       x11vnc -display :<NUMBER_OF_DISPLAY>

4. Create an SSH tunnel between your local machine and the server where you tests are running:
   
   
   
5. Run VNC client on your local machine, create a new connection. With Chicken of the VNC it looks like this:
   

Now click on Connect, wait for a while…

Woohoo! Now you see what is going on with your tests on a remote machine.

Тренинг "Exploratory Testing" (Андрей Дзыня)

Мне посчастливилось побывать на тренинге Андрея Дзыни “Exploratory Testing”. Мероприятие проходило в офисе компании, в которой я работаю (Cogniance). Наверное, всем известно, что тренинг этот проходит не в первый раз. Но! Теперь он обрел новый двухдневный формат. Итак, расскажу вам чем мы занимались.

День первый по большей своей части был теоретическим. Андрей рассказал об exploratory тестировании как таковом, о том чем оно отличается от scripted и ad-hoc тестирования. Также мы узнали много интересного о турах, евристиках, парном тестировании, построении функциональной карты приложения и об оформлении результатов тестирования. Занятие не ограничилось “сухой” теорией, нам дали возможность попрактиковаться в построении функциональной карты приложения, парном тестировании, участии в “дебрифах”, а также в составлении отчета о тестировании. Забыла о самом интересном - мы определяли свой тип тестировщика. Бонус дня: мы узнали много нового о лошадях и калькуляторах :)

День второй. С новыми силами и знаниями, уложившимися в голове, мы приступили ко второй части тренинга. Девиз дня: “Минимум теории - максимум практики”. Андрей рассказал об инструментах, которые могут облегчить жизнь тестировщика (в некоторые из них я влюбилась с первого взгляда). Нас разделили на команды, каждая команда отвечала за маленький кусок функциональности тестируемого приложения, для которого она должна была составить функциональную карту, протестировать его, представить результаты тестирования. Все команды соединили части функциональных карт в одну большую (нашу гордость).

Участники рисуют функциональную карту

Мы попрактиковались работать в стиле сессий, это было очень интересно и ново для меня. Эффект потрясающий, особенно для людей, имеющих проблемы с управлением временем. В ходе тестирования мы использовали инструмент для управления сессиями, который тоже показался довольно удобным.

Участники работают во время сессии

Завершение дня прошло в общении, обмене опытом из своих текущих проектов. Мы задавали вопросы Андрею, который охотно и подробно на них отвечал. Для особо стойких тренинг завершился на кухне за чашкой чая и интересной беседой о тестировании.

Итог. Безусловно, тренинг стоит внимания. Признаться, всегда относилась с опаской ко всем тренингам-семинарам по ручному тестированию (возникает банальный вопрос “да чего я там не знаю?”). Но, я изменила свое мнение за эти два дня. Время было проведено продуктивно, насыщенно новой для меня информацией. Андрей всегда делал акцент на практическом применение всего, о чем шла речь. И самое главное - я получила от тренинга море воодушевления, позитива и новых идей. Теперь не терпится начать использовать все полученные знания на практике и совершенствоваться, совершенстваться и... угадайте что? Творческих вам успехов!

Google Chrome Remote Debugging для тестирования производительности мобильного веб-приложения

Недавно на проекте возникла интересная задача. Разрабатываем мы мобильное веб-приложение. Нужно было измерить время загрузки отдельных элементов страницы (*.js, *.css, *.png файлы) для разных типов подключений: WiFi, Edge, 3G.

После не очень длительного исследования существующих решений, мой выбор пал на относительно новую возможность Google Chrome - Remote Debugging. Для того чтобы воспользоваться данным решением вам необходимо работать с версией Android 4.0 и выше (мобильная версия Google Chrome доступна только для сэндвича).

Настройте тестовую среду, выполнив следующие шаги:
1. Убедитесь, что у вас установлены: Android SDK и Chrome; ваше мобильное устройство настроено для разработки.

2. Подключите мобильное устройство к компьютеру по USB кабелю. Для коммуникации с устройством нам нужен Android Debug Bridge (adb), который включен в Platform Tools (Android SDK).

3. Для удобства добавьте Platform Tools (<sdk>/platform-tools/) к переменной окружения PATH.

4. В командной строке запустите команду adb devices. После запуска команды убедитесь, что ваше устройство появилось в отображенном списке. Если нет - убедитесь, что на вашем телефоне разрешена USB-отладка. Список выглядит примерно так:

5. На мобильном устройстве запустите браузер Chrome. Откройте Настройки -> Инструменты разработчика и выберите галочку Включить веб-отладку через USB.

6. Запустите в консоли следующую команду для того, чтобы активировать передачу через порт:

adb forward tcp:9222 localabstract:chrome_devtools_remote 

7. Откройте Google Chrome браузер и загрузите страницу: localhost:9222

8. Вы увидите набор эскизов страниц, которые открыты в вашем мобильном браузере в данный момент. Выберите страницу, которую вы собираетесь отлаживать. Вот пример того, что вы должны увидеть в браузере:

  
9.  Теперь вы можете начать отладку мобильного контента на своем рабочем компьютере в Developer Tools. Вы можете измерить время загрузки каждого элемента веб-страницы:

Остается только обратить ваше внимание на то, что при проведении измерений нужно учитывать кеширование страницы. Чтобы полностью исключить кеширование советую:
    - Проводить отладку в инкогнито режиме мобильного браузера;
    - Выключить кеширование в Developer Tools (шестеренка в правом нижнем углу):

Ну вот и все, удачной охоты на багов! :)