Комментарии 17
Хорошая статья, причём не только для самих тестировщиков, но и для их коллег, которые не понимают что делают эти QA )
В начале идёт важная мысль, что у QA-отдела есть цель "коммерческая - повышение лояльности к компании и приложению, так как любой обнаруженный дефект негативно влияет на доверие пользователей. От сюда следует, что QA влияет на продукт, а не просто тестирует что сказали :)". Это по смыслу тесно переплетается с понятием валидации из 30 пункта. То есть QA должны получается проводить аналитические исследования статистики роста лояльности (продаж) продукта и/или прибыли? Но ведь это уже задача отделов маркетинга (продаж) проводить исследование роста рынка, продаж, и т.п.? Или я неверно понял посыл?
Когда то в прошлой жизни я был qa тимлидом (точнее будет сказать мамкиным тимлидом, т.к. стал им меньше чем за три года с начала работы сразу после института).
Что я спрашивал у людей:
1) В каком ВУЗе вы учились?
2) Расскажите о своей дипломной работе.
3) Переведите этот отрывок текста с английского на русский.
Этих вопросов мне было достаточно, чтобы понять, насколько хорошо человек будет работать тестером. А ваши вопросы помогают понять насколько хорошо человек подготовился к собеседованию, а не то, как он будет работать.
Вот-вот. В статье большинство вопросов на зубрёжку, а не на умение думать, тестировать, грамотно говорить/писать.
Поддерживаю! Ни разу мне не удалось через знание определений и типов тестирования, понять: на сколько кандидат усидчив и внимателен к деталям, исполнителен, ответственный, на сколько он сможет вписаться в команду, в режим работы и темп, уровень его коммуникации и дружелюбие. Бывало что зная все определения, люди уходили сами черёз месяц со словами 'я думал будет всё иначе'. Сейчас мои собесы это во первых и в основном вопросы про хобби кандидата, его успехи и неудачи на прошлых проектах, его описание сложных ситуаций, где я вижу всё он солей а в чем слаб. Уровень его открытости, желание расти и изучать новое постоянно, и в каком количестве. Ра спрашиваю как у него с планированием, на сколько он приучен к этому, и на сколько детально и далеко может распланировать. Как часто его планы нарушаются и по какой причине, тоже очень важно. Интересно как кандидат для себя понимает тестирование, что именно он видит главное и второстепенное. И точно я всегда прошу не рассказывать мне определений и инета от очередных инфоциган. Ещё интересуюсь что откровенно не нравится на текущем проекте и от чего он точно хочет уйти и не встретить снова. А что действительно нравится и он ищет в других командах. Много раз мне удавалось найти замотивированного с горящими глазами бойца и за год из него сделать хорошего спеца, на которого могу положиться. Уверенна,что за час собеседования по определениях и структурах никак не выяснить как человек будет работать ина сколько тщательно и глубоко погружаться.
Статья ещё и поможет подойти к просмотру своего продукта в этом разрезе - в разрезе пользы некоторого тестирования продукта.
Спасибо. Структурированно, несложно.
Три основных аспекта безопасности:
общепринятое здесь:
https://ru.wikipedia.org/wiki/Информационная_безопасность#Ключевые_принципы
а у автора что-то свое.
Как попасть в компанию, где всё это применяется? Маленьким компаниям плевать на качество
Как попасть в компанию, где всё это применяется?
Попасть в крупную банковскую структуру, которая зарегулирована до чертиков и все требования выполняет.
Как опция - попасть в ад, т.к. при соблюдении всех требований разработка становится адской.
Именно поэтому зарегулированным структурам проще поглотить готовый продукт, чем разработать самим. Личный опыт.
1. Что такое тестирование?
Сравнение ожидаемого результата с фактическим результатом ПО. Тестирование это не поиск багов!
Своими словами: тестирование - это процесс сопоставления спецификаций продукта с его финальным результатом.
Ожидаемого кем? Заказчиком, постановщиком задачи, проектировщиком, разработчиком или пользователем? И сколь часто у тестировщика бывает под рукой полная и чёткая спецификация ПО?
29. Приведите примеры серьезного, но не приоритетного бага.
Более приземленный пример: интернет-магазин прислал красное платье вместо бордового.
Откуда известно, что это не приоритетный баг? Как можно отвечать на этот вопрос, не имея списка приоритетов, данного тестировщику начальством?
Как бы вы ответили на эти вопросы? Интересно послушать Вас.
В нормальной компании - ожидаемого по спецификации. Если вылазит что-то чего не описано в спеке - то спека допиливается. То есть в идеале всё ожидаемое поведение должно быть специфицировано. Ну это имхо, конечно, из опыта работы в достаточно крупной ИТ компании.
Насчет типов тестов, сродни Security Testing я работал с penetration testing, когда основная задача с использованием разных подходов (XSS, SQL Injection, etc.) пытаются проникнуть в приложение.
Не уверен что это задача для Juniors, но для общего развития знать полезно и джунам.
Какая же это скукотища, чёрт возьми... Неужели находятся те, кому нравится подобная работа?
Что-то наблюддается некоторая мешанина терминов. Мне вот всегда было непонятно это стремление ссылаться на всякие странные сайты. С одной стороны там есть некая агрегация данных и знаний, с другой стороны, каждый использует своё видение видов, уровней, техник и методик тестов. Есть ISTQB и RUP. Чем они не угодили? Почему нельзя использовать их терминологию. Она хотя бы общепринята. Выделение тестирования изменений в одном уровне с функциональным и нефункциональным тестирование - крайне странно. Тестирование изменений ровно также включает функциональное и нефункциональное тестирование. Является общим множеством smoke, sanity & regression. Обычно виды тестов делят принципиально на функциональные и нефункциональные. А дальше внутри идёт ветвление которое спрашивать наизусть полностью не имеет смысла. Я обычно просто спрашиваю примеры.
Публикации
Какие вопросы я задаю на собеседовании QA Junior+