Простые советы по поиску багов - или напоминалка мне самому

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

Простые способы найти баги:
1) Фантазировать что вы реальный пользователь и выполнять реальные действия в системе (а не просто проверять функционал отдельных элементов)
2) Проверять JS консоль на ошибки (тут можно найти очень много "скрытых" проблем)
3) Постоянно тестировать с разными аккаунтами (разные роли / права доступа)
4) Обновлять страницу и проверять что она выглядит так же (иногда при обновлении страница загружается уже другая)
5) Пытаться взаимодействовать даже с неактивными элементами (нажатие на неактивные кнопки и ссылки)
6) Проверять обработку введенных значений во всех полях (текст, числа, календари, чек-боксы, выпадающие списки и прочее)
7) Проверять все как минимум в двух разных браузерах (и желательно в таких, которые используют пользователи, конечно)
8) Менять тестовые сценарии и вводимые значения (пестицид, ну вы знаете)
9) Менять размер экрана / устройства (ширина экрана браузера, соотношение сторон экрана и прочее)
10) Уделять время исследовательскому тестированию, когда вы не пишете автотесты и не делаете какие-то срочные / регулярные проверки и задачи, а просто тыкаете свое приложение и изучаете как оно себя ведет в разных условиях

Потестим: баги повсюду

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

1) Баги есть даже на серьезных и крупных проектах с миллионной аудиторией
2) За пять минут показать процесс тестирования не получается, и вместо 5ти минут видео получилось на 30ть минут 😊
3) Чтобы найти баги не нужно вообще знать ничего о тестировании (к сожалению)
4) Мне еще предстоит научиться записывать интересные ролики и нормально их монтировать, а пока делаю так как умею (извините 😂 )

В процессе загрузки моего первого видео на новом канале обнаружился довольно неприятный баг на youtube! (youtube, Карл! - это же Google! - и я уже не говорю про юзабилити проблемы при загрузке видео - это печалька)

Вот и скриншотик с JS ошибками на Youtube:

Печаль, баги повсюду.

Подписывайтесь на канал, ставьте лайки и пишите в комментарии что еще можно потестировать :)

Следующий объект для тестирования - портал http://software-testing.ru 😎(спойлер: посмотреть будет на что 😂😂😂)

Еще раз про pairwise

Всем привет,

эта статья будет интересна тем, кто либо совсем не знает что такое pairwise, либо тем, кто что-то слышал, но все еще не понял что это за черная магия :)

Как многие уже знают, "протестировать все невозможно" - и это утверждение в частности, базируется на том, что полный перебор всех параметров некоторой системы и проверка ее работы при таких параметрах займет миллиарды лет, даже при условии что каждый тест занимает 1 миллисекунду и даже если их запускать параллельно (просто ОЧЕНЬ много возможных комбинаций).

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

Есть исследования (http://www.pairwise.org/papers.asp), которые доказывают, что подавляющее число ошибок в программном обеспечении так или иначе связано с комбинацией оригинальных значений любых двух параметров сложной системы. Конечно, есть ошибки, для воспроизведения которых может потребоваться определенная комбинация определенных значений сразу трех параметров, но вероятность воспроизведения такой ошибки значительно меньше, чем вероятность воспроизведения ошибки, которая воспроизводится при комбинации значений двух параметров.

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

Разберем на простом примере. Есть три параметра:
- Возраст (разбиваем на категории - до 18ти, от 18ти до 24, от 24х до 35ти и от 35 до бесконечности)
- Пол (М/Ж)
- Цвет глаз (карие, голубые, серые, зеленые, черные)

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

Для составления набора комбинаций воспользуемся инструментом PICT (кросс платформенный, с открытым исходным кодом)

Создадим файл data.txt:


И сгенерируем уникальные комбинации, используя метод pairwise:


Эти комбинации мы теперь можем использовать в наших тестах и можно быть уверенными, что эти комбинации отловят 80+% всех багов (эмпирически научно доказано, так что пользуйтесь).

В рассмотренном примере PICT сгенерировал 20 комбинаций, а полное декартово произведение бы дало 40 комбинаций.

Обратите внимание, что метод особенно хорошо работает там, где декартово произведение дало бы нам больше 1000 уникальных комбинаций, при этом pairwise техника может помочь значительно сократить количество таких комбинаций, что сделает задачу "протестировать все уникальные комбинации" - вполне выполнимой (но конечно же всегда есть вероятность супер редких багов, для воспроизведения которых потребуется определенная комбинация 3-4 параметров - помним об этом).

Полезные статьи:
http://qcthoughtsaloud.blogspot.com/2010/06/pairwise-testing.html
http://software-testing.ru/library/testing/test-analysis/1304-pairing

PyTest + TeamCity - автоматический репортинг

Оказывается для тестов на Python есть отличная библиотечка для интеграции с TeamCity - https://github.com/JetBrains/teamcity-messages

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

Проведение встреч 1:1

Что такое встреча 1:1? Это общение менеджера (непосредственного руководителя) с вами и обзор ваших результатов и целей.

Особенности таких встреч:
1) Присутствуют только двое людей
2) Длится недолго, обычно 20-30 минут
3) Проходит регулярно, каждые 2-3 недели

Я советую разделять встречу на три этапа:
1) 5 минут просто обсуждаем какие-то текущие моменты
2) 10 минут - менеджер рассказывает о том, как он оценивает проделанную с предыдущей встречи сотрудником работу - что он заметил и что ему понравилось. Так же обращая внимание на любые негативные моменты - потому что негативную обратную связь надо давать при личном общении и как можно скорее, не откладывать ее на пол года
3) 10 минут - обсуждаем какие цели в общем стоят перед компанией, командой и сотрудником, и почему они важны, как он сам их видит и как планирует по ним работать
4) 5 минут обсуждаем какие-то дополнительные вопросы или что-то, что должно быть обсуждено на отдельной встрече.

Подборка книг для менеджеров: the best of the best

Стивен Р. Кови - 7 навыков высокоэффективных людей
Книга, которая, как я считаю, изменила мою жизнь. Моя первая книга по менеджменту :) Немного фанатична, но в формате жизненных историй автор рассуждает об очень важных темах, которые относятся не столько к работе менеджера, а в целом к жизни и ценностям. Хотя бы попробуйте прочитать до 100 страницы :) я читал медленно, перечитывая некоторые моменты, и хотя периодически я впадал в депрессию (например когда надо представить себя на своих похоронах - там есть такое задание :) ) - в целом книга отличная и стоит прочтения (но все кому я ее рекомендовал не испытывали такого же восторга почему-то )) ).
Книга многократно окупилась еще до того, как я дочитал ее до конца :)


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


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


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


Максим Батырев - 45 татуировок менеджера
Очень хорошая книга о личностном росте, о миссии менеджера, о том как менеджер и лидер думает и как он видит жизнь вообще. Иногда есть перегибы, но в целом точно стоит прочитать, особенно молодым менеджерам. Я пару советов/татуировок себе сохранил, а некоторые обнаружил уже из собственного жизненного опыта )) и еще раз вспомнил свои ошибки - и знаю как их не повторять теперь.


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

Личные консультации и подготовка к QA интервью

Всем привет,

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

1) Ревью резюме с рекомендациями (я проверяю резюме, и рассказываю что надо переписать, что убрать и что добавить, чтобы резюме выглядело интереснее и вас заметили и пригласили на интервью) - по результатам могу порекомендовать вас в одну из компаний как подходящего кандидата (если у меня будут подходящие контакты и вакансии)

2) Помощь в подготовке к техническому интервью на позицию QA Manual / QA Automation (репетиция собеседования, дополнительные тренировки с практическими заданиями по теории тестирования, сетям, линуксу или Python)

3) Помощь в прокачивании практических навыков и знания теории в Networks, Linux, Python, Selenium, REST API, Android mobile testing (любая из этих тем - будут практические задания "на вырост", подсказки и помощь с любыми вопросами, будем работать индивидуально  пока все не получится)

4) Как правильно проводить технические интервью (все тонкости проведения интервью - будет актуально не только QA, но с фокусом именно на QA - подробный разбор всех шагов, важных вопросов, репетиции)

Если Вам интересно - напишите мне в Telegram (xwizard707) или Skype (xwizard707).

Время прокачивать свои навыки и переходить на новый уровень!

Selenium: дожидаемся загрузки страницы

Наверное, почти каждый, кто пробовал писать тесты на Selenium, знаком с explicit wait и implicit wait.

Но иногда их не хватает, да и хочется чтобы тесты работали быстро.

Еще есть AJAX и скрипты, которые подгружают контент только при скроле странички и не дают нам успокоиться просто установкой таймаутов. Нужно что-то еще.

Конечно, для каждого случая тут можно придумать "свое решение" (что чаще всего и делают).

Здесь хочу поделиться хорошей ссылкой, как один инженер уже решил такую задачу для себя (и почему эта проблема возникла у него):
https://blog.codeship.com/get-selenium-to-wait-for-page-load/

Мое решение я сделал в виде функции, может, и не самой красивой, но у страничек почти не остается шансов незагрузить весь свой контент (для загрузки картинок, конечно, нужна дополнительная магия и она тоже есть в виде отдельной функции).

Логика простая - скролим страничку и с помощью выполнения JavaScript дожидаемся загрузки странички и каждой картинки на страничке.

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

Код доступен здесь: https://github.com/TimurNurlygayanov/test-tasks-example/blob/master/selenium_wait.py

Комментарии и предложения о том, как можно сделать лучше, приветвуются )).

Ожидаемый результат

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

Я пишу:

Steps To Reproduce: 1,..2..,3..
Expected Result: Страница выглядит хорошо, все элементы отображаются правильно.
Actual Result: Но, к сожалению, что-то не так <screenshot>

На самом деле все немного иначе:
Steps To Reproduce: open page <url>
Expected Result: На этой странице по-любому сейчас будет мясо будут баги.
Actual Result: Ну вот, как всегда, давайте делать скриншот.

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

Хорошей всем рабочей недели :)

Игра в Кубики

Очень многие в детстве играли в деревянные кубики, выстраивая из кубиков слова, змейки, пирамидки, стенки или колонны :)

У вас появилась возможность поиграть в кубики, но теперь уже онлайн! Конечно же, мы добавили специальные правила, чтобы игру было интереснее тестировать (многие просили нас сделать задание на тестирование требований, и теперь такое задание у нас есть :) ).

На игровом поле всего 6 кубиков, и 4 цвета (один цвет - белый, означающий отсутствие кубика).

Правила игры:
1. Белый кубик - пустое место, куда может быть установлен любой кубик. Сверху пустого кубика не могут находиться другие кубики.
2. Красный кубик весит в два раза больше других кубиков.
3. Кубики одного цвета не должны соприкасаться.
4. Зеленый кубик выдерживает вес одного стандартного кубика.

Попробуйте придумать тестовые сценарии для такой игры, а потом проверьте сколько баллов получится набрать, пройдя все кейсы из вашего тест плана :) Максимально можно набрать 160 баллов, игра доступна в Песочнице QA Battle (для доступа к заданию нужна регистрация в QA Battle).

Очень просто автоматизируем сбор урожая в Android игре

Недавно был опубликован отличный инструмент для автоматизации мобильных приложений - Airtest IDE.

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

Мне нравится играть в Township, поэтому на примере этой игры я и решил поэкспериментировать и автоматизировать простые действия пользователя, проверив возможности фреймворка.

Интерфейс Airtest IDE выглядит удобно, все достаточно просто и понятно.

Тесты пишутся на Python, при этом в IDE мы можем объявлять собственные переменные, присваивая им картинки с экрана устройства, выглядит это так:

В Python коде это будет выглядеть иначе:

carrot = Template(r"tpl1526539603051.png", record_pos=(0.078, -0.018), resolution=(1920, 1080))

Картинки складываются прямо рядом с Python скриптом отдельными файлами.

Пример ожидания и нажатия кнопки "Забрать" (для ежедневной награды пользователю):

Немного разобравшись с возможностями инструмента, я перешел к автоматизации реального сценария:

1) Открываем игру

2) Ждем ежедневную награду и забираем ее, если награды нет, то просто пропускаем этот шаг

3) Если на поле есть созревшая морковка, то собираем всю морковку

4) Если на поле есть созревшая пшеница, то собираем всю пшеницу

5) Если есть пустые поля - засеиваем их пшеницей

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

Итого:

Сильные стороны Airtest IDE:

1) Поддерживает Python синтаксис и сторонние Python библиотеки

2) Умеет находить элементы по картинке (а значит с его помощью можно автоматизировать любое приложение, в том числе мобильные игры)

3) Есть удобные локаторы, например, можно найти элемент по тексту внутри элемента и даже по регулярке, можно применять сразу несколько локаторов

4) Основан на Poco Library и поддерживает все его фичи.

Слабые стороны Airtest IDE:

1) Пока нет поддержки iOS (но обещают скоро сделать)

2) IDE не работает на Linux (либо Windows, либо MacOS) - но можно писать на чистом Poco SDK, тогда и IDE не нужна

3) Нет всего многообразия продвинутых локаторов как в Appium (например XPath) - но есть другие, и их вполне хватает

4) Нет подробной документации по продвинутому использованию (будем надеяться скоро появится)

5) Нет нормальной интеграции с тестовыми фреймворками, придется одновременно использовать Airtest IDE и PyCharm, копируя куски кода, чтобы написать нормальный тест, либо сразу переходить на PyCharm + Poco SDK, без Airtest IDE.

Appium: автоматизация Android приложений

Appium - известный инструмент автоматизации мобильных приложений (Android & iOS), с возможностью написания тестов на большом количестве языков программирования / фреймворках, среди которых есть Python (полный список поддерживаемых языков можно найти на сайте).

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

Дополнительные условия:
1) Пункты меню могут быть вложенными
2) Меню динамическое, меняется каждый день вручную несколькими людьми
3) Надо проверить каждую категорию (кликнуть на каждый пункт меню и проверить сколько будет доступно товаров на странице)

Метрики/KPI в тестировании: как узнать кто хороший мальчик?

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

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

За время работы в качестве QA инженера, лида и менеджера, я сформулировал для себя собственные практики оценки QA специалистов, которые, конечно же, субъективны, но все-таки хочу ими с вами поделиться.

Как искать и находить баги

Есть QA инженеры, которые находят много багов, а есть те, кто находит в разы меньше. Много лет размышляя о том, как же это так у меня получается находить в несколько раз больше багов чем у других(и как у других получается находить больше чем нашел я), я сформулировал список советов, соблюдая которые почти любой человек может находить достаточно много багов.

Советы эти очень простые и проверены многолетней практикой многими QA инженерами, с которыми я обсуждал как они ищут и находят баги:

Регистрация в QA Battle

До конца апреля регистрация на QA Battle остается бесплатной. На данный момент зарегистрировано 500+ человек (это мы еще почти не рекламировались) и мы ожидаем, что будет более 3000 участников (хотелось бы набрать 5000).

Если наберем 5000+ участников - то, возможно, расширим набор призов для тех, кто займет первые 20ть мест в чемпионате (сделаем футболки или медальки/статуэтки на память о вашем участии)

Важная информация: если у вас не получается зарегистрироваться на сайте https://qa-battle.com - откройте этот адрес в приватном режиме браузера и повторите попытку регистрации. Иногда ваш браузер может закэшировать старую версию JS скриптов, в результате чего регистрация может не работать (если вы открывали этот сайт раньше). У новых пользователей регистрация должна работать в штатном режиме. Если что-то не работает - пишите на почту timur@qa-battle.com.

Чемпионат по тестированию QA Battle

Всем привет,

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

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

И вот настало время действовать :)

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

Сколько вы находите дефектов за неделю?

Всем привет,

подниму немного холиварную тему - сколько должен находить багов хороший QA инженер за неделю?

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

Когда я только начинал познавать эту профессию, и работал первые несколько месяцев над одним проектом в Cisco - моим личным рекордом было 18 найденных и описанных багов в неделю. Я был неопытным, а проект очень старым и стабильным :)

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

Уже позже, когда я работал менеджеров распределенной команды (большая распределенная команда в 30 крутых QA инженеров) - я по-прежнему продолжал находить баги. Я уже почти совсем не занимался ручным тестированием (то есть таких задач не было) и количество лично мной найденных багов совсем не входило в мой KPI (наоборот каждый раз когда я отвлекался от менеджмента на меня укоризненно смотрели :) ) . - все равно я репортил от 1 до 10 багов в неделю.

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

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

За сегодня нашел и зарепортил 25 дефектов. Почти весь день был потрачен на то чтобы писать тексты репортов об ошибках (хотя конечно же есть шаблоны) - пока подготовишь последовательные скриншоты со стрелочками, пока все опишешь на понятном английском, выделишь нужные фрагменты жирненьким :)

25 баг репортов в день, мой новый личный рекорд :).

А сколько обычно багов репортите вы?

Кстати, у меня появился телеграм канал, подписывайтесь: https://t.me/qa_and_testing