Home

Автор: Боб Салмон (Bob Salmon)
Оригинал статьи
Перевод: Ольга Алифанова

Эта статья - ответ на челлендж Министерства тестирования “Как мы хакнули инструмент, чтобы заставить его работать на нас”. Сначала я поговорю об инструментах в целом, а затем приведу пару примеров не особенно стандартного использования инструментов. Я уже писал немного об инструментах, но не в этом контексте. Использование инструментов интересным способом или их комбинирование часто встречается в физическом мире - неудивительно, что мы переносим эту идею и на ПО тоже. Пила и стусло, молоток и долото - инструменты улучшают друг друга.

Оригинальная публикация

Привет! Я Линар Юнусов, тестировщик из мобильной команды СберМаркета. Если вы не первый день в тестировании, то знаете про существование нефункциональных проверок и как они могут поломать жизнь приложение. В этой статье расскажу про то, к каким проверкам мы пришли в СберМаркете. Сначала поговорим о довольно популярных кейсах, потом о более специфических: попадём на экраны настройки в режиме разработчика, попробуем поработать с клавиатурой и вводом эмоджи , а ещё узнаем скорость загрузки нашего приложения на разных платформах. Поехали!

Автор: Луиза Гиббс (Louise Gibbs)
Оригинал статьи
Перевод: Ольга Алифанова

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

Увидев тему 5 дня челленджа “30 дней инструментов”, я сразу же подумала о записи и воспроизведении. Ранее я писала и говорила, что поддерживаю инструменты записи и воспроизведения для автоматизации, и все еще стою на этой позиции. Несмотря на то, что я несколько лет не работала с фреймворком тест-автоматизации, включающим запись и воспроизведение.

Автор: Чистяков Вадим
Оригинальная публикация

Фича = задача и далее по тексту :-)

Что есть задача для разработчика?  

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

После разработки

Исходя из своего опыта, могу заметить, что следующим после тестировщиков в процесс релиза вступает Release Manager или даже целая Release-Team. Он берет на себя ответственность довести задачу до клиента. Продакт/проджект-менеджеры и другие участники от бизнеса, скорее всего, имеют представление о том, что происходит с нашей новенькой и очень полезной (нет) фичой. Они также ведут таблицы, получают информацию от аналитиков и на основе этих данных могут принимать решение: "А что дальше?" 

Автор: Андреа Иенсен (Andrea Jensen)
Оригинал статьи
Перевод: Ольга Алифанова

Хочу рассказать вам о крошечном инструменте, который всех спас.

Когда-то я тестировала одну из проблем, чьи первопричины просто не даются в руки. Конечно, ПО работало прекрасно на машине разработчика, но не делало этого на моем тестовом ноутбуке. Наконец после часов дебага, ряда звонков и балансирования на грани отчаяния… мы нашли первопричину!

Оригинальная публикация

Всем привет! Меня зовут Иван Шевелев и я Head of QA Automation в Skyeng. Я регулярно занимаюсь обучением Manual QA и менторством начинающих QA Automation (далее – QAA) и часто слышу от падаванов вопрос: «А как же мне, собственно, стать QAA?»

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

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

Однажды приходит осознание, что нужно расти. Но куда?

• Разработка – сложно. Глядя на разработчиков в компании, понимаешь, что вы находитесь на совершенно разных уровнях.

• Инфраструктура – сложно. Инфра — это что-то про администрирование, DevOps и вот это вот всё.

• Team Lead/Head of QA – рановато. Опыта в менеджменте нет, а набираться его почти негде. Разве что в кросс-проектных задачах.

• SDET – Понять бы для начала, чем он занимается…

• Автоматизация тестирования — Хм… Программировать особо уметь не надо — пишешь тестики, лутаешь х2 ЗП. Сказка!

Но сказка ли?

Автор: Пол Гриззаффи (Paul Grizzaffi)
Оригинал статьи
Перевод: Ольга Алифанова

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

Автор: Алия Токарева, ICL Services
Оригинальная публикация

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

Время идет, сроки становятся все короче и короче, а тестировщику еще не предоставили возможности «познакомиться» с программой. Конечно, тестер задастся вопросом: «А как я успею изучить ПО и уж тем более протестировать, если у меня нет доступа к нему?». Здесь я вам отвечу, что изучить и протестировать – можно. Даже без входа в приложение.

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

1. Программное решение уже готово, но требуются значительные изменения или небольшие доработки;

2. Есть прямой контакт с заказчиком или с лицом, который имеет доступ к приложению.

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

«Присаживайтесь поудобнее, начинаем».