понедельник, 21 января 2019 г.

Наименование аттрибутов в Python: не все очевидно

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

Рассмотрим простой пример:


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

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

Подберем простой пример:
Есть класс а, у которого есть метод с двойным подчеркиванием в начале имени. Мы создаем новый класс b и наследуем его от класса a. После этого мы хотим раширить функционал класса b, добавив новую функцию:


Теперь, если мы не хотим переопределять метод input, внутри класса b мы обызаны работать с аттрибутом _a__numbers вместо __numbers, и постоянно помнить об этом.

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

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

среда, 12 декабря 2018 г.

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

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

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

среда, 5 декабря 2018 г.

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

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

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


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

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


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

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

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

вторник, 25 сентября 2018 г.

Еще раз про 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


вторник, 14 августа 2018 г.

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

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

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

четверг, 19 июля 2018 г.

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

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

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

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


среда, 18 июля 2018 г.

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

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


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


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


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


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


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