1. Лена Нюстрём. Меняйте свое мнение о некоторых вещах
Раньше я обожала водопадные проекты. Мне казалось, что я могу хорошо тестировать только в том случае, если могу уверенно планировать. Один ужасный проект в 2014 году заставил меня попробовать что-то другое, и результаты меня поразили. Думаю, Agile был не так уж плох, в конце концов.
Я не доверяла разработчикам тестирование. Несколько удивительных людей показали мне, насколько более сильной становишься, когда работаешь в команде. И, наверное, я улучшила свои мягкие навыки, и перестала относиться к разработчикам так, что они меня отталкивали, поэтому сегодня я меньше давлю, а больше предлагаю, и меньше говорю им об их глупых ошибках.
Я думала, что тестирование на проде — это бред. Я на собственном опыте убедилась, насколько удивительным может быть отказ от контроля и доверие к тому, что кто-то заметит, расставит приоритеты и исправит баги, когда что-то пойдет не так.
Возможность развертывания много раз в день даже в немикросервисной среде — это не невозможно, и это чертовски круто.
Раньше мне казалось, что легко убедить людей с помощью фактов. Но это не так. Эмоции намного сильнее. Невозможно убедить руководство в приоритетности крупных проектов/улучшений. Это не так. Вам просто нужно понять, что их мотивирует.
2. Проблемы, с которыми вы можете столкнуться в качестве тестировщика — Аарон Ходдер
Первая — это постоянное обучение, которое вы должны пройти в качестве тестировщика. В каждом проекте есть что-то уникальное, что требует от вас быстрого повышения квалификации. Необходимость быстро узнать о новом клиенте, о том, что для него важно, что он ценит, о проблеме, которую должен решить этот продукт, о техническом решении еще до того, как вы подумаете о том, как вы будете его тестировать.
Вторая проблема, самая сложная — донести до клиента, что мой способ тестирования может отличаться от того, что он видел, как тестировали другие. Может возникнуть сопротивление, когда вы предположите, что написание тестов по методике TDD может быть не лучшим использованием вашего времени, и им легко выместить свое недовольство на тех, кто просит тестовые сценарии, а не на тех, кто зарабатывает деньги, распространяя басни, будто тестирование — это просто написание и выполнение тестовых сценариев.
3. Малоизвестные полезные расширения для браузеров — Аджай Баламуругадас
- Wordtune помогает перефразировать текст. Используйте его при составлении электронных писем, отчетов о тестировании, любой документации.
- One-Tab помогает делиться многими ссылками одновременно, а также группировать их. Попробуйте и вы.
- Также есть и обычные друзья, такие как: GoFullPage, Dualless, Link Klipper
Больше на Ultimate Productivity Toolkit.
Интервью с Аджаем Баламуругадасом
4. Каллум Акехерст-Райан (Callum Akehurst-Ryan) — Когда проводить исследовательское тестирование
Тест-кейсы и скрипты нужны, когда мы хотим подтвердить то, что уже знаем.
Поэтому они отлично подходят для регрессии или в среде, где все разрабатывается по спецификации. Как правило, в моих проектах они автоматизируются, поэтому тестовые сценарии — отличный кандидат на автоматизацию.
Затем мы используем запланированное и структурированное исследование, чтобы исследовать то, о чем мы не знаем.
Это очень полезно в периоды неопределенности, когда вещи не очень четко определены, или когда мы использовали пользовательские истории для определения того, что, но не того, как.
Мы исследуем продукт, чтобы выяснить, как можно что-то сделать, а затем воспроизвести истории о том, как это работает.
Исследовательское тестирование — это то, что мы всегда можем использовать, но мы, возможно, не всегда будем его использовать. Это то, с чем некоторые компании, команды и тестировщики не знакомы или не чувствуют себя комфортно, и вы должны уметь отстаивать его использование в компании.
Я писал о том, как рассказать разработчикам об исследовательском тестировании, и есть отличные ресурсы, если вы захотите сделать то же самое. Однако если вы или ваша команда/организация не хотите продвигать этот стиль тестирования, то он может вам не подойти.
Я бы рекомендовал попробовать: это хороший скилл, который нужно иметь, он помогает наладить отношения с командой, и им весело заниматься.
Интервью с Каллумом Акехерст-Райаном
5. Побороть неуверенность — Элизабет Загроба
Вы не должны буквально говорить «Я не знаю». Мой совет таков: Показывайте свою работу. Заметив, что вы в чем-то не уверены, найдите какой-то дополнительный ориентир, или проведите дополнительное исследовательское тестирование, и поделитесь полученной информацией, чтобы ваши коллеги могли принять участие в принятии решений.
Это разница между «204 ответа не имеют тела ответа» и «здесь на httpstatuses.com написано, что 204 ответа не имеют тела ответа». Это разница между сообщением «Я закончил тестирование, можем релизить» и «Я посмотрел ветку Джона в тестовом окружении с пользователем admin.» на стендапе.
Исследуя чуть более глубоко, ваша команда может спросить вас, «Была ли ветка Джона нормальной, должны ли мы посмотреть на переделанную версию в development-ветке?». Или «Пробовали ли вы заходить под обычным пользователем в дополнение к пользователю-администратору?»
Мне также интересно, существует ли человек, которому трудно сказать «я не знаю», в команде, где возможно (а еще лучше — поощряется) признание сомнений. Если их команда не способствует такому мышлению, я бы начала интересоваться, почему так происходит.
6. Пример ошибочного представления о тестировании — Ким Энгель
Самое большое заблуждение, которое я слышу о тестировании, — что оно скучное.
Если тестирование кажется вам скучным, значит, вы выполняете его неправильно. Попробуйте изучить новый подход; узнайте больше о своем продукте; посмотрите конкурирующие продукты; пообщайтесь с клиентами на онлайн-форумах; почитайте бесплатный онлайн-журнал о тестировании; найдите или организуйте встречу тестировщиков в своем регионе; читайте блоги о тестировании; общайтесь с коллегами в Twitter.
Мне жаль говорить, я встречала многих тестировщиков, которые не делают ничего из этого, и они жалуются мне, что тестирование это скучно.
7. Начало тестирования доступности — Лавина Рамчандани
Я начала заниматься тестированием доступности в очень странной ситуации: меня срочно вызвали на митинг и спросили, провели ли мы тестирование доступности после запуска банковского приложения! Я была в замешательстве и начала думать, что же такое тестирование доступности.
Этот опыт подтолкнул меня к изучению всего этого и к тому, чтобы, где бы я ни была, я продолжала делиться этими знаниями. Однажды мне сказали, что нам не стоит заниматься доступностью, поскольку мы реализуем проект B2B, а не B2C. Это меня очень потрясло, но я начала двигаться вперед, невзирая на то, что мне говорили. Вы столкнетесь с этим на каком-то этапе своей жизни, если вы видите, что кому-то не хватает знаний, идите вперед и поделитесь этими знаниями, и вы спасете компанию от убытков.
Ресурсы, которые я бы рекомендовала:
- Изучить стандарты WCAG
- Попробовать плагины для Chrome (также Axe, Developer Tools, Lighthouse)
- Изучите WAVE, Arc Toolkit и программы чтения с экрана
- Следите за лидерами комьюнити, которые являются экспертами по доступности
- Книга: The Design of Everyday Things, Don Norman
- Начните тестировать свои фронтенд-приложения!
Сложным моментом в обеспечении доступности для меня было понимание того, что означают те или иные вещи, особенно такие ошибки, как ARIA, ошибки форматирования страниц, которые были простыми для фронтенд-разработчика. Тогда я начала работать в паре с разработчиками и учиться у них. Как я всегда говорю: «Пара — это забота».
8. Самое большое заблуждение Agile-тестирования — Лиза Криспин
Я часто вижу, что в agile-командах есть один или два тестировщика, но они по-прежнему практикуют мини-водопад. Они передают все на проверку тестировщику (тестировщикам). Они не используют подход «вся команда участвует», фокусируются не на предотвращении багов, а на их обнаружении. Процессы не масштабируются, один или два тестировщика не могут справиться с работой трех, четырех, десяти кодеров. Менеджеры, которые часто не разбираются в тестировании, думают, что им просто нужно нанять больше тестировщиков, а это обычно не является решением проблем с качеством.
Меня до сих пор часто спрашивают: «Каково правильное соотношение кодеров и тестировщиков?»
На этот вопрос нет правильного ответа.
Я работала в высокоэффективных agile-командах, где тестировщиков требовалось столько же или даже больше, чем кодеров, даже если команда практиковала TDD, ATDD и все участвовали в тестировании. Код писать было несложно, но бизнес-сфера была довольно рискованной — сбои на проде могли привести к потере денег как клиентов, так и компании, или нарушению законов, что привело бы к полному краху бизнеса. Мы должны были быть уверены, что продукт ведет себя идеально.
Я работала над продуктом — инструментом для отслеживания проектов — где на 30 программистов вполне можно было иметь двух или трех тестировщиков, потому что программисты тоже использовали свой продукт и хорошо его понимали, риск был невелик (неудобно, когда ваш онлайн-инструмент для отслеживания проектов падает, но обычно это не приводит к большим финансовым потерям или гибели людей), а команда была экспертом в TDD, парном программировании, исследовательском тестировании, непрерывной интеграции и автоматизации.
Как тестировщики, мы выступали скорее в роли консультантов и тренеров по тестированию, помогая всем желающим овладеть необходимыми навыками тестирования.
9. Отправляясь в путешествие — Лизи Хок
Мой тур по тестированию стал еще одним испытанием для меня: мне предстояло общаться с разными людьми на разные темы. Я очень понимаю, как трудно подходить к незнакомым людям и отправляться в такой тур, особенно публично. Что ж, это должно было быть страшно и вывести меня из зоны комфорта, чтобы я могла расти вместе с этим!
Что мне действительно помогло, так это использовать уже построенные отношения и начать с них. Мои самые первые тур-сессии проходили с людьми, с которыми я познакомилась на конференциях, и с коллегами — так я могла получить опыт подготовки к этим сессиям, их проведения и последующего контроля, чтобы извлечь максимум пользы для всех. Чем больше сессий я проводила, тем увереннее становилась, и тем больше это позволяло мне приглашать других людей присоединиться ко мне.
В какой-то момент мне уже не нужно было спрашивать себя, незнакомцы обращались ко мне напрямую или просто заказывали сессию! Это облегчило процесс налаживания связей, но в то же время принесло немало трудностей, которые помогли нам встать на правильный путь.
Зачем отправляться в такое путешествие? Что бы ни заставило вас отправиться, это должно соответствовать вашим личным целям. Для меня это был тот факт, что я всегда была одиноким тестировщиком или самым опытным — и я была очень неуверена в своих навыках тестирования. Мне хотелось увидеть, как другие подходят к решению задач тестирования, познакомиться с различными специальностями, такими как тестирование безопасности или доступности, и т. д.
Я получила гораздо больше знаний, навыков, инструментов, а также множество замечательных человеческих связей. Участие в этих сессиях в течение десяти месяцев было одним из лучших занятий в моей карьере тестировщика и открыло передо мной множество возможностей в дальнейшем».
10. Сильный стиль работы в паре — Маарет Пюхяярви
Сильный стиль работы в паре — это подход к работе в паре, основанный на идее, что мы можем делать так, чтобы пара была более вовлечена в общую работу, выбрав правильный способ разделения задач в паре. В парах с сильным стилем идея о том, что делать, начинается с того, что человек с клавиатурой озвучивает идею. Так что если у вас есть идея, вы говорите: «Бери клавиатуру». В традиционной паре все наоборот: вы передаете клавиатуру тому, у кого есть идея.
Долгие годы я работала в паре в традиционном стиле и чувствовала себя особенно неуютно с людьми, с которыми у меня не было прочных отношений, или когда наши навыки были разными (программирование против тестирования), или мы находились на значительно разных уровнях мастерства. Сильный стиль распределяет работу и позволяет человеку за клавиатурой заниматься не только рецензированием. Кроме того, он решает проблему того, как трудно разговаривать, пока пишешь, не заставляя вас нести обе обязанности в паре. Правила помогают работать в паре с новыми людьми, и те же правила позволяют вырасти из пары в ансамбль — более двух человек над общей задачей.
Новичку в тестировании или программировании сложно работать в паре любым другим способом. Сопряжение важно для новичков, но для эффективного обучения им нужен контроль над темпом, их руки (и их рабочий лэптоп) на клавиатуре. Новички — да и состоявшиеся люди тоже — не знают, как попросить о том, чего они не знают, и что упускают. Работа в паре открывает много неизвестного в инструментах, техниках, подходах и мышлении. Любой стиль работы в паре не подойдет, если люди не хотят работать в паре. И при составлении пар я лично отдаю предпочтение сильному стилю.
