SQA Days 2012 как это было

Вот и пришло время рассказать о конференции, на которой я недавно побывал.
Поводом поехать на неё стало то, что в прошлом году вместо неё поехал на Microsoft QA Day 2011 и пропустил SQA Days 2011, но пообещал себе "в следующем году" обязательно съездить.

Перелёт Саратов-Москва-Минск. Всё отлично, Минск шикарен.
Широкие улицы, дорожки для велосипедистов, всё как у людей.
Миллион в кармане ;) - там ведь цены другие.

Хожу по ночному городу ищу где бы поесть. А всё закрыто. Это вам не Москва и не Саратов.
Там редкое заведение работает до 12ти, а большинство в 8 уже закрываются.

Библиотека. По рассказам это должно было быть что-то нереально огромное и крутое) обычное здание.

Регистрация, доклады...

Интересно, да, но аудитория еще не проснулась, не растормашилась, доклады все большей частью о том что уже набило оскомину, что прописано в книгах и вообще.

Фраза первого дня SQA Days 2012: за рабочий день лучше удалить несколько строчек кода, чем написать несколько строчек кода. Эта фраза выглядит очень интересно и имеет мало смысла, если только не является частью культуры разработки. Я определённо над ней ещё буду думать.

Встретил свою знакомую, с которой раньше работали за соседними столами ).
Конечно, некоторые доклады были хороши, сейчас достану листочек и пройдусь по самым лучшим:
Сервисы на базе автоматизации тестирования. Мне понравился этот доклад по тому, что мы у себя делали что-то похожее когда-то.
Ну и ребята из Яндекса, они вообще вносили некоторую нотку позитива в конференцию, в их докладах были профессионализм, легкость, уверенность, подготовленность. И слайды в стиле Яндекса, что меня позабавило. И конечно же тема, о которой они рассказывали, мне очень интересна, но больше меня всё же зацепил Яндекс-доклад второго дня, потому что он был более практическим.

... вечерний Минск, душ, еда, интернет ...
после того как расслабишься и побродив по городу даешь своим мыслям свободу выражаться, после таких вот конференций сразу же возникает желание что-то делать. Строишь планы, думаешь, какие надо проявить инициативы на своих проектах, кому какие дать задания, о чем поговорить и рассказать. Это здорово. Это отлично. Как будто до этого твои мысли и желания только и ждали чтобы их кто-то спугнул и вот они расправили крылья и разом взмыли в воздух.

день второй)

Второй день был наполнен ожиданиями чуда ещё с утра, доклад Алексея Баранцева был отмечен красным кружком в плане посещения, так же конечно же доклад сотрудника Яндекса и все доклады по автоматизации, т.к. было решено во второй день ходить только на практические доклады.
Собственно, ценными докладами второго дня можно назвать доклады про HTML Elements и про вектор развития Selenium.
Эти два доклада вселили в меня оптимизм и зарядили именно теми мыслями, которых я ждал от конференции. Закрепив в себе желание изучать Selenium с строить автоматизацию на его основе, я, чувствуя в себе силы свернуть горы, поехал в аэропорт.

Предстояло ночь провести в аэропорту, что я и сделал, сев с ноутбуком рядом с розеткой и кофейным автоматом. Отлично попрограммировал несколько часов. Полностью переделал автотесты на своём проекте, да так хорошо, что до сих пор в восторге) Теперь у меня на каждый тест кейс из тест плана есть тест кейс в excel, записанный в виде user-story, который скармливается фреймворком и поехали...

Потом еще день в Домодедово в ожидании того, что снеговые тучи рассеются.... самолёт.... и я дома.

Прошло уже почти две недели...
Сегодня сообщение в скайп:
Тимур, больше никогда не отдавай мне свой купон на бесплатное пиво, мы пропустили наш поезд...

конференция удалась )

Selenium - подборка материалов с комментариями

Конечно, первая ссылка - проект Алексея Баранцева:
http://www.software-testing.ru
Кстати, у него был отличный доклад по селениуму на конференции SQA Days 2012.

Так же стоит обратить внимание на бесплатные тренинги Михаила Поляруша:
http://www.youtube.com/watch?feature=player_embedded&v=IPraAY78jGY

Внимания так же заслуживают материалы с конференций, посвященных Selenium:

http://seleniumcamp.com/archive/selenium-camp-2011/materials/
http://seleniumcamp.com/archive/selenium-camp-2012/materials/

Сайт самого проекта Selenium:
http://seleniumhq.org

Сайт конференции Selenium Camp 2013:
http://seleniumcamp.com

Автоматизируем виртуальные машины на Python. Музей граблей.

Статья посвящается нескольким дням моего упорного труда над автоматизацией работы с виртуальными машинами. Краткий обзор граблей и подводных камней, полезных ссылок и пространственных размышлений, примеры исходных кодов.

Начал я с того что установил Virtual Box и пробовл рабораться с  vboxapi. Потратил день. Результат: смог создавать виртуальную машину без жесткого диска, как прикрутить жёстский диск так и осталось тайной за семью печатями. Более того, при попытке отправлять нажатия клавиш на VNC консоль виртуальной машины, отправлялся только символ '=' - при этом бесконечно. Собственно, залогиниться так и не удалось.

 Потом я вычитал про libvirt. Из плюсов: она поддерживает различные гипервизоры, такие как KVM, Xen, Virtual Box и другие (см википедию). Оказалось, вполне дружелюбная библиотечка, но и тут не всё гладко: нужно создавать XML конфигурацию виртуальной машины и сети, а для работы с vnc консолью приходится использовать subprocess, вызывая команды 'virsh ...'.
Но с перечисленными недостатками можно смириться, учитывая, что всё остальное просто прекрасно. В процессе моих поисков толкового документа по libvirt мне попался блог (который я и до этого читал, но о другом):
http://koder-ua.blogspot.com/2011/12/libvirt-co-1.html
где очень доходчиво описано "как начать работу с библиотекой". Собственно, это дало мне хорошую возможность начать, после чего я написал свой класс, который умеет создавать и настраивать виртуальную машину, т.е. можно его использовать для полной автоматизации работы со всеми виртуальными машинами.

Код класса, который обеспечит удобную работу с консолью виртуальной машины:

import re, time, pexpect


class kvm_cmd:
    def __init__(self, vm_name):
        self.cmd = None
        self.i = 0
        while self.cmd == None:
            try:
                self.cmd = pexpect.spawn('virsh console ' \
                                            + str(vm_name))
            except:
                pass

    def flush(self, c='.*'):
        for i in range(3):
            try:
                self.cmd.expect(['.*', pexpect.EOF], timeout = 30)
            except:
                pass
            time.sleep(10)

        try:
            self.cmd.expect([c, pexpect.EOF], timeout = 120)
        except:

            pass

    def wait(self, s):
        if s != '':
            try:
                self.cmd.expect('.*' + s + '.*', timeout = 30)
                self.i = 0
            except:
                self.i += 1
                if self.i < 20:
                    self.wait(s)

    def wait_and_accept(self, s):
        try:
            self.wait(s)
        except:
            pass
        self.run('')

    def run(self, s, c=''):
        self.i = 0
        try:
            self.cmd.sendline(s)
        except:
            pass
        self.wait(c)

 Используя этот класс с виртуальными машинами работать просто и весело, например, вот так

console = kvm_cmd('Host1')
console.wait('login')
console.run('user')
console.wait('password')
console.run('secret')

Но иногда одного консольного интерфейса не достаточно, например, если мы не линукс без графической оболочки поднимаем, а свое приложение с графическим интерфейсом, которое надо устанавливать и запускать в системе с графической оболочкой. Здесь одной консолью не обойтись. Что мы можем сделать:
1. Подключаться к X серверу по ssh и таки запускать приложение на своей машине, после чего уже его тестировать.
2. VNC console. Старый проверенный, хотя и не сказать что дедовский ;) способ. К тому же, есть отличная готовая тулза для linux - vncdotool, которую смело можно использовать для таких целей. Умеет тыкать мышкой и посылать нажатия клавиш, делать скриншоты и сверять картинку на экране со скриншотами. Ну или Sikuli, тоже отличный выбор.
3. Какой-то другой, революционный способ, который предложите именно вы.

Эмуляция сетей: dynamips & dynagen & Cisco GNS.

    За неимением реальных дорогостоящих и шумных железок Cisco, мы можем использовать эмулятор, для того чтобы протестировать некоторые функции реальных устройств.
    Ценность подобного программного продукта очень велика, особенно, когда тестовое окружение должно включать в себя множество различных роутеров, и топология сети постоянно изменяется. При этом эмулятор позволяет получать далеко не все функции реальных устройств, съедает много памяти и процессора (образы Cisco IOS загружаются прямо в оперативную память вашей машины). Но оно того стоит, в некоторых случаях.

    При этом вы получаете самые настоящие устройства cisco из коробки - у них есть консоль, сетевые интерфейсы и все по-взрослому - траффик ходит, как полагается. Конфигурацию устройств можно настраивать и сохранять так же как и на реальных железках.

    Но какие есть плюсы для тестировщиков кроме самых очевидных?
Это можно автоматизировать! На Python! ) (dynagen написан на питоне и вы можете непосредственно изменять его, редактируя текстовым редактором файл /urs/bin/dynagen ;) ну или на bash, кому что)
Полезное примечание: мы можем создавать конфигурацию оборудования и топологии сети в графическом редакторе Cisco GNS, сохраняя всю сеть в файл конфигурации, а потом в процессе тестирования подгружать различные конфигурации и получать по запросу различные топологии с уже настроенными устройствами. Этим данная технология вызывает у меня восторг ).

    Смотрим для начала:
1. http://unixadmins.su/index.php?topic=122.0

2. http://adminofsystem.net/2010/08/%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B5%D0%BC-%D0%BB%D0%B0%D0%B1%D0%BE%D1%80%D0%B0%D1%82%D0%BE%D1%80%D0%B8%D1%8E-cisco-%D1%81-%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5%D0%BC-dynamips/

3. http://7200emu.hacki.at/

4. http://unixadmins.su/index.php/topic,905.0.html

Используя эту технологию, мы можем создавать сложные сети, включающие виртуальные машины и роутеры Cisco. При этом роутеры cisco могут взаимодействовать с виртуальными машинами, если создать необходимые бриджи и виртуальные интерфейсы в системе.
Примечание: Для того, чтобы dynamips не съедал весь процессор, нужно использовать значения idlepc для каждого эмулируемого роутера.

Для связи с виртуальными машинами на KVM мы используем виртуальные интерфейсы tap, которые подключаются к бриджам, с которыми, в свою очередь, связаны сетевые интерфейсы виртуальных машин. 

sudo tunctl -t tap1
sudo ifconfig tap1 up
sudo brctl addif virt_br2 tap1

Используются утилы командной строки linux, возможно, вам необходимо их будет доустановить в систему, чтобы всё работало.

import time
from subprocess import Popen, PIPE
 

conf  = '/home/user/configuration_of_cisco_routers.conf'

Popen('killall dynamips', shell=True, stdout=PIPE, stderr=PIPE)

time.sleep(2)

Popen('dynamips -H 7200', shell=True, stdout=PIPE, stderr=PIPE)

time.sleep(5)

Popen('dynagen ' + conf, shell=True, stderr=PIPE, stdout=PIPE)

time.sleep(60)

Этот скрипт перезапускает dynamips и dynagen. (чтобы всё это работало, надо применить хак: sudo vi /usr/bin/dynagen  - строка 1521 - закомментировать несколько строчек кода, чтобы при загрузке конфигурации dynagen не запрашивал подтверждения) Можно и без этого, но тогда придётся через pexpect - кому как нравится.

Далее делаем конфигурацию dynagen:

autostart = True
[localhost:7200]
    workingdir = /tmp
    [[7200]]
        image = /home/user/CiscoIOS/cisco.bin
        ghostios = True
        sparsemem = True
        idlepc = 0x60507884
    [[ETHSW sw1]]
        1 = access 10 NIO_tap:tap1
        2 = access 10
        4 = access 20 NIO_tap:tap2
        5 = access 20
    [[ROUTER R1]]
        console = 2000
        f0/0 = sw1 2
        f0/1 = sw1 5
        model = 7200

вот и всё, теперь осталось только настроить cisco роутеры и сохранить конфигурацию.

есть возможность совершенно бесплатно и без особых усилий развернуть тестовую площадку из десятков Cisco роутеров с различными конфигурациями, различными версиями IOS и более того, подключить их к интерфейсам виртуальных машин.

у всего этого есть графический интерфейс, в котором можно "нарисовать сеть", мониторить состояние узлов, снимать трафик для анализа пакетов и многое другое - Cisco GNS. Есть под винду, линукс и мак.

Другой взгляд

Столько написано, рассказано и показано про вампиров, все знают об этих легендах, сказках и мифах.

И лишь немногим пришла в голову мысль о том, что легенду о кровавых и страшных существах, монстрах, можно превратить в повесть о вечной любви двух бессмертных существ.

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

Поклон в сторону тех, кому это удалось. Поклон в их сторону в честь того, что их внутренний голос оказался громче криков толпы.

Это действительно сложно - придумать то, что еще не существует и лишь сможет существовать когда-то в будущем, если тебе удастся выразить своё ощущение того, чего не хватает в этом мире.

Ура

Вот и прошли две свежие конфетки, впереди еще одна.

И моё имя есть в списке:
http://software-testing.ru/component/content/article/37-yvcomments/1749---auto-confetaqa

я прямо счастлив )

Тестируем API на Python.

Для тестирования API сервиса раньше на проекте использовался Soup UI (а до него ещё одна программа, но лучше о ней не вспоминать)

SoupUI, конечно, хорошо.
Но:
1. Бесплатная версия заставляет делать множество лишних движений (например, нельзя скопировать и вставить несколько повторяющихся действий из теста в тест или получить список всех входящих и выходящих параметров для вызываемых функций, когда передаём значение от одной к другой)
2. Результат приходится проверять вручную, т.к. даже если тест 'passed' - вполне вероятно, что было возвращено какое-нибудь исключение, которое программа посчитала за корректный ответ.
3. Как показывать отчёт? Сколько тестов и на какие функции было запущено? Сколько из них пройдено и не пройдено?

Если коротко: в такой автоматизации слишком много приходится делать руками.
Поэтому, встречайте: Python !

Что он даёт:
1. Удобная библиотека работы с API позволяет в одну строчку вызывать любую функцию, получать ответ и адекватно его проверять (я использовал suds, но есть и другие, можно здесь найти: ссылка на stackoverflow )
2. Возможность генерировать отчёт в HTML (например http://tungwaiyip.info/software/HTMLTestRunner.html )
3. Полная автоматизация: запустил скрипт, через пол часа пришёл и забрал готовый отчёт.

Недостатка два:
1. Для работы с такими тестами (например, чтобы понять почему какой-нибудь тест упал) вам нужен человек, знающий Python (но вам достаточно одного человека).
2. Большой объем Python кода. если у вас, скажем, 30 функций, у каждой функции в среднем по 3 параметра, то с учётом проверки возможных классов эквивалентности (в идеале мы хотим протестировать как можно больше) получаем 4 * 3 * 30 тестов, каждый в строчек 10-20. Итого: 3600+ строк Python кода. Поэтому важно обзавестись хорошим редактором, который позволяет, например, сворачивать текст отдельных функций, а так же удобно подсвечивает питон код.


Пример того как генерировать HTML отчёт: ещё одна ссылка на stackoverflow

Selenium. Start.

Начало работы с Selenium.

Давно мечтал начать работать с этим фрэймворком для автоматизации тестирования веб приложений.

Чтобы начать:
1. Смотрим видео файл
    Спасибо авторам этого видео. Бесплатно выложенный видео-урок для того чтобы начать. Отлично, то, что нужно. Дальше - уже сами.
    Подробно расскажут как поставить selenium и python/java к нему. Научимся делать простые тесты, поговорим о полезной утиле Mind - теперь я знаю как делать красивые, эффектные презентации.

2. Ещё: cтатья в блоге о бесплатных лекциях по selenium

3. Установка в Linux Ubuntu была проста:
sudo apt-get install python-pip
pip install selenium
и далее работаем с любимым браузером.

В Windows надо будет как всегда допиливать:
 - скачиваем питон: http://www.python.org/download/
 - скачиваем setup tools: http://pypi.python.org/pypi/setuptools#Credits
 - прописываем ручками пути в переменную окружения Path к папке с питоном и папке с easy_install:  C:/python27/   & C:/python27/Scripts/
 - устанавливаем pip:  easy_install pip   (не забываем каждый раз закрывать окно консоли и открывать заново, чтобы виндовс увидел сделанные ранее изменения)
 - устанавливаем селениум:  pip install selenium

да, на експлорер надо скачать дополнительный компонент, версия которого зависит от битности операционной системы:
http://code.google.com/p/selenium/downloads/list
и да, необходимо запускать IE-сервер для корректной работы драйвера и прописать путь к нему в переменной окружения.

4. Покатили:
    from selenium import webdriver
    browser = webdriver.Firefox()
    browser.get("http://google.com")
    ...

   Welcome to Selenium )

дополнительно, по вопросам о локаторах:
http://selenium2.ru/docs/webdriver.html
http://autotestgroup.com/ru/blog/85.html
https://addons.mozilla.org/en-US/firefox/addon/xpath-checker/

Всё оказалось не так здорово, как виделось при прочтении множества статей о возможностях селениума в качестве фрэймворка для автоматизации. Идентификация простейшего объекта, который QTP распознаёт на раз, для selenium оказалась невыполнимой, даже с несколькими вариантами xpath. Оказывается, когда страница состоит из нескольких фреймов и встроенных страниц со структурой "таблица в таблице", xpath не так уж и силён. Selenium IDE видит объект, а Selenium Web Driver - нет. Читаю про локаторы, проникаюсь дао автоматизации.

вкусности:
http://automated-testing.info/forum/razbiraemsya-v-zapuske-testov-v-jenkins-maven-testng-webdriver-na-java

Soup UI free и все все все

Автоматизированное  тестирование. Тестирование API. Soup UI.

Собираюсь начать цикл статей по тестированию веб приложений и сервисов с помощью различных программных инструментов.

Soup UI - программа для функционального / регрессионного / нагрузочного тестирования, а так же для тестирования безопасности. Строго говоря вряд ли качество тестирования безопасности при помощи этого инструмента находится на достаточном уровне, но безопасность - дело тонкое, и, на мой взгляд, в этом деле лучше ничем не пренебрегать. В том числе - необходимо использовать максимум доступного (тем более есть бесплатная версия) программного обеспечения для автоматического сканирования и обнаружения известных типов уязвимостей, вдруг да что-нибудь обнаружится.

Небольшое отступление от темы в сторону моих первых впечатлений от использования данного инструмента:
1. Слишком много действий необходимо предпринять чтобы что-то сделать. Интерфейс состоит из маленьких кнопочек, не интуитивен, любое действие требует чаще всего нескольких движений, щелчков и заполнения нескольких полей в бесконечных формочках.
2. Не смотря на пункт 1, в самостоятельном освоении он достаточно прост, есть неплохая документация на просторах сети как на английском, так и на русском языках. После того как разобрались - основное неудобство - пункт 1.
3. Мне не хватает красивых отчётов с результатами тестов, таких, какие хочется показать руководству. Может, я до этих отчётов ещё не добрался?
Они могут быть очень полезны, когда надо продемонстрировать преимущество используемого инструмента перед продуктами конкурентов или внедрить новый вид автоматизированного тестирования (имею ввиду подвиды автоматизированного тестирования, например, нагрузочное или тестирование безопасности) на проекте.


Тема сегодняшнего дня - Soup UI в тестировании REST API.
Тестируемое устройство: Cisco ANM 6.1
Версия программы Soup UI 4.5.1 free.
Сайт: www.soapui.org

Раньше использовали SOAtests 9.0. Жуткая штука - тормозная и достаточно сложная. При разрастании тест кейсов больше чем на 25 мегабайт - будьте добры создать новый проект, иначе всё начинает тормозить, появляются артефакты. В атоматизированном тестировании они ни к чему.
Ко всему этому ещё скажем о проблемах с лицензией, которая располагается на сервере лицензий и настройки постоянно сбиваются. Всё это не лучшим образом сказывалось на скорости и качестве проведения тестирования. И вот однажды мы подсмотрели как этот же функционал тестируют его разработчики... бесплатным плагином Soup UI для Eclipse!

Создаём новый проект, щёлкаем на имени проекта правой кнопкой мыши и выбираем "добавить схему WSDL".
Выбираем заранее сохранённый файл с WSDL схемой.
Создаём New Test Suite
Это сьют, в который мы будем складывать все тест-кейсы.
Щелкаем правой кнопкой по сьюту, выбираем New Test Case, задаём имя нового тест кейса.

Теперь у нас есть Test Case 1, принадлежащий Test Suite 1.
Щелкаем два раза левой кнопкой по тест кейсу, открывается список его шагов, он сначала пуст.
Щелкаем правой кнопкой мыши в списке шагов тест кейса, выбираем Append Step > Test Request.

Задаём имя, в нашем случае это Login, выбираем соответствующее данному шагу действие из загруженного списка возможных функций.
То же самое делаем для функции Logout - теперь есть два шага - Login и Logout.






Вопрос, который меня мучил несколько дней - как в бесплатной версии Soup UI передавать параметр Sesion ID от Login к Logout.
Рассмотрим структуру ответа Login и запроса Logout:

Ответ на запрос Login:

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
  <ns2:loginResponse xmlns:ns2="http://anm.cisco.com">
    <SessionToken>
      <sid>-2124210123754741170</sid>
    </SessionToken>
  </ns2:loginResponse>
</S:Body>
</S:Envelope>

Запрос на Logout:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:anm="http://anm.cisco.com">
<soapenv:Header/>
<soapenv:Body>
  <anm:logout>
    <sessionToken>
      <sid>?</sid>
    </sessionToken>
  </anm:logout>
</soapenv:Body>
</soapenv:Envelope>

Хочется не копировать каждый раз параметр sid из ответа одной функции в запрос другой, хочется чтобы значение передавалось автоматически - и мы сразу видели результат работы всей цепочки шагов.
Оказалось всё просто. Между двумя шагами тест кейса надо вставить экшен Property Transfer.

В Property Transfer создаём новый элемент, SessionID.
Указываем следующие свойства:

Source: login     Property: Response

В текстовом поле пишем:
//SessionToken/sid

Target: logout   Property: Request

В текстовом поле пишем:
//sessionToken/sid

Готово, запускаем - работает.

 Выход найден:
1. Soup UI бесплатен, не надо мучиться с сервером лицензий и запускать его где-то на виртуалке, можно запускать прямо на свое машине.
2. Soup UI работает быстро, без артефактов.
3. Soup UI помогает делать то же самое и даже больше. Правда, разобраться в нём тоже не просто, подвох тут в том, что большая часть документации охватывает... платную версию, в которой, конечно, есть специальные удобные штуки для того чтобы не ломать голову как же добраться до свойств функций и другие вещи.

Вдохновение

Есть такие видео, которые заставляют нас задумываться о том, что мы делаем.

(С) Видео файл позаимствован с сайта pyvideo.org

Тут рассказ о том как классные ребята делают классный софт. Есть чему поучиться.

Уменьшение количество кода и улучшение его качества, читаемости, логичности, точности - это отлично. Это здорово. Как будто и не может быть лучше.

Есть отличная идея про разработку программного обеспечения будущего.
Разработка в таком стиле, чтобы все баги бросались в глаза и были уникальными.
Идея в том, что при этих условиях их легче заметить.
Если он виден, если он буквально размахивает красным флагом с надписью "БАГ" - тут-то его и поймают.
Вопрос в том каковы принципы написания кода, который выводит все баги на чистую воду.
Паттерны отлично тестируемых приложений. Идеальный цикл разработки с исправлением багов до их внесения. Надо будет подумать об этом чуть дольше.

Идея как раз в том, чтобы не плодить новые проблемы, решая имеющиеся проблемы. Чтобы ставить цель и достигать её кратчайшим путём. И делать программы так просто, как это только возможно. Легко. Качественно.

DevCon 2012 online

DevCon 2012. Online трансляция.
2 дня отличных мыслей, отличного настроения. Полный мотивацией видеоряд.

Плюсы:
их куча - выступление реально классных людей о реально классных вещах. Жаль, многие интересные доклады пропустил, надеюсь, у меня будет возможность посмотреть запись чуть позже.
Много мыслей, новых классных, воодушевляющих на что-то великое. Так и хочется сразу сесть и сделать всё хорошо на своем проекте.
Microsoft TFS вновь радует (не смотря на постоянное её упоминание, даже не приедается, интересно - т.к. множество разных классных штук туда напихали)
ну и конечно же классные обзоры возможностей Visual Studio 2011, которой я сейчас активно пользуюсь и очень этому рад - очень классно сделанный софт.

И чуть было не забыл рассказать про первый доклад на конференции, которым эта конференция была открыта - Сессия вопросов и ответов со Скоттом Хансельманом
Интересный человек который делает большую работу.

Минусы:
Онлайн трансляция постоянно подвисала, выключался то звук то изображение. Да и ощущения не те, когда постоянно на что-то отвлекаешься. На реальной конференции все намного круче, лучше проникаешься атмосферой, а это важно.

Выводы:
1. Стоит посетить.
2. Надо ехать "вживую".

жду записей всех докладов, обещали выложить на сайте - будет здорово посмотреть )
кстати сайт конференции: http://www.msdevcon.ru/online

Microsoft QA Day 2012

Москва. Microsoft QA Day 2012.
Я посетил это мероприятие, после чего решил дать своим мыслям немного упорядочиться, перед тем как записывать их в блог.

... Москва встретила меня снегом с дождём, время на часах 5:30 утра, начало конференции в 9:00.
Метро, поиски центра "Инфопространство", о котором, похоже, не знает ни один москвич.
Но я его всё же нашёл.

Регистрация, большой зал со столами и кофе. Дали бэйджик, рекламные листовки и гарнитуру для того, чтобы можно было слушать синхронный перевод.
Стоим, пьём кофе, разглядываем народ, слушаем случайные разговоры. Пытаемся понять как крепится гарнитура.

10:00. Начало выступления Рэкса Блэка.
Большой человек. В прямом смысле этого слова. Выше всех нас )
Рассказывал про баги, про то, как они переходят от этапа к этапу при разработке программного обеспечения. О стоимости ликвидации багов на этапе планирования и разработки. И о том, сколько может стоить баг в продукте, который был отдан пользователю.
От синхронного перевода пришлось отказаться, с первых минут наслушался про "дикие баги" в продукте, которые на самом деле являются всего лишь необнаруженными деффектами в программном обеспечении.
Выступление всем понравилось. Действительно, поговорили об интересном.

Далее доклады пошли один за другим, выступали ребята из Microsoft, показывали, что умеет их тулза Team Foundation Service - действительно очень впечатляющая вещь. Для команд, которые разрабатывают программное обеспечение в Visual Studio это действительно круто. Позволяет разрабатывать автоматические тесты на основе исходного кода, анализирует покрытие, сопоставляет тест кейсы с требованиями и исходным кодом, создаёт на основе этого отчёты. Так же создаёт отчеты на основе результатов прохождения автоматизированных тестов и блокирует возможность закоммитить код, который не прошёл автоматизированные тесты. Что ещё нужно для счастья? )
А, точно - ещё и позволяет определять изменения в коде с момента запуска предыдущих тестов и запускать регрессионные тесты только для того функционала, который был "задет" внесёнными в код изменениями. В общем это действительно качественный переход к другому процессу разработки и тестирования. Хочу попробовать поучаствовать в таком процессе, результаты и процесс интересны до жути )

Выступал Дмитрий Питунин из Intel с очень интересным докладом о том, как можно оптимизировать QA процессы. О том что надо автоматизировать всё что можно, а то что не автоматизировано выполнять пореже. И опять же - QA - должны давать информацию о продукте. Красивые отчёты, анализ, диаграммы. Тогда от тестирования будет толк.
В общем тоже очень полезный доклад. Бонусы: идея ботов, которые гоняют самосгенерённые тесты.

Потом доклад Максима из Parallels. Про то, как стартап вылез на бэта-тестировании. И о том какая это непростая задача - поддерживать бетта-тестирование продукта, особенно, открытое бетта-тестирование. Рассказал чему они научились, к чему пришли и чего получается добиться. Довольно интересно получилось. И поучительно. Полезный доклад, тоже к нам в копилку.

И доклад сотрудника IBM. Он рассказывал про решение компании IBM, которое используется для обеспечения качества в крупных компаниях. Впечатляющий набор программных продуктов, которые действительно позволяют работать на другом уровне.
Но по сути, все компании имеют нечто подобное, возможно, менее удобное и менее функциональное, но - так или иначе нужное на каждом проекте.
Их программа позволяет работать с требованиями, тест кейсами и спецификациями в одном окне. Каждый элемент имеет ссылки на родителя, таким образом можно быстро понять что к чему относится и найти необходимую информацию. Удобно.
Программа так же создает простые отчёты и может создавать сложные отчёты, если подключить сторонние дополнения.

... После докладов: розыгрыш MSDN подписок и ноутбука Samsung, сессия вопросов к докладчикам.
Гуляем по вечерней Москве с трофейным рюкзаком, едем обратно в поезде почитывая две трофейные книжки )

Поездка удалась. Появились новые тестерские силы, новые мысли, новые идеи. Конференции, оказывается, очень полезная вещь.

Баги долгожители

Сегодня собираюсь написать о багах-долгожителях, о замыленном взляде, о долгом процессе тестирования...
О насущных проблемах, на которые есть пару способов управы, да всё нет времени взяться за них обеими руками.

Вещь 1 - он же парадокс пестицида. То, что набило уже оскомину в мозгу тестировщиков.
Начнём с того, что мне это название не нравится. Слишком оно шаблонное. Читаешь его и мозг сразу переключается в режим белого шума.
Морковка!
И вот теперь, переключившись на шифрованный канал, продолжим. Есть наборы тестов, которые автоматизированы. Часть проходит успешно, другая сообщает о проблемах. Чаще всего - других примеров на моей практике не было - отваливаются сами тест-кейсы, т.е. в большинстве случаев - Bad статус тест-кейса в автоматизации означает баг в тест-кейсе, а не в продукте.
Интересно, но факт - ручной тест кейс тоже может содержать баг. Вот именно об этом данная статья.

Баги в ручных тест кейсах, тех самых, что приходится делать ручками, я выделю пока следующие
1) устаревание тест-кейса. Выполнение одного и того же тест кейса много-много раз приводит к тому, что он выполняется не добросовестно - такова особенность мозга. Тестирование - интеллектуальный труд. И его эффективность сильно зависит от внимательности. И сильно зависит от интереса к объекту, на котором вы сосредотачиваете внимание.
Так вот. Чем больше раз вы делаете одно и то же, тем неинтереснее это для вас. И тем больше вероятность пропуска дефекта. Или, например, вы решите это вовсе не делать, т.к. раньше всё вроде работало.
2) Слишком общее и не подробное описание тест-кейса. Заставляет наш мозг придумать и додумать возможные мысли самостоятельно. Это влечёт за собой всегда некоторую ограниченность - нам приходит в голову только определённая часть идей из возможных и что самое опасное здесь - продумывая возможные варианты в голове, мы заранее сильно сокращаем их количество, чтобы удержать в памяти все шаги друг за другом, т.к. действовать можем, получая лишь конкретные команды из головы. А это означает, что если в тест-кейсе тест-дизайнер написал "проверить работу функции для различных пользователей" - она не будет проверена полностью и для всех возможных пользователей.
3) Не понятное описание тест кейса или описание, содержащие неточности и ошибки. Опять вспомним наш дорогой мозг, который всё это и делает с нами и нашим продуктом. Мозг, встречая ошибку в описании того, что надо делать, сразу стартует тормозящие процессы внутри себя. И мы либо часть тест кейса не делаем, либо делаем эту часть как-то иначе, на своё усмотрение.

Результат всего этого - долго живущие баги, бывает, что они живут от начала разработки и до релиза готового продукта.
Результат этого - понижение интереса и самостоятельности членов команды контроля качества. Снижение их желания сделать продукт лучше.

Апельсин дольками.
Режьте пополам!
Так, вот, о чём мы. Лечится всё это легко. Тест-кейсы разрабатывает вся команда. Каждый выполняет тест-кейсы только те, которые не писал сам. при выполнении ты должен изменить тест-кейс - что-то добавить, исправить или удалить. Это надо сделать таким же обязательным пунктом, как предоставление результатов для каждого тест-кейса. Временно увеличивать количество тест кейсов на одну из функций приложения. Увеличить в несколько раз, провести тестирование, после нахождения всех возможных багов сократить количество тест кейсов до первоначального, основываясь на анализе найденных багов. Потом то же самое для другой функции. И по кругу.
И ещё одно правило, которое, к сожалению, тоже приходится писать - сообщать о всех выявленных дефектах/недочётах, которые были обнаружены в ходе проведения тест-кейса или в ходе ручного тестирования.

И да, ещё. Многим такая схема может прийтись не по вкусу. Что значит постоянно менять описание тест-кейса? Это значит постоянно отвлекаться. Терять много времени. И вообще "заниматься не тем". Это всё из отговорок, но они по-своему весомые.
Вообще говоря, не обязательно к паровозу прикручивать крылья. Такой режим работы можно задавать одному из членов группы и каждый раз менять "Избранного". Можно даже это обыгрывать переходящим Знаком Отличия. Кепка великого Исправителя тест-кейсов или кружка главного-тест-аналитика.
И да упасут те высшие силы в которые вы верите вас кого-то заставлять. На эту должность вам нужен человек с очень хорошим вниманием и памятью, с горящими глазами. Заставив править тест кейсы кого-то через силу, хорошего ожидать не приходится.

Ну и в конце-концов. Если вы вдруг не тим-лид - а большинство тестировщиков и QA именно из этой группы (как ни странно )) ) - и вы не особо можете командовать и менять порядки в группе - вы можете постоянно, даже не афишируя особо - брать эту роль на себя. Не забудьте только руководство уведомить о том, что собираетесь "лезть в тест кейсы" с исправлениями и дополнениями. А то мало ли.

И помните про пушистых кроликов. Они любят морковку и не любят порезанный дольками апельсин. И очень хорошо держат на себе внимание и активируют воображение. Примерно на 5-10 минут.

Верификация чужих багов - или не рой яму ближнему своему

Вот такая ситуация, я думаю, не редкость и на других больших проектах:
- есть куча тестировщиков, работающих в разных часовых поясах и не знакомых друг с другом лично.
- есть общая баг-трекинг система с описанием багов. Все могут заводить баги и менять их статусы.

И вот ты сидишь и читаешь "шаги воспроизведения" к чужому багу:
иногда фича №4405 работает не очень хорошо.....
И комментарии программиста, который это исправил:
было исправлено в версии 1.3.4.55554 от 02.03.2004.

Вот и верифицируй. Подтверди, что исправлен баг. Даже если отлично знаешь продукт, если этот баг нашёл не ты, то подтвердить исправление бага, который проявляется "иногда" в определённой фиче... При этом доступ к фиче есть как минимум по двум-трём юзер-стори...
Господа, да, я, конечно, разберусь. Настрою девайс с версией, где этот баг ещё жив, потом настрою второй девайс с новой версией без бага. И пойду искать отличия, примеряя эти отличия к той информации, что дана другим тестировщиком и программистом.
Потрачу день на верификацию одного бага, но разберусь и верифицирую.

Понятно, что либо для этого тестировщика такой баг был очевиден, и он решил, что его описание будет очевидно другим (и тогда программисты тоже помучились, чтобы понять в чём проблема) либо тестировщик договорился с программистом и завёл баг, описание которого будет понятно только этим двоим.
Как бы там ни было. Верифицировать третьему.

Господа тестировщики, будьте людьми. Сэкономив себе время, написав слишком короткое описание к багу и не приложив скриншоты, вы тратите время своих коллег (у которых на это уходит больше времени)

Тестировщики - где их обучают?

Во многих блогах и на многих сайтах встречал вполне серьёзные сетования по поводу того, что мол нет университета тестирования в России, что не от куда взять тестировщика с высшим образованием по специальности "тестировщик всех и вся".
Но когда я задумался о том, что могли бы рассказывать таким тестировщикам на лекциях, мне стало грустно.
Расскажут, допустим, о всех возможных методиках тестирования. Всю теорию тестирования, включая процессы разработки программного обеспечения и менеджмента. И даже для кучи будут устраивать лабораторные и практические занятия.
Да, конечно и безусловно, для того чтобы отсвечивать белыми рубашками с толстыми галстуками, такие люди могли бы пригодиться.
То, что они знают как надо делать правильно и как вообще можно сделать - это здорово. Но то, что чувствовать это и не бояться применить можно только в реальной ситуации, работая на реальном проекте - бесспорно. Да, здорово, он знает все виды тестирования и знает в какой фазе проекта каждый вид должен быть применён - но посади его тестировать, и не известно чем это закончится. Так уж устроен мир и так уж сделаны люди - от природы мы мало что умеем делать хорошо. И всему надо учиться.

Так вот о чем я.

Всему, что может знать тестировщик о тестировании, он намного более быстрее и результативнее обучается на реальных проектах. После чего покупает пару хороших книжек, читает блоги и занимается тестированием, постепенно наращивая мастерство.

Чтобы тестировать, приходится знать невероятное множество дополнительных вещей - администрирование различных видов серверов на различных операционных системах, виртуальные машины, сети, верстку, способы взлома сайтов и атаки на сетевые узлы, программирование на нескольких языках - да всего и не перечислить, а любой список будет выглядеть немного глупо.
На первый взгляд всего этого не может знать один человек достаточно хорошо. И уж точно вот так "всему подряд" не получится выучить в университете, давая теорию... и спрашивая по билетам на экзаменах.
Потому до сих пор и нет университета тестировщиков.

А есть математики и физики, специалисты по компьютерной безопасности, бывшие админы и программисты, которые занимаются тестированием программного обеспечения.