Тестировщикам посвящается

Сервисы для шаринга скриншотов и текста

Всем привет!

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

В интернете можно найти множество таких инструментов, и даже доклады на эту тему (например, доклад Алексея Баранцева).

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

Paint (Windows) - с этого инструмента, наверное, начинают все тестировщики. Все просто, PrintScreen, затем Ctrl+V, а затем уже все, что душе угодно - обрезайте, рисуйте стрелочки, пишите текст и т.д. :)

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

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

Snaggy - делаете скриншот, вставляете прямо на веб-страницу через действие Ctrl+V - изображение загружается и отображается ссылка на него. Присутствуют возможности редактирования изображения.

Pastebin - предназначен для шаринга теста. Регистрируешься, и создаешь свой "paste" c возможностью настроить приватность и срок хранения.

Сollabedit - предоставляет возможности совместного редактирования программного кода (или просто текста).

Список сервисов "по вашим комментариям":

Jing - позволяет создавать скриншоты и видео.

Imgur - сервис для обмена изображений

Clip2net - сервия для обмена изображений и файлов

Jet Screenshoot

Agile-доска для Redmine

Всем привет!
Пора уже отходить от своей свадьбы и путешествия и стряхнуть пыль с моего блога :)))

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

Полезные знания о TortoiseSVN для тестировщика

Всем привет!
Наверняка многие из вас знают такое понятие, как система контроля версий. Для тех, кто не знает, определение из википедии:

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

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

В данной статье рассмотрим систему контроля версий SVN и клиент, позволяющий работать с этой системой - TortoiseSVN. Все команды этого клиента добавляются в контекстное меню для файлов/папок файловой системы. На мой взгляд, очень удобно. Я люблю работать с UI клиентами. Кто-то предпочитает работу с SVN через консоль.

Почему в словаре MS Word нет слова "тестировщик"?

Всем привет!
Предупреждение. Это бесполезная с профессиональной точки зрения заметка.

Несправедливость какая-то получается.

Вводим в любом документе MS Word с проверкой орфографии слово "Тестировщик" и получаем красное подчеркивание. На что Word предлагает заменить это родное любому тестировщиковскому сердцу слово:

1. Татуировщик
2. Таксировщик - кто это вообще? :) (не буду писать тут, если интересно, погуглите).

Такие дела.

Запуск Apache JMeter на Windows первый раз

Всем привет!

Apache JMeter — инструмент для проведения нагрузочного тестирования, разрабатываемый Apache Software Foundation.

В данной заметке я хочу расписать по шагам процедуру запуска Apache JMeter первый раз на операционной системе Windows 8.1.

1. Устанавливаем JAVA. Загружаем последнюю версию с сайта, устанавливаем. Установочная папка в моем случае - "C:\Program Files (x86)\Java".

2. Устанавливаем Apache JMeter. Из раздела "Binaries" скачиваем zip-архив. Распаковываем содержимое в какую-либо папку. В моей случае - "E:\Soft\jmeter"

3. Добавляем 3 переменных окружения.

1. Перетащить курсор мыши в правый нижний угол экрана
2. Щелкнуть на значке "Поиск" и введите: панель управления
3. Выбрать Control Panel (Панель управления) -> System (Система)-> Advanced (Дополнительные параметры системы)
4. Выбрать Environment Variables (Переменные среды).
5. В разделе "Системные переменные" нажать кнопку "Создать".
6. Добавить переменную со значениями: 
1. Имя переменной - "JMETER_BIN", 
2. Значение переменной - "E:\Soft\apache-jmeter-2.11\bin" (в моем случае). Ок.
7. Аналогично п. 5-6 добавить переменную среды:
1. Имя переменной - "JM_LAUNCH"
2. Значение переменной  - "C:\Program Files (x86)\Java\jre7\bin\java.exe"
8. Найти в разделе "Системные переменные" переменную среды "Path", нажать кнопку "Изменить". В поле "Значение переменной" через знак ";" добавить еще одно значение "C:\Program Files (x86)\Java\jre7\bin". ОК.
9. Нажать "ОК" в окне "Переменные среды".

4. Запускаем файл "E:\Soft\apache-jmeter-2.11\bin\jmeter.bat".

Вот и всё, JMeter запущен.

P.S.
Очень полезная статья по JMeter, содержащая ссылки на другие полезные статьи - http://forworktests.blogspot.ru/2013/03/jmeter.html

Несколько полезных сервисов.

Тестирование веб-приложений на IE.

http://www.modern.ie/en-us - здесь можно бесплатно скачать образы виртуальных машин с различными версиями браузера IE и операционных систем Windows (образы доступны для платформ Windows, Mac и Linux), а также проверить сайт на наличие общих проблем кодирования, сделать скриншоты в разных браузерах и устройствах, проверить совместимость. Более подробный обзор.

Снятие скриншотов:

http://monosnap.com -  сервис позволяет быстро делать снимки экрана и делиться ими с другими пользователями посредством ссылки.

Тестирование мобильных приложений на iOS

https://testflightapp.com - сервис для бета-тестирования приложений. На данный момент преимущество заключается только в быстрой и простой установке приложения на устройство. Все остальные плюсы в виде получения логов, отчетов о падении приложений и др. ушли в никуда после покупки сервиса компанией Apple. Теперь новым пользователям невозможно скачать TestFlight SDK, который и предоставлял эти возможности.

https://www.bugsense.com - сервис для бета-тестирования приложений. Он как раз предоставляет те возможности, которые были исключены из TestFlight. Можно получать подробную статистику по использованию приложения, по падениям приложения и т.д..

Coded UI Test. 10 шагов на пути к успеху.

Всем привет!
Решила поделиться со своими читателями расширенным руководством по работе с Coded UI тестами.
На этом цикл статей, посвященных Coded UI, временно заканчивается.
Всем пока!

Тестеренок на SQA Days-15

Ребятки, всем привет!

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

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

Проводилась конференция в местечке с названием "Инфопространство", которое находится недалеко от Храма Христа Спасителя. Так что, как говорится, перекрестились, и в путь :)) Что обрадовало в первую очередь, когда я попала на место проведения - что скучать не придется, даже если ты одинокий тестеренок среди 700 других тестерят. Этому способствовали многочисленные стенды с активностями от партнеров конференции. Можно было и сфотографироваться на память, и заполнить всевозможные анкеты, получив возможность выиграть призы, а также сразу получив подарки в виде брелков, книжек, обложек на паспорт  и т.д. А уж наклейки никого не оставили равнодушными. 

Очень классным решением было выводить на большом экране в центре холла твиты участников конференции. В комнате игр можно было испытать на собственной шкуре шлем виртуальной реальности Oculus (надеюсь,не перепутала название), прокатившись на американских горках, находясь в нем. Я не решилась, но наблюдать за ребятами и девчатами в этом шлеме доставляло не меньшее удовольствие. Они отклонялись назад, вперед, почти падали, кричали, вопили, а зрители видели на экранах то, что видит человек в шлеме. Вобщем, всем было очень весело и смешно. Особенно докладчикам секции Б, когда во время докладов из соседней комнаты игр доносились крики девушек. Хм, тяжело им было сосредоточиться)) "Тяжелее" пришлось только нескольким докладчикам первого дня, когда во время их доклада в течение полминуты был саундчек у групп, которые выступали на афтепати (кстати, группы отличные). Приятным сюрпризом были большие и вкусные торты по случаю юбилея конференции. Ням-ням. Приятнее было смотреть только на Майкла Болтона, стоящего у столика за ноутбуком в своей фирменной шляпе :) Это же сам... Майкл!)

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

Если выделять доклады среди тех, на которых я побывала, то я бы отметила следующие:

1. Все доклады про A/B и мультивариантное тестирование. Мне пока не приходилось применять этот вид тестирования на практике, но для более глубокого ознакомления, чем определение, очень полезные доклады.

2. Дмитрий Штепура - Кроссбраузерное тестирование с популяризацией HTML5 и CSS3. Internet Explorer, не такой как все. Очень хорошая подача материала. Но даже больше позитива от того, что ооочень обаятельный и смешной докладчик. Думаю, не в последнюю очередь из-за этого взял одно из призовых мест.

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

4. Андрей Морозовский - Полная автоматизация развертываний ПО: общие концепции, пример реализации, сравнение подходов. Я же фанатка TFS, ALM в частности, так что не могу не отметить этот доклад :) Continious Deployment - это супер, Continious Delivery - вообще мечта, насколько я поняла, для докладчика пока недостижимая тоже. Надеюсь, на следующей конференции расскажут, что они ее достигли, и покажут, как.

5. Igor Khrol - Автоматизация тестирования: отбрасываем лишнее и проверяем суть. На мой взгляд лучший доклад конференции. Игорь уже не первый раз выступает с подобным докладом, активно продвигает эту тему. Он молодец, потому что именно такой должна быть автоматизация тестирования. Сколько было к Игорю вопросов после доклада, наверное, час точно его не отпускали! А теперь небольшая, но интересная история для тех, кто все-таки дочитал до этого места))

                                             Об особенностях восприятия изменений

На второй день конференции первым шел доклад про тест-дизайн. Я привычно заняла свое место около прохода, рядом со мной сел какой-то парень и пара девушек. Я послушала доклад про тест-дизайн, который был ну ооочень интересным, и пошла вместе с другими тестерятами общаться с докладчиком в кулуарах. Естественно, на следующий доклад про метрики тестирования опоздала чуть-чуть. Хорошо, мое место не заняли, потому что я предусмотрительно положила на стул блокнот (а что, так все делали). Доклад был еще интереснее предыдущего, я смотрела на экраны, все внимательно записывала. В конце, когда докладчику стали задавать вопросы, парень справа от меня что-то комментирует, я поворачиваю голову, и вижу, что это Игорь Хролл) И тут я думаю, как долго он тут сидит, уже 2 доклада, или только 1, а я его не замечаю?))) Оказалось 1. Но я же тестировщик, я должна быть внимательной, как же я этого не заметила? А все из-за особенности восприятия изменений. Когда ты сосредоточен на чем-то одном, ты можешь не заметить оооочень много. По этому поводу я недавно читала очень занятную статью, и волею судьбы довольно быстро испытала это на себе. Если лень читать, можете сразу посмотреть это видео про слепоту невнимания. Посмотрите, не пожалеете! 

-----------------------------Конец истории-------------------------------.

6. Александр Александров  - Тест-дизайн: проще читать или проще писать. Нет циклам в тестах. Нет слову "любой".

7. Григорий Сенин - Waterfall revisited: практические метрики тестирования. Ну очень круто! Уже хочу применить у себя на работе.

8. Игорь Бондаренко - Crystal Agile, или как мы приспособили процесс разработки для обеспечения максимального качества. Самая полезная информация - про метод экспертных оценок, мы так и не дошли до ее применения. Докладчику могу посоветовать посмотреть в сторону канбан, учитывая, что у них часто возникают новые задачи посреди спринта.

9. Александра Ковалева - Планирование трудозатрат на тестирование. Отличный доклад, тоже хочу попробовать применить. Девушка профессиональная и очень обаятельная. Когда она говорила слово "джунирята", я думала - "родственная душа". Мы на работе говорим "тестерята" :)

10. Natalya Rukol - Миссия тест-менеджера. Без комментариев. Просто супер. Казалось, даже на полу нет свободных мест.

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

Разработка через шантаж

"Разработка через шантаж". Такое вот смешное понятие процесса разработки родилось у нас в ходе ежедневного митинга, когда архитектор сказал, что они втроем (он подразумевал трех программистов) выкатят релиз через неделю. Эй-эй, полегче, а ничего, что мы команда)) В итоге я, как тестировщик, пообещала найти какой-нибудь зловредный баг, а наш аналитик/product owner повысить ему приоритет. Если не вспомнит, что мы команда. Такие дела :)

Test impact в TFS

Есть в TFS такая замечательная штука, как test impact. Не буду рассказывать подробно, по ссылке все замечательно описано. Если кратко, то вам предоставляется возможность получить набор тестов (как unit, так и UI, что для нас самое важное), которые нужно выполнить, чтобы проверить последние изменения кода. Получается, вам не нужно выполнять все тесты. Система сама подскажет вам, какие части тестируемого приложения изменились, а какие остались нетронутыми.

Принцип работы очень прост - вы привязываете тест-план из Microsoft Test Manager в какому-то билду тестируемого приложения из TFS. Затем вы выполняете эти тесты, используя опцию "Run" из MTM и отмечаете результат прохождения каждого теста. Предварительно нужно настроить запуск тестов на сбор "test impact" информации. Все! Теперь, выбрав новый билд и билд для сравнения (для которого мы собирали информацию) вы можете получить список тестов, которые рекомендуются к выполнению.

Очень полезная вещь!

Как тестируют в Гугл. Впечатления от прочтения и краткий обзор.

"Качество родится только тогда, когда разработка и тестирование начнут жить вместе" - эта мысль красной строкой проходит сквозь всю книгу Джеймса Уиттакера "Как тестируют в Гугл". Эта книга просто перевернула мой мир. Как будто кусочки пазла собрались наконец в одну картину. Теперь я знаю, к чему стремиться. В каком направлении развиваться, как специалист. И какую организацию процесса разработки ПО считать идеальной.

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

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

Разработчик - пишет код, проводит код-ревью, пишет юнит-тесты.

Разработчик в тестировании - фокусируется на тестируемости кода и создании инфраструктуры тестирования. Тест считается такой же фичей приложения, как и другие, и за нее отвечает разработчик в тестировании.

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

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

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

Defect-Driven Development

Ребятки, всем привет!

Я сейчас читаю очень замечательную книжку "Как тестируют в Гугл". Вот здесь ее анонс, для тех, кто еще не видел. Электронная версия стоит всего 100 рублей, за такое содержание это просто копейки, друзья мои, очень советую. Позже я обязательно напишу ее краткий обзор. Но даже сейчас могу сказать, что она О-ФИ-ГЕН-НАЯ!!! =)

Так вот, встретилось мне в этой книге такое понятие, как DDD, которое расшифровывается не как "Domain-driven design", и даже не как "Deadline-driven development", а как "Defect-driven development".

Так что же это такое?

Defect-Driven Development — разработка через дефекты. Принцип следующий. Мы выпускаем продукт и объявляем его бездефектным. Когда пользователь находит баг, мы исправляем его и снова объявляем продукт бездефектным. Таким образом, исправляются только по-настоящему значимые баги для пользователей. Этот процесс идеален для доработки существующего продукта. Вы исправляете только важные баги, а не возитесь с дефектами, до которых никому нет дела.

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

Redmine. Отображение подзадач под родительской задачей.

    К чему я привыкла в TFS и чего никак не могла найти в Redmine, так это отображения подзадач под родительской задачей в списке задач. А оказалось все очень просто.
    Итак, по умолчанию задачи у нас отсортированы по номеру по убыванию.

Наши простые шаги.
1. Добавляем в нашу таблицу еще один столбец "Родительская задача". Применяем.

2. Сортируем таблицу по столбцу "Родительская задача".

3. Аналогичным п.1 способом удаляем столбец "Родительская задача" из нашей таблицы за ненадобностью.

И получаем такую картину:

Социальный тестировщик Роб Ламберт

      Ребятки, в данной заметке хочется поделиться с вами интересным блогом тестировщика веб-приложений Роба Ламберта, известного также, как "Социальный тестировщик". Вот его блог. А здесь находится довольно-таки занятная книжка советов по тестированию веб-приложений "The Blazingly Simple Guide To Web Testing 36 Ideas to try", которая будет полезна начинающим тестировщикам веб-приложений и даст достаточно (а конкретно, 36) идей для тестирования. Книга на английском языке, но небольшая, очень быстро и легко читается. Приятного ознакомления!

Сравнение test managment систем, интегрирующихся с Redmine.

Ну здравствуйте, ребятки!

Наконец-то я добралась до своего блога :) Можете вздохнуть спокойно, я его не забросила, и буду продолжать радовать вас различными статьями и заметками. Просто в декабре я решила поменять работу. Это привело к тому, что я пока больше не работаю с моим любимым TFS и Coded UI тестами (надеюсь, это временно, очень я их полюбила). Но новая работа - это всегда новый опыт и новые знания. Так что буду с вами делиться тем, что изучаю, может для кого-то и будет полезным.

Итак, до встречи, TFS, и здравствуй, Redmine. Мне, как тестировщику, нужна система управления тест-кейсами. Не могу я тесты писать в Excel. Это лично мое мнение, я его никому не навязываю. Поэтому предлагаю ознакомиться с табличкой сравнения разных Test management систем, которые интегрируются с Redmine. В большей степени эта интеграция сводится к возможности заводить баги в Redmine при падении теста во время его выполнения. Табличка находится здесь. Рекомендую скачать ее, т.к. при просмотре в браузере может отображаться не все ее содержимое.

Всем спасибо и до связи!