Прекрасная статья на Хабре, не поделиться которой было бы грешновато: 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, давать понятные названия локаторам и т.д.

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

This. 👇🏼

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

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

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

Но чем дальше, тем проще.

О формуле лучшего проекта

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

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

Кстати, на собеседовании один из вопросов был примерно о том же: что нужно, чтобы вы чувствовали себя комфортно при работе над проектом? Что заставит вас с радостью порсыпаться каждое утро и идти на работу с нетерпением?

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

Из внешних источников я узнала, что часто причиной потери интереса становятся либо непосильные задачи и завышенные ожидания от себя и от других, либо некомфортные условия труда - например, трудно дающееся общение в команде, пассивная агрессия, плохая коммуникация, либо отсутствие видимого результата. Все три пункта я у себя смело вычеркнула: ничего сверхъестественного от меня не ждут, я тоже вполне трезво оцениваю свои возможности; команда у меня замечательная (искренне желаю, чтобы всем удалось хоть раз поработать в таком коллективе, как у нас в Noveo), результат совершенно точно виден: и мой, и общий. Где же тогда лужа, Робин?

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

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

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

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

Детективные истории

Сидеть и выверять точные условия воспроизведения "мигающего" бага, который воспроизводится через раз, чтобы найти их в итоге И ЗАВОСПРОИЗВОДИТЬ ЕГО РАЗ 10 ПОДРЯД - это, пожалуй, одна из самых кайфовых деталей моей работы!!!

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

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

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

Чувствую себя детективом, который по ниточке распутывал-распутывал сложное дело, и распутал. Как же меня прёт от этой работы! 🤩

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

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

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

Минутка ностальгии :)

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

Помню, это был очень солнечный апрель, диплом был уже написан, стажировка PM подходила к концу, и я срочно искала, куда бы вложить свои силы и энтузиазм. В тот момент я уже загорелась тестированием и взахлеб штудировала http://www.protesting.ru/, книгу Савина, книгу Куликова (даже конспектировала в тетрадку и сама себе тесты составляла, простигосподе) и все разделы Хабра по тегу #тестирование. И вот — о счастье! — в Noveo открыт набор на летнюю стажировку по новому направлению: QA.

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

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

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

Кстати, если интересно подробнее о стажировках и прочем — ищите тут https://university.noveogroup.ru. Это на правах не рекламы, но искренней любви к месту, где начался и до сих пор продолжается мой профессиональный путь 🧡