SQA Days 13. День 1

Вот и закончилась очередная конференция SQA Days, уже 13-ая. Проходила она в славном городе Санкт-Петербурге, в отеле “Прибалтийская”.

Чтобы далеко не ходить, остановилась я в том же самом отеле. Очень милое местечко, скажу я вам! Вот, например, мой номер:

Ну и первое, что сделает ИТ-шник, приехав в отель... Правильно, достанет ноутбук:

А уж какие там конференц-залы! А интернет!

Нет, правда, даже в Москве было хуже. Wi-fi работал как часы, причем во всех залах, а не так, что в секциях работает, а на стендах нет.

Да и стенды полностью изменились. Помните как они начинались? Без микрофона у телевизора, вокруг десяток пуфиков - и все! А тут – целый зал, с таким же проектором, как и во всех остальных, с кучей сидячих мест и с телевизорами посередине зала – чтобы сидящие в конце могли видеть оратора и его презентацию. В общем, полноценный доклад, просто короткий.

TEST IT! Тестируем регистрацию на Foodnation.ru

Коллеги, пинг! На связи TEST IT!

И сегодня с Вами снова я, сменная ведущая Киселева Ольга с новой рубрикой "тестируем вместе". И тестируем мы сайт https://www.foodnation.ru/, ныне http://www.foodpanda.ru/

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

• Полный список тестов по http://www.foodpanda.ru/

Ну что ж. Бегло мы все осмотрели. С чего начать? Тем более, что внешний вид сайта внезапно изменился... Но зато осталась возможность зарегистрироваться. Давайте ее и проверим.

Как в Maven быстро создать БД по шаблону?

Бывают такие ситуации, когда надо что-то протестировать на предварительно подготовленной БД, потом это все убить, снова подготовить итд итд...

Получаем такую последовательность действий:

• Создаем БД.
• Заполняем ее через внешний интерфейс.
• Выполняем свои тесты.
• Дропаем все нафик.
• Снова создаем.
• Снова заполняем ровно теми же данными, так как нам нужно проверить именно их, но в разных вариантах развития.
• Выполняем свои тесты
• ...

Правда, уныло? А, главное, долго!

Когда передо мной встала такая задача, я сначала попробовала ее обойти, написав автотест. Ну а что? Занесла один раз нужное состояние БД в эксельничек и все, доверилась машине. Все-таки, мне стало гораздо спокойнее писать один тест, чем проверять что-то вручную, надежнее оно...

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

Озвучила мысли разработчику и пошла пилить тест. Но что-то у нас с ним не сложилось... Не создавал БД, хоть ты тресни.

Разработчик посмотрел-посмотрел на мои страдания и сделал утилитку, которая заполняет БД по xls (возможны и другие форматы) без дополнительных танцев с бубнами.

Итак, ребята! Если у Вас установлен Maven, пользуйтесь (как же раздражает это дурацкое форматирование в блоге при вставке текста, но уж извините, как есть...).

1. Создаем pom.xml
2. Создаем Start.xls 

Создаем БД!

1. В разделе common configurations заполнить данные по схеме БД, которую будем заполнять

<username>test</username>

<password>test</password>

<schema>test_schema</schema>

2. В разделе specific configurations  в параметре src указать путь к файлу

<src>C:\dbunit_load\Start.xls</src>

3. Запустить утилиту! 

mvn clean package

Ну вот и все 

Настройка pom.xml

Утилита настроена на работу с oracle-драйвером.

Исходник Pom-а, меняем под свою организацию (себя):

• groupId - the id of the project's group.
• description - описание
• url - строка подключения к БД
• username - логин
• password - пароль
• schema - название схемы
• src - путь к файлу

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <groupId>group</groupId>

    <artifactId>dataset-load</artifactId>

    <version>0.0-SNAPSHOT</version>

    <packaging>pom</packaging>

    <name>Loader</name>

    <description>TADA!</description>

  <build>

    <plugins>

      <plugin>

        <groupId>org.codehaus.mojo</groupId>

        <artifactId>dbunit-maven-plugin</artifactId>

        <version>1.0-beta-3</version>

       

        <!--jar file that has the jdbc driver -->

        <dependencies>

          <dependency>

<groupId>com.oracle</groupId>

        <artifactId>ojdbc6</artifactId>

        <version>11.2.0.3</version>

          </dependency>

                        <dependency>

            <groupId>org.apache.poi</groupId>

            <artifactId>poi</artifactId>

            <version>3.2-FINAL</version>

            <exclusions>

                <exclusion>

                    <groupId>commons-logging</groupId>

                    <artifactId>commons-logging</artifactId>

                </exclusion>

                <exclusion>

                    <groupId>log4j</groupId>

                    <artifactId>log4j</artifactId>

                </exclusion>

            </exclusions>

        </dependency>

        </dependencies>

       

        <!-- common configurations -->

        <configuration>

          <driver>oracle.jdbc.OracleDriver</driver>

          <url>jdbc:oracle:thin:@server:port:sid</url>

          <username>test</username>

          <password> test </password>

             <schema>test_schema </schema>

              <format>xls</format>

              <datatypeWarning>true</datatypeWarning>

            <dataTypeFactoryName>org.dbunit.ext.oracle.Oracle10DataTypeFactory</dataTypeFactoryName>

            <skipOracleRecycleBinTables>true</skipOracleRecycleBinTables>

        </configuration>

       

        <executions>

          <execution>

            <phase>test-compile</phase>

            <goals>

              <goal>operation</goal>

            </goals>

            <!-- specific configurations -->

            <configuration>

              <type>CLEAN_INSERT</type>

              <src>C:\auto_db\Start.xls</src>

            </configuration>

          </execution>

        </executions>

      </plugin>

    </plugins>

  </build>

</project>

Фредерик Брукс. Мифический человеко-месяц.

Ссылка на OZON.

Мои выдержки из книги:

• Операционная бригада. Хирург-тестировщик.
• Если проблема в ресурсах, почему не достроили Вавилонскую башню?
• Зачем нужны формальные документы?

Фундаментальный труд. Несмотря на то, что книга вышла в свет аж в 1975 году, она до сих пор актуальна. Так как содержит советы на все времена. Спустя 20 лет, в 1995 году, вышло 2-ое издание, в котором автор добавил пару глав - о том, что изменилось за столько времени.

А в принципе, немного. Ну разве что довольно странно читать про использование перфокарт

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

Да и потом, всегда чего-то не хватает, кому-то еды, а кому-то брильянтов в ожерелье мало. Если раньше памяти было мало и старались ее экономить, то сейчас не легче, потому что запускаешь сразу и sql developer, и idea для отладки, и аж 2 jboss-а стартуешь и еще чего-то хочешь по скорости

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

Книга написана именно про сложные проекты (см мою выдержку про хирурга-тестировщика), но применима и для небольших команд, просто с некоторыми поблажками. В общем, "стыдно не знать" такое произведение!

PS - Добавила книгу в общий список прочитанных мною книг.

Зачем нужны формальные документы?

Фрагмент взят из книжки "Мифический человеко-месяц" Фредерика Брукса:

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

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

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

   Задача менеджера состоит в том, чтобы разработать план и выполнить его. Но только записанный план является точным и может быть сообщен другим. Такой план состоит из документов, описывающих: что, когда, по какой цене, где и кто. Этот маленький набор важных документов охватывает значительную часть работы менеджера. Если в самом начале понять их всеохватывающую и важную сущность, то они станут для менеджера добрым инструментом, а не раздражающей обузой. Сделав это, он определит свой курс более четко и быстро.
--------------------------------------------------------------------------------------

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

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

А ведь там бумажной работы еще больше. А для новичка так и совсем много. Он ведь еще не знает, что эффективно, а что нет. Что будет полезно, а что нет.

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

Fun ConfetQA, весна 2013. День 3

И последний... Вот только-только руки дошли написать. Итак, весенняя серия забавных fun конфеток закончилась!

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

Что же было освещено в 3 конфеточный день?

1. Катерина Несмелова / Раскрываем секреты систем управления тестами на примере Test Link.

Катерина рассказала, как пользоваться Test Link-ом, что он умеет и как там можно что-то сделать. Очень грамотный доклад с точки зрения новичка во всех этих инструментах. Хотите начать использовать Test Link для своей работы? Посмотрите доклад, там все подробно расписано, где на какую кнопочку нажимать, какой отчет открывать, какие отчеты вообще там полезные, а какие так, для общего развития. Как составить план из тест-кейсов, как их инклюдить, а не копипастить, как... И все это за 20 минут!

Думаю, если захотите внедрить такую систему, 20 минут будет не жалко потратить на доклад, который сэкономит вам время в дальнейшем!

2. Сергей Атрощенков / Коммуникационные аспекты работы тестировщиков

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

Сергей рассказывал о том, почему коммуникация важна. И еще о том, что есть некие 16 типов характеров человека, например, "политик", как сам докладчик. Зная тип характера, можно искать тот самый ключик к сердцу, путь к которому далеко не всегда проходит через желудок.

Интересная концепция. Вообще, конечно же, каждый человек по своему уникален и нет двух полностью одинаковых. Но вы только посмотрите на гороскопы, описывающие характер! Ведь и правда похоже, а все почему? Потому что гороскопы довольно общие и да, такие черты в вас вполне могут присутствовать. Тут главное - что доминирует.

А доминировать сразу все не может. Именно на то и расчет при разделении на 16 типов - на что напирать, на логику или эмоции? На сентиментальность или холодный расчет? В общем, интересный подход!

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

3. Татьяна Зинченко / SQL профайлеры: что это и с чем их едят?

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

Вот про классы эквивалентности тоже могут не знать, но так или иначе применяют. А про такое неведомое чудо могли и не слышать никогда. Таня не просто разглагольствовала, показывая слайды - она применила методику online кодинга, в ее случае, правда, не совсем кодинга, но все равно!

Открываем БД и смотрим, смотрим, как это все в реальности происходит. Очень хороший подход с точки зрения воспроизводимости = ничего не мешает после лекции взять и повторить то, что рассказывал тренер. Воспроизвести, вдохновиться и пойти к Тане на курсы просвещаться дальше :))

Вот так и закончилась весення конференция. Вместе с ней, кстати говоря, москвичи встречали весну! Если в пн многие еще по привычке ходили в теплой зимней одежде, то к среде уже все перешли на легкие курточки и пальто. Ура, да здраствует весна! Позитив, яркие краски и... интересные доклады по вечерам! Ждем следующую конфетку из той же серии, а пока - идем на форум и голосуем. голосуем! Кто же был лучшим?

Регексп-судоку

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

Источник: хабр, хабр.

Ссылка: интерактивная версия.

Ссылка: pdf, пригодный для печати.

Такое вот интересное задание на регулярные выражения (они же regexp)

Fun ConfetQA, весна 2013. День 2

А вот и второй день веселой конфетки прошел...

Что он нам принес?
 Первым должен был быть доклад про коммуникации, но увы. Таки уж мы, тестировщики. Все сломаем, что в руки дадут. GTW не желал слышать микрофон Сергея, поэтому слово передали Алексею Баранцеву, который всегда готов помочь 

Причем получилось смешно - Таня высказала дифирамбы в адрес Сергея, передала ему слово...
- Сергей?
...
- Сергей?
...
- Ну ладно, тогда его заменит Алексей Баранцев! Алексей, Вам слово!
...
- Алексей?
...
- Алексей?!

Оказалось все очень просто - Алексей Баранцев выступал в роли диджея и понадобилось какое-то время на переключение микрофона. Но выглядело очень подозрительно, словно микрофон в ГТВ работал только у Тани.

Ну ладно, поехали по докладам.

1. Алексей Баранцев / Firefox и его плагины

Отличное выступление! Кто, как не Алексей, знает, чем заинтересовать публику. Слушатели быстро побежали устанавливать FF, даже те, кто его не любит (сужу по твиттеру).

Алексей описывал различные плагины и их возможности. Очень познавательно, несколько штук захотелось опробовать. Особенно всех впечатлил плагин. позволяющий посмотреть на 3D модель своего сайта. А заодно понять, почему же на нем кнопочка роботом ну никак не нажимается? Афигенный плагин, его стоит попробовать хотя бы for fun, а, может быть, еще и проблемы в верстке найдете!

В общем, пошла я на форум, названия плагинов узнавать...

О, а еще Алексей раскрыл многим глаза - оказывается, Selenium IDE годика через 2 будет заменен, тока тс-с-с-с!

2. Александр Булкин / Системы отслеживания ошибок – почему, зачем и как?

Вторым, как и планировал, был Александр Булкин. Александр рассказывал о различных системах баг-трекинга, всячески их сравнивания.

Ну и по дороге разведя холивар, который наверняка развернется в форуме. В процессе описания, какая БТС (баг-трекинговая система) что умеет, Александр выставлял им свои оценки.

Довольно забавно было видеть тройбаны по всем пунктам, итоговую "3-" и вещание в эфире "Я очень рекомендую эту БТС" о_О

Так и хотелось увидеть БТС, достойную пятерки, но увы. Оказалось, что "4+" - это максимум.
Не, ну я все понимаю, всегда надо стремиться к совершенству и не останавливаться, но все же... Та же JIRA, я считаю, достойна 5 баллов.

И вообще, непонятно, как это так - "Ну, администрирование позволяет все, что надо, поэтому четверочка"... Хм, хм, странно это, странно это. Но вообще, доклад полезен тем. кто не знаком с системами учета багов. Ну или тем, кто хочет убедиться, что сделал правильный выбор :)

Закончился доклад весьма забавно. Александр все рассказал:
- Вопросы?
...
- Таня?
...
- Ребята?

Такие вот мы тестировщики, да

3. Анна Карпенко / Ручное тестирование мобильных приложений с нуля

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

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

Хотя, конечно, встречались вещи и из моей далекой практики, например, проверка на прозвон. Оооо, эта проверка на прозвон. Еще пока не было всяких там айпадов, андроидов и айфонов - вот тогда я и тестировала игры на мобильных телефонах. И про прозвон могу многое рассказать

Но теперь я со своими рассказами отстала о жизни, а вот про фишечки андроидов не в курсе. Была. Хороший доклад - о том, с чего начать, что прочитать и что поизучать на эту тему. Тестируете мобилки? Тогда вам сюда!

Так и закончился второй день ConfetQA, посмотрим, что принесет нам завтра!

Полиморфизм, наследование и прочее в жизни тестировщика

Сидели мы как-то, играли в Шляпу в таком коллективе - я, другая тестировщица и два разработчика. Точнее, одна разработчица, с которой мы и были в паре. А Шляпа - это такая игра, где вы сами придумываете слова, которые будут объяснять участники своей команде. Не называя однокоренных.

И вот мне разработчица и говорит так задумчиво (пытаясь придумать, как объяснить по другому):

- Ну вот в программировании наследование есть...

Я неуверенно откликаюсь:

- Полиморфизм?

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

И даже отчасти был прав, так как моя коллега объяснила его очень просто "та неведомая хрень!"

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

И я бы хотела объяснить на примере, чем важен красивый код, который не дублируется в нескольких местах. И для изменения которого надо менять одно место, а не 5, и даже не 10.

Ну раз уж пример сам просится в руки. Дело было вечером, делать было нечего... В общем, прочитав мой отчет в TEST IT про тестирование сайта https://www.foodnation.ru/, мой коллега заинтересовался и мы некоторое время его критиковали. Об этом, наверное, позже, в других выпусках, но посмотрите.

Открываем сайт, главную страницу. Все на русском. Спускаемся вниз - видим кнопки перехода на AppStore и в Google Play. Совершенно непонятно, зачем 2 совершенно идентичные кнопки рисовать совсем рядом, я об этом уже говорила.

Если это один код, еще ладно. А если тестировщик не имеет доступа к белому ящику? Это ведь дополнительная нагрузка, совершенно излишняя, кстати. Но допустим.

Поднимаемся наверх и переключаем на английский язык. Опускаемся к кнопкам и-и-и-и-и... Они по-прежнему русские!

Хм, печально, конечно, но, видимо, у них просто нет локализации для этих кнопок.

А давайте нажмем на эту призывную фразу - "Foodnation in your pocket!". Оп-па... А вот и локализованные кнопки!

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

О чем нам это говорит? О том, что где-то явно идет излишнее дублирование кода.

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

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

Ну и, конечно же, храните файлы локализации отдельно! Это, кстати, касается не только программирования. Я уверена, что автоматизаторы, читая эту заметку, сразу вспомнили о своей структуре тестов и гордо подумали, что у них то все хорошо.

Да-да, когда мы тестируем что-то через роботов, иногда приходится проверять текст. Ну вот, допустим, чтобы убедиться, что на английской странице у нас английские сообщения, а не русские. Зачем это делать вручную? Пусть работает робот! Только скажите ему, что делать.

А, чтобы сказать, надо сделать примерно похожую структуру - один тест, который проверяет надпись. И файл локализации, который говорит "для английской версии текст будет такой, а для русской - такой". Иначе, опять же, дублирование кода, сложное понимание тестов, а еще более сложная поддержка, ведь вы посмотрите, на двух экранах мы насчитали 5 (пять!!!) одинаковых кнопок. А изменится название и что, в 5 местах исправлять?

Не-е-е-ет, лучше уж вспомнить про китов ООП, Page Object Pattern и прочие премудрости

Fun ConfetQA, весна 2013. День 1

Весна, кхе-кхе... Ну ладно, допустим, что весна. А где весна, там и ConfetQA!

Начинает цикл конфеток FUN - весело и полезно, как говорится. Конференция о ручном тестировании. Для тех, кто стремится найти выгоду там, где другие видят только скучную и утомительную работу.

Итак, сегодня выступали:

1. Алексей Петров / Квартальные цели – инструмент для мотивации личного роста

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

И это здорово! Потому что действительно, цель - это мотиватор. Или хотя бы инструмент для отслеживания метрики, если вам так удобнее

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

Но, даже если я поставлю себе такую цель - "выучить Java", как я смогу определить, достигла я ее или нет? Расплывчатость угнетает. Ведь ни для кого не секрет, что, чем глубже мы начинаем что-то изучать, тем отчетливее понимаем, что ничего не понимаем.

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

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

Именно об этом и рассказывал Алексей - почему цели важны, как их ставить, с кем делить и почему их надо выполнять. Также мы в твиттере вспомнили про книжку Цельная жизнь, так ее хвалили, похоже, что надо перечитать  А то уже забыла половину... Хотя, хорошо, что записала свои мысли, хоть немного освежила в памяти. Едем дальше!

2. Елизавета Батурина / Использование кейсов при тестировании

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

Стандарт - понятно, что нет никакого стандарта, надо смотреть по ситуации, что лучше именно для вашей компании. Если у вас, как у Елизаветы, ручной регрессии на 80 человеко-часов (вот ужас то! Какое счастье, что у нас эту работу делает компьютер...), то конечно, надо расписывать кейсы как для детей. Иначе можно и чек-листами пользоваться. иначе можно...

В общем, тесты всякие нужны, тесты всякие важны! А я пошла читать на форум ответы автора на вопросы слушателей!

3. Ирина Винокурова / Свободное плавание тестировщика

Ну и наконец! Закрывала первый день конфетки Ирина Винокурова. Девушка, которая за год, с прошлой школы тестировщика, успела познакомиться с крутыми тренерами и поиграть с ними во всякие там Алиасы (привет Татьяне Зинченко и Наташе Руколь), побрататься с самыми известными шишками мира тестирования (а теперь привет Баранцевым!), пожить в Москве, плюнуть на нее, вернуться в Калининград и учесать в Тайланд на все остатки зимы.

И главное, что она полностью счастлива! Несмотря на все сомнения перед уходом с основной работы, она смогла решиться! И уйти в неизведанное. В фриланс, на полную ставку. Ух. И получать кайф от путешествий, умудряясь совмещать работу и прогулки по Таю в поисках сувенирчика мне, любимой  Шучу.

В общем, Ира очень большая молодец, я ей немножко завидую - что это ее ниша. Это, наверное, здорово, путешествовать и не быть привязанной к месту. Я бы вот не смогла. Я не хочу жить где-то еще, я хочу жить здесь, именно здесь. И на пмж никуда не собираюсь. А оставлять съемную квартиру... А платить за нее, свалив в Тай?! Бррр.

Да и потом, фриланс вообще не для меня, по крайней мере, на full-time. Я вот, пока болела, в последний день горела желанием поработать. Ага, подключилась к рабочему компу и пошло-поехало. Сейчас вот тут дочитаю и пойду. А вот фильм посмотрю и пойду...

Понимаю, конечно, что просто не прижало. А то бы работала как миленькая. Но мне ближе офис. Я и раньше, на прошлой работе, когда наша команда стала первой, кто попробовал практику работы из дома, гордо приходила в офис. Ну а что? С коллегами у кофемашины поболтать. Всяко лучше, чем в 4 стенах сидеть... Не знаю, я бы не смогла. Точнее, смогла бы, но не захотела.

А Ира и захотела, и смогла! Чему я очень рада

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

TEST IT. Тестируем сайт Foodnation.ru

И снова здравствуйте! В эфире - TEST IT и я, ее сменная ведущая Киселева Ольга! Ее - потому что "рубрика" - "она моя", а не потому, что я опечаталась.

О чем мы поговорим сегодня? Ну конечно же, о тестировании.
Так как многие вопросы связаны с глобальным вопросом "а с чего же начать?", то мы решили разбавить ответы на вопросы онлайн-тестированием.

Итак, сегодня (возможно, не только сегодня), наш подопытный сайт - https://www.foodnation.ru/

Сайт был любезно предоставлен организаторами, так что публикую ссылку не боясь. А то, знаете как бывает, идет обсуждение сайта или его тестирование сразу 5-ю пользователями, например, во время семинара... И все, тю-тю, нету сайта. Временно, конечно, но все равно.

Так вот! Пришли мы, значит, на работу и нам говорят - "Вот, родной, тебе сайт, иди тестируй, завтра чтобы был отчет". Упс, это же мое первое рабочее место. А где мой наставник? А где документация? Ах, будет, но позже...

Ай, да и ладно, мы сами с усами! Пойдем пока потестируем, пока наставник освободится...

Напутствие тестировщика

И еще одна цитата из книжки  Software Testing (Ron Pattorn). Надо сказать, потрясающая цитата, завершающая одну из глав книги, звучит отличным напутствием, которое напоминает нам, что жизнь - не такая уж серая штука, в ней есть много всего интересного и удивительного.

What you should take away from this chapter is that you should leverage whatever means possible to be an effective tester. One situation might dictate using technology, another might require extra people, another might need just plain old brute force manual testing. Every software testing problem will be unique, and you`ll learn something new with each one. Experiment, try different approaches, watch what others do, but always strive to find the best way to make your testing more efficient and more likely to locate those bugs.

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

Аминь

Не надо тестировать в одиночку!

Еще одна небольшая цитата из книжки  Software Testing (Ron Pattorn).

It`s easy to fall into the trap of wanting to be solely responsible for testing your own piece of the software, but don`t do it. There`s too much to gain by having other help you out.

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

Ну и, собственно говоря, список того, почему новая пара глаз никому не повредит:

• Закон Пестицида. Люди замечают разные вещи в игре "найди 10 отличий" и в разной последовательности. То, к чему ваш взгляд давно привык, увидит "новый" человек.
• Закон Пестицида. Люди не только видят разные отличия, они еще и тестируют по-разному. Они могут чуть быстрее нажать на кнопку, выполнить действия в другой последовательности и прочее, прочее...
• Если тебе кто-то помогает, это позволяет избежать скуки. Скука - вот то, из-за чего наше внимание рассеивается и мы начинаем пропускать очевидные вещи.

Поэтому - не попадайтесь в ловушку "Мое! Никому не отдам!".

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

Это же мой проект. Я там единственный тестировщик была, кучу разработчиков пережила! И отдать другому? А вдруг там баги найдут, которые мимо нового тестировщика проскочат?!! Это же мне обидно будет видеть со стороны.

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

Главное - наступить на горло своей жадности и понять, что так действительно будет лучше

Если проблема в ресурсах, почему не достроили Вавилонскую башню?

Еще одна небольшая выдержка из книги Фредерика Брукса "Мифический человеко-месяц".

Вавилонская башня стала первым инженерным фиаско. Эта история глубока и поучительна в нескольких отношениях. Давайте, однако, рассмотрим ее как чисто технический проект и посмотрим, какие уроки администрирования можно из нее извлечь. Насколько хорошо проект был обеспечен необходимыми составляющими успеха? Имелись ли:

1. Ясность цели? Да, хотя и наивно недостижимой. Проект провалился задолго до того, как столкнулся с этим принципиальным ограничением.
2. Человеческие ресурсы? В большом количестве.
3. Материалы? Глина и битум в Месопотамии имеются в изобилии.
4. Достаточно времени? Да, нет никаких указаний на ограничение по времени.
5. Адекватные технологии? Да, пирамидальной или конической структуре присуща устойчивость и хорошее распределение нагрузки сжатия. Очевидно, свойства каменной кладки были хорошо известны. Проект провалился до того, как вышел за пределы технологических ограничений.

Так почему же провалился проект, если все это у них было? Чего у них не хватало? Двух вещей: обмена информацией и вытекающей из него организации. Они не могли разговаривать друг с другом и, как следствие, согласовывать усилия. Когда отказала координация, работа встала.

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

Так все-таки, отчего мы не успеваем? Потому что не хватает времени и ресурсов?

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

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

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

А то получите вожделенный Test Complete и внезапно окажется, что на нем еще надо учиться тесты писать. Что тесты писать - тоже время занимает... И опять у нас недостаток времени. Но времени ли?

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

Отчет об ошибке. Ты - это то, что ты пишешь.

Или вот так

Bug report - you are what you write.

Взято из книжки "Lessons Learned in Software Testing" (Cem Kaner, James Bach, Bret Pettichord):

Bug report - это главный рабочий продукт деятельности большинства тестировщиков. Благодаря этому документу у других людей составляется впечателение о вас как о профессионале. Чем лучше ваши отчеты об ошибках, чем лучше ваша репутация.

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

А ведь не только разработчики читают твои отчеты.

Группа поддержки хочет знать, исправлена ошибка или нет. Менеджер хочет понимать, в каком состоянии находится проект, правда ли в нем столько критических задач, сколько он видит в списке. И что он сделает? Откроет их и начнет читать. А что будет, если описание проблемы абсолютно непонятно? Отношение к автору будет скорее раздраженное - зачем он такой фигней занимается, когда релиз на носу?!

Признайтесь хотя бы сами себе - всегда ли Ваши отчеты об ошибках идеальны? Откройте все задачи, созданные полгода назад - Вы смогли бы сейчас по этому отчету воспроизвести ошибку или проверить, актуальна она или нет?

Всегда помните о том, что Вы - это то, что и как Вы пишите...

Кого спасем - себя или компьютер?

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

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

А вас эта шутка касается?

Или другой вопрос. Вот допустим, пьете вы чай, даже не чай, а облепиху, она жирнее, а не просто "высохнет, будет как новый". Ну и по закону жанра разливаете ее. Причем умудряетесь разлись и вперед (на ноутбук) и назад (себе на ноги). Кипяточек такой...

Внимание, вопрос - что будем делать первым, бежать в ванную остужать ноги или вытирать клавиатуру на ноуте и лужи около него?

Просто представила себе, как это смотрится со стороны "нормальных" людей - человек бережно протирает ноутбук, и снова, и снова... А потом уже убегает в поисках чего-нибудь холодненького