Home

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

Всем привет! Меня зовут Фефилов Александр, я работаю в QA с 2017 года. По большей части это были компании, которые занимались аутсорсингом, но затем я присоединился к SM Lab.

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

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

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

• что делать, если ваш заказчик живёт в парадигме «Я плачу деньги, а ты просто делаешь всё, что я говорю»

• как решать процессные задачи

• как находить продуктовые проблемы

• кто такой QA-эксперт и как им стать

• полезная методика, которая может пригодиться вам в работе.

Итак, начнём по порядку.

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Наша главная задача как тестировщиков – это выявить реальный статус продукта. Помните – все остальные участники проекта сконцентрированы на Успехе, Предотвращении Проблем, Встраивании Качества, Добавлении Ценности, и всякое такое. Все это здорово, ничего плохого тут нет. Но есть нюанс.

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

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

Меня зовут Антон Морозов, я инженер по тестированию в Яндекс 360. Я работаю над мобильным Яндекс Диском — это проект с тысячами тест-кейсов, который развивается уже тринадцатый год. 

Погружение в продукт и новую команду — непростая задача для новичка, но нам удалось выстроить безболезненную адаптацию (отток за 4 года составил 0%). В статье поделюсь практиками в команде QA, которые помогли нам за последние четыре года успешно адаптировать новичков.

Небольшие дисклеймеры перед прочтением статьи

1. Статья — наш личный опыт, который сработал конкретно в нашей команде. Эти практики не волшебная таблетка, а то, что работает конкретно у нас.

2. У нас есть общекорпоративный процесс адаптации, погружение в культуру компании, отдельные курсы для новичков. Команда Яндекс 360 делает собственные мероприятия для знакомства новичков, а руководитель готовит план адаптации. В статье речь пойдёт о более прикладных советах, которые помогут быстрее погрузиться в продукт.

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В этой статье я хочу ответить на вопрос, заданный мне в LinkedIn Полом Сименом (Paul Seaman). Он спросил, что я думаю о документировании автоматизированных тест-кейсов как способе продемонстрировать, что автоматизация вообще делает.

Краткий ответ: я не определился.

Это, конечно, не очень-то полезный ответ, да и статья вышла бы странно короткой – постараюсь развить свою мысль.

Автор: Ольга Назина (Киселёва)

Очень насущный вопрос для многих — можно ли найти работу в тестировании сразу после курсов? Да! (сказал автор курсов, хе-хе-хе)

Я вам больше скажу — можно и БЕЗ курсов устроиться ????. Более того, грамотные самоучки очень ценятся! Но для такого эффекта надо пахать =))

Об этом и поговорим в статье:

• как устроиться без курсов — чем запоминаются самоучки (расскажу истории из своей практики), 

• зачем тогда вообще курсы, что они дают и как помогают трудоустройству,

• вспомним и про ситуацию "наоборот": курсы есть, знаний нет (вот и не берут!),

• подведем итоги
  

Содержание

1. Как устроиться без курсов — чем запоминаются самоучки

2. Что дают курсы

3. Ситуация наоборот: курсы есть, знаний нет

4. Ситуация: знания есть, работы нет

5. План по эффективному обучению

6. Итого

Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

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

Пост написан Стефаном Шмидтом. Он говорит, что у него за плечами более сорока лет разработки. У меня их столько же (1 января 2024 стукнул 41 год, годовщина моего первого рабочего дня в Dale Disharoon, Inc. Моим первым проектом было создание игры Hey Diddle Diddle для Apple II и С64). Возможно, разница между нами в том, что я всю свою карьеру занимался именно тестированием, а он говорит, что «пишет тесты» в ходе разработки. Между написанием тестов, предполагаю, он пишет код продукта, а это не тестирование. То есть он в лучшем случае поверхностно знаком с нашей отраслью.

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

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

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

Собеседник: «Я хочу научиться делать это хорошо!» (это здорово!)

Я: «Что вы делали ранее, что работало, что нет?»

Собеседник: «Мы пробовали внедрять это раньше, но получилась ерунда», или «Мы наняли экспертов, чтобы они это сделали, но получилась ерунда» (бывает довольно часто).

Я: «Как я могу помочь вам стать лучше?»

Собеседник: «Нам нужно изучить лучшие практики в области …»

Я (в реальности): «Я могу вас научить/рассказать вам о распространенных практиках, но…»

Я (про себя): «Пожалуйста, нет, только не это!»

Привет! Меня зовут Евгений Константинов. Я занимаюсь разработкой инструментов автоматического тестирования в Яндексе. В этой статье хочу рассказать про историю создания инструмента Testplane, который предназначен для тестирования пользовательских сценариев во фронтенде и теперь доступен в опенсорсе.

Testplane поможет вам:

• протестировать разные сценарии в любом браузере; 

• проверить вёрстку с помощью скриншотного тестирования; 

• выполнить тестирование ваших React-компонентов;

• запустить клиентские unit-тесты в контексте браузера.