Это, пожалуй, одна из важнейших вещей, которые хочется запомнить и которым хочется следовать.
(Источник - А. Швец. Погружение в паттерны проектирования)

О первых шагах в тестировании

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

Допустим, человек решил стать тестировщиком. С чего можно начать?

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

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

Теоретических источников много, но вот мои любимые:
1. Видео-туториал на русском языке от СКБ Контур: https://ulearn.me/Course/Testing
2. Туториал на английском языке, совмещающий видео и краткий саммари-текст: https://www.guru99.com/software-testing.html
3. Из книг хороши следующие:
- Роман Савин - Тестирование.ком. Автор пишет живо и с юмором, но часть теории (впрочем, меньшая) устарела или просто мало где актуальна. Неплохой старт, но её нельзя считать настольной книгой современного QA.
- Святослав Куликов - Тестирование программного обеспечения. Очень хорошая книга, регулярно обновляется на официальном сайте, однако есть и "стабильная" неизменяемая версия. Сам блог автора тоже очень интересный, кстати, но об этом несколько позже. Может по праву считаться одной из лучших книг для быстрой консультации по теоретическим вопросам.
- Сэм Канер - Тестирование программного обеспечения. Неплохая, но немного неоднозначная книга. Как мне кажется, из неё хорошо брать технические сведения, а вот философскую часть лучше оставить на потом, чтобы изначально не запутаться в некоторых противоречиях с отечественной школой тестирования.
- И последний в начальном списке, но не по значимости - мой нежно любимый Джеймс Уиттакер - Exploratory Testing. Книга на русский не переведена, но очень уж она хороша, стоит времени прочтения (ради неё я была бы рада выучить английский до приличного уровня 🙂). Там рассказывается не только про уникальную методику исследовательских туров, но и про тестирование как процесс в целом, а ещё представляются некоторые инетерсные задачки "на подумать", без очевидно правильного ответа, - просто чтобы размять мозги и вспомнить, что знать всё на свере нереально :) Они восхитительна, и она, пожалуй, для меня любимейшая книга на профессиональную тему.

Итак, мотивация и цель есть, теория проштудирована, - что теперь?

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

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

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

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

Как ручному тестировщику выжить в мире автоматизации?

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

Поэтому пока, чтобы совсем не теряться, поделюсь своим косеньким, но с душой сделанным переводом одной прекрасной статьи (ссылка на оригинал для ценителей английского есть в конце) в блог родной компании: https://blog.noveogroup.ru/2018/10/3-sposoba-vnesti-vklad-v-kachestvo/

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

Вообще не люблю разделение понятия тестирования на "ручное" и "автоматизированное", если речь о чем-то большем, чем об инструментах выполнения тестов (и то, как мне кажется, в таком случае лучше так и говорить: ручные/автоматизированные ТЕСТЫ, а не тестировщики).
Мыслями про то, какие классовые неравенства и, хуже всего, непонимания самой сути процесса обеспечения качества это влечёт за собой, я ещё обязательно поделюсь 👩🏻‍💻

Инструменты, которые могут помочь тестировщику в работе

Вчера посчастливилось выступить на митапе SPb SQA Group - оставлю запись тут.
Эту тему мы с моим ментором Антоном уже освещали внутри компании. Фидбек был позитивным, так что доклад пошёл дальше! :)

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

https://youtu.be/60Wfa5wmePY

Почему нельзя стать хорошим автоматизатором, не овладев ручным тетированием на практике?

На эту заметку меня натолкнуло создание тренинга по введению в автоматизацию тестирования - вспомнилось, как я сама в неё входила. Это было весело. И поучительно - для себя на совём же примере :)

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

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

Основная задача автоматизации - облегчить рутину и уменьшить так называемый эффект (парадокс) пестицида (см. http://software-testing.ru/library/testing/testing-for-beginners/1202-pesticide-paradox), с которым рано или поздно сталкиваются все тестировщики. Но готов ли тестировщик к тому, чтобы начать автоматизировать - другой вопрос.

Я представляю экзоскелет (питаю слабость к роботоподобным гаджетам 🤷🏻‍♀️), надев который, человек получает +20 к силе, +50 к скорости и +30 к ловкости. Несомненно, если сравнить физические показатели одного и того же достаточно умелого человека без и с надетым устройством, мы обнаружим, что использование экзоскелета действует на пользователя исключительно благотворно.
Однако если человек, надевший его, не был особо ловким и до использования устройства, то новая амуниция может принести лишь проблемы - невозможно научиться хорошо бегать, если не умеешь уверенно стоять на ногах. И уж тем более не выйдет ничего хорошего, если внутри навороченного девайса не будет мудрого и грамотного пользователя, который сможет не только выжать из устройства максимум, но и увеличить общий КПД за счёт собственных навыков и сил. В моём случае автоматизация была тем самым экзоскелетом, а человек внутри него - тестировщица, которая очень хочет получить обещанные перки.

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

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

Прекрасная статья на Хабре, не поделиться которой было бы грешновато: https://habr.com/company/funcorp/blog/426759/

Про митапы

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

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

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

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

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

Вместо вывода вкину соображение: как мне кажется, чтобы увереннее выступать, нужно больше выступать. Преодолевать стеснение, придумывать или подбирать интересные темы, взаимодействовать с публикой. И любить своё дело, а как же иначе :) Потому что нет лучшей приправы к хорошему докладу, чем искренний интерес и огонь в глазах спикера!

А это фото с митапа PyLadies SPb в JetBrains. На память, как раз под постом о митапах ^^

Немного полезностей: 4 онлайн-ресурса в помощь тестировщику, которые я открыла для себя не так давно

У IT-индустрии есть прекрасная особенность, которая влюбляет меня в эту сферу всё больше и больше с каждым днём: здксь необходимо постоянно развиваться.
Как минимум это мониторинг того же Habr'а и Software Testing; как максимум -бесконечность, включающая регулярное чтение полезных тематических блогов, посещение мероприятий сообщества, хотя бы минимальное знакомство с обновлениями, представленными в release notes любимых и часто используемых продуктов и, конечно же, самостоятельный поиск таковых.

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

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

1. pairwiseTool (https://pairwise.teremokgames.com/)

Просто и сердито: паирвайзер онлайн, который генерирует как попарные проверки, так и полный перебор. Т.к. pairwise заслуженно считается одинм из наиболее эффективных методов комбинирования тестовых данных, всегда держу вкладку с этой удобной тулзой под рукой. Огромный плюс: есть отдельная панель для задания условий связи между тестируемыми сущностями (например, параметр X не может существовать без параметра Y, и ещё много вариантов). Highly recommend!

2. Бесплатная система ведения тестовой документации и багтрекинга Qase.io (https://qase.io)

Нашла этих ребят совершенно случайно, ещё когда система была в открытом бета-тестировании и падала с 500-й ошибкой, когда я пыталась редактировать тест-кейс (смахиваю слезу ностальгии). Теперь баги пофиксаны, фичи доделаны, и в результате мы получаем отличную систему вроде TeatRail (судя по функциям и виду отчетов, создатели явно вдохновлялись им), удобную и интуитивно понятную, а главное - бесплатную. Посмотрим, как пойдёт дальше, но сейчас продукт выглядит очень перспективно и так и манит начать работать с ним :)

3. Testim - искуственный интеллект на страже стабильности ваших тестов (https://testim.io)

Веб-приложение, которое выглядит как расширенная версия Selenium IDE (однако под капотом у него, если я правильно поняла, вовсе не Selenium). Суть такова: тестировщик инициирует запись теста, кликает кнопки и вводит значения, затем завершает запись и руками редактирует получившийся тест, добавляя в конце нечто проде ожидаемого результата. Создатели утверждают, что за счёт использования AI тесты стабильно проходят, даже если локаторы меняются - "In fact, the more you're running tests, the more stable they get". Звучит интересно, да и на практике использование вполне понятное и простое - неплохо для тех, кто ещё совсем не знаком с автоматизацией.
Огромный минус: инструмент платный, так что я пока наслаждаюсь 2-недельным трайалом, а потом... потом будем заводить новую почту, видимо :) Но штука однозначно прикольная, стоит того, чтобы потратить немного времени на её изучение.

4. Образовательная платформа Stepik (https://stepik.org)

Нечто вроде Coursera. В арсенале довольно много интересных курсов с лекциями и заданиями, по прохождении которых можно получить сертификат (в том числе от настоящих университетов например, СПбГЭТУ «ЛЭТИ», Высшая школа экономики (НИУ ВШЭ) или БФУ им. И. Канта). Очень рекомендую для самообразования или просто для поиска интересностей всяких и расширения кругозора.
Платформа бесплатная и пока что обещает оставаться таковой.

Всем продуктивного окончания рабочей недели и просто отличного дня! ☺️

Мой друг сегодня обратил внимание, что на ютубе есть ссылка-запись выступления на PyLadies SPb meetup. Преодолеваю стеснение и постю на память!
https://www.youtube.com/watch?v=yvqfXM1DuAY

Грабли вхождения в автоматизацию

Как упростить себе жизнь и ускорить тестирование рутинных фич? Как стандартизировать проверки и исключить человеческий фактор? Как избавиться от эффекта пестицида?

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

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

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

Итак, тебе предстоит длинный путь. Какие же ошибки тебя подстерегают?

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

2. "Буду пробовать всё подряд, пока не получится".
Правильный путь: поставить себе конкретные задачи. Например, "автоматизировать тестирование API, потом добавить UI смоук-тесты, затем добавить регрессионных сценариев". Это поможет не только сузить область и не позволять забить себе голову тоннами лишней информации, но и упростит способ оценки своего прогресса. Можно даже визуализировать задачи: от доски в трелло до рисунка-лесенки.

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

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

5. "Сделаю всё как можно быстрее".
Правильный путь: дать себе время, не торопиться. Нет, даже не так: ДАТЬ СЕБЕ ВРЕМЯ И НЕ ТОРОПИТЬСЯ. На этих граблях я до сих пор пляшу с переменным успехом :) Надо сразу смириться с мыслью, что качественно обучиться автоматизации за 2-3 недели невозможно. Не стыдно стоять на месте, пока не поймешь тему, не стыдно задавать вопросы и пробовать, пока не получится. Всё время, которое вы тратите сейчас - это инвестиция в будущее, и чем меньше спешки, тем лучше.

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

7. "Справлюсь без наставника, я сам(а) всё умею".
Правильный путь: найти ментора или человека, к которому можно обратиться за помощью. Это может быть разработчик или QA, кто-то внутри компании или вне (в сообществе). Чтобы стать лучше, надо всегда иметь перед глазами соответствующий пример. Кроме того, возможно, какую-то проблему уже решили - и гораздо продуктивнее будет спросить об этом старшего товарища, нежели тратить лишние часы, нервы и силы на изобретение велосипеда.

8. "Скопирую код из документации/StackOverFlow, главное чтобы работал, а как именно работает, разбираться не обязательно".
Правильный путь: осознанность. ОСОЗНАННОСТЬ. Всегда понимать, что и зачем ты делаешь. Лучше потратить больше времени на то, чтобы разобраться с кусочком кода, чем потом очень долго разбираться, что произошло, если в нём возникнет ошибка и окажется, что на этом "ошибочном" коде держится много другого функционала.

9. "Если есть документация по выбранной технологии и всё понятно, можно не общаться в сообществе".
Правильный путь: общение в сообществе - не только способ задать вопрос и обменяться опытом, но и психологическая разрядка и понимание, что другие идут похожим путем. Помогает предотвратить синдром самозванца и, как следствие, выгорание. От других коллег можно почерпнуть неожиданные классные идеи и просто вдохновение.

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

Заметка называется "Грабли", потому что если вовремя не предотвратить эти ошибки, есть шанс наступать на них снова, и снова, и снова...

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

Про итоги года (и немного невеселых признаний)

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

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

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

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

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

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

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

В следующем году меня ожидают новые обязанности, проект с автоматизацией (страшно до жути, но я уверена, что нет такой задачи, которая не решается упорным трудом) и, что важнее, работа с людьми. Теперь мне предстоит не только держать себя в руках, но и следить за тем, чтобы у нескольких людей рядом тоже всё было хорошо и ровно. Задача непростая и совершенно мне новая, но я рада, что сама пережила описанный выше опыт: надеюсь, я смогу вовремя распознать и предотвратить выгорание у тех, с кем работаю, и приложу все усилия, чтобы сделать их карьерный путь приятным и вдохновляющим.

С наступающим! И пусть в 2019 году всё вокруг вас будет честно, искренне и наполнено любовью к себе и своему занятию.

И багов поменьше, конечно же! 🐞

Немного приятностей: меня приняли в роли докладчицы на SQA days 25, конференцию, которая будет проходить 31 мая и 1 июня в Питере.
Начинаем подготовку, чтобы не посрамить прекрасное имя компании и зарядить аудиторию настроением на то, что всё получится 💪🏻

О небезразличии

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

Один из вопросов, который понравился мне и заставил задуматься, звучал так: "Как вы считаете, каковы ключи к успеху в работе тестировщика?".

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

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

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

Я ответила: "QA-engineer should care" и пояснила, что лично мне бы хотелось искренне любить свой продукт - вот и всё, что нужно: тогда и средства организовать работу найдутся, и проверки не будут дежурными и, главное, мотивация будет неугасимая и искренняя.

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

Отличной всем недели. И увлекательных, интересных задач ☺️

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

Как обычно, я рада обсуждению вопроса в ЛС. Если вам есть, что добавить, оспорить или уточнить - велкам!

Итак...

...Чем тестирование отличается от QA? И нужно ли искать отличие?

Чтобы ответить на этот вопрос, надо определить, что мы понимаем под каждым из этих процессов.

Силлабус ISTQB говорит на этот счет следующее:

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

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

Wikipedia дополняет это определение термином QA:

Обеспечение качества (англ. Quality Assurance, QA) — это процесс или результат формирования требуемых свойств и характеристик продукции по мере её создания, а также — поддержание этих характеристик при хранении, транспортировании и эксплуатации продукции.

Таким образом, из двух определений выше можно сделать выводы:

1. Тестирование - часть процесса обеспечения качества (Quality Assurance, QA). Тестирование позволяет определить уровень качества продукта(ов) или функциональности, поставляемой клиентам.
2. Обеспечение качества - задача не только тестировщиков. Вся команда должна вносить свой вклад в обеспечение высокого уровня качества поставляемых продуктов и услуг.

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

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

Как тестировщик может улучшить качество продукта и помочь наладить процесс QA в команде?
Я не могу достоверно ответить на этот вопрос. Скорее всего, новые и новые ответы на него я буду искать в течение жизни :) Однако сейчас у меня есть ряд своих best practices, проверенных опытом, поэтому, пожалуй, сказать о них пару слов - неплохое начало этого пути.

Итак, как тестировщик я могу...

1. Контролировать качество продукта, начиная с ранних этапов: в первую очередь, проверять требования/спецификации на непротиворечивость и полноту.

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

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

4. Планировать работы по тестированию на этапе согласования требований.

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

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

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

8. Помогать другим членам команды разделить ответственность за качество: объяснить разработчикам простые методики тестирования, поделиться своими чек-листами с командой, объяснить, насколько важна критичная для работы продукта фича и т.д.

Как остальные члены команды могут улучшить качество продукта?
Вопрос, так же, непростой. Вот мои докадки о возможных ответах на него:

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

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