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

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

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

#онбординг #soft_skillz #личное

Песочница для игры с окнами браузера, алертами и т.д.

#взакладки
Я принесла очередную площадку для практики автоматизации :)
https://www.toolsqa.com/automation-practice-switch-windows/

Что там можно потрогать:
🔹 Новое окно браузера
🔹 Новую вкладку браузера
🔹 Алерт
🔹 Алерт с задержкой в несколько секунд
🔹 Элементы с разными ID и локаторами
И многое другое.

А ещё на том же сайте есть туториалы на английском языке, но я их не успела почитать, так что за качество ручаться не могу :D

Идея для стартапа: стендап на IT-тематику под названием "Хахатон" 😅

Провели сегодня второе мероприятие Women in Tech в России @womenintechrus. Гоу-гоу гёрлз!

Я уже упоминала, что в последнее время упоролась по Cypress. Протестировала в Firefox — огонь. Кажется, пора плотно садиться на JS :D

Cypress 4.0

Привет, на прошлой неделе вышел релиз Cypress 4.0. Основная новость - поддержка Firefox и Edge😮. Теперь в мире JS есть куча библиотек, которые позволяют делать автоматизированное тестирование легко и эффективно.

https://cypress.io/blog/2020/02/06/introducing-firefox-and-edge-support-in-cypress-4-0/?utm_content=115505380&utm_medium=social&utm_source=twitter&hss_channel=tw-2774638535

Git command explorer

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

https://gitexplorer.com/

“Every day it gets a little easier… But you gotta do it every day — that's the hard part. But it does get easier.” (с)

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

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

Маленькие шаги всегда ведут к результатам, надо это набить себе на лбу и каждое утро вспоминать, смотрясь в зеркале :)

​​Comma в CSS локаторах

Привет! Вот и прошли две самые большие QA конференции этого сезона. Из трендов можно отметить набирающий популярность puppeteer и JavaScript. Я для себя неожиданно открыл одну новую вещь. Оказывается, в css селекторах можно писать условие OR. Для этого достаточно разделить два локатора с помощью запятой. Не знал, что оно будет работать в случае с Selenium. Топовая фича, которая будет полезна, если у вас адаптивная верстка или вы хотите сделать тест более стабильным и указать основной и запасной локаторы.

RailsGirls в Санкт-Петербурге

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

Важно, что мероприятие рассчитано на неопытных слушательниц. Это значит, что вам совершенно необязательно иметь опыт программирования, чтобы записаться и посетить RailsGirls.

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

RailsGirls, как и другие аналогичные инициативы, проводится бесплатно.

https://vk.com/wall-132605355_880

#intern

Есть такие популярные каталоги ссылок на облачные сервисы полезные для разработки ПО: Tools of the Trade и free-for.dev. Многие из перечисленных сервисов предоставляют бесплатные тарифы для разработчиков, но есть один минус - там почти нет сервисов для тестирования. Статья Testing-As-A-Service хорошо дополняет эти два каталога ссылками на полезные сервисы для тестирования сайтов, оценки покрытия кода, управления тесткейсами, анализа результатов тестирования производительности и другие. Вообщем все тем, что сопутствует качественной разработке ПО.

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

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

РЕБЯТА, ДАВАЙТЕ УЧИТЬ ТЕОРИЮ.

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

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

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

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

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

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

2. Возможность говорить на одном языке дает нам шанс обосновать выбранные решения и примененные подходы.

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

4. Знание теоретических основ позволяет структурировать собственные навыки и трезво их оценить: что этот вид деятельности предполагает, насколько я могу это сделать, нужно ли мне "докачать" вот именно этот скилл.

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

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

Приходите 21 марта на конференцию WTM International Women Day!

В 15.25 расскажу доклад про тестирование на основе моделей, а потом буду рада получить фидбек и просто пообщаться, — давно не выбиралась на профессиональные мероприятия.

Участие бесплатное!

UPD: мероприятие отменили из-за мер предосторожности в связи с пандемией. Это, кстати, отличная аналогия на работу QA: лучше предотвратить опасность, чем разгребать последствия.

Всем здоровья!

О переменах

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

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

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

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

https://youtu.be/sx246jqwAeo

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

Особенно нежно люблю атомарный перебор. Как по мне, эта техника почти универсальна :)

А ещё теперь моя мордашка появилась на сайте https://women-in-tech.org/ru/: я Community leader по СПб! ❤️ Go go girls :)

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

https://teletype.in/@qa_nastasiya/TB5O1GczB

Прощальное.

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

https://teletype.in/@qa_nastasiya/q1z9L1VJ-

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

Тестирование является довольно легкой точкой для входа в айти.
Помимо миллиона курсов, обещающих сверхзарплаты через 2 недели, а также большого количества соискателей, прочитавших одного только Савина, это рождает ещё и устойчивое мнение что QA - это просто.
Действительно, сформировать какой-то необходимый минимум для тестирования проекта - довольно объемная, но не такая уж и сложная, задача.
Только QA - это немножечко больше, чем тесты на API, девять с половиной ручек селениума и тестраннер прикрученный к CI.
Качество стоит дорого, а его обеспечение требует мозгов, скиллов и способности решать задачи, а не просто пилить покрытие тестами ради покрытия тестами.
Сделать тесты эффективными, быстрыми, масштабируемыми и прозрачными для всех, чью работу они затрагивают - сложно.
Сформировать такой набор тестов и тестовых данных, чтобы тестирование действительно говорило об уровне качества системы, а не просто показывало красивый список зеленых тестов, пока пользователи и бизнес продолжают страдать - сложнее, чем научиться применять граничные значения и классы эквивалентности.
Добиться того, чтобы на каждое падение не приходилось проводить длительный root cause analysis - тонна работы, как со стороны самих тестов, так и со стороны тестируемой системы.
Если QA-инженер не обладает достаточной экспертизой, чтобы решить как это должно быть сделано, то все эти задачи так и останутся нерешенными.
Всё перечисленное выше - то, что на поверхности.
Помимо этого есть куча направлений работы и множество задач, ограниченных только вашими скиллами, желанием и способностью объяснить окружающим, и себе, зачем это нужно.

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

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

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

Ну а тестировать любимую соц. сеть так вообще кайф.

https://teletype.in/@qa_nastasiya/0Kbk9K-vj