Мифы и легенды о тестировании
Тестирование — не то, чем кажется. Я работаю тестировщицей больше десяти лет и встречала разные мифы о своей работе. В этой статье я разберу самые популярные из них.
Примечание редакции: тема важная, поэтому в качестве иллюстраций для большей читаемости мы добавили любимые мемы про QA.
Миф 1. Тестирование — это просто
Многие не-тестировщики думают, что тестировать — просто. Достаточно нажимать кнопки в интерфейсе. На самом деле тестировщики исследуют продукт, собирают информацию, выдвигают и проверяют гипотезы.
Даже если вы находите баги, это ещё не делает вас тестировщиками. Вы можете писать хорошие сочинения, но одно это еще не делает вас писателем, верно? Чтобы стать тестировщиком, нужно разбираться в продукте, теории тестирования и процессах, уметь задавать правильные вопросы и искать информацию. Я стала тестировщицей 10 лет назад. Тогда, чтобы устроиться на работу, достаточно было быть сообразительной и прочитать одну книжку. Чтобы начать тестировать сегодня, мне пришлось бы потратить гораздо больше сил — изучить теорию тестирования, тест-дизайн и особенности процессов разработки, и понять специфику основных технологий. Вот, например, что нужно от джунов сейчас: раз (https://hh.ru/vacancy/50291854), два (https://hh.ru/vacancy/43386946), три (https://hh.ru/vacancy/48202920).
Миф 2. Тестирование — это скучно
Со стороны кажется, что тестировщики постоянно кликают на одни и те же кнопки, и всё. Если бы это было так, то тестировщиков бы уже не осталось — всё бы отдали машинам.
К счастью, это неправда. Чаще всего тестировщики тестируют одну и ту же функциональность далеко не всё время. И даже в этом случае они смотрят по сторонам, задают вопросы и думают. А когда тестировщики проверяют новую задачу, то берут на себя работу детектива. А что может быть увлекательнее?
Тестировщики работают и с бизнесом, и с потребностями пользователей, и заглядывают в то, как всё устроено внутри программы. И даже само тестирование разное — помимо тестирования функциональности есть ещё тестирование доступности, удобства использования, безопасности, нагрузки. Кроме того, в каждой компании свой процесс, который зависит от бизнес-контекста и целей компании.
В гибких методологиях тестировщики часто берут на себя всё, что не код, и тогда тестирование включает в себя анализ, ведение переговоров, погружение в бизнес-контекст и написание документации. Есть где развернуться!
Миф 3. Тестировщики всё ломают
Я знаю много шуток про тестировщиков, которые что-то ломают — от программ до стульев. Это часто смешно, но не отражает реальность. На самом деле, как метко написал QA-консультант Джеймс Бах, тестировщики ломают не программы, тестировщики ломают ваши иллюзии о программах. Мы никогда не хотим действительно что-то сломать — мы исследуем программу и выясняем, как она работает в реальном мире. Часто результаты не совпадают с ожиданиями.
На эту тему есть хороший пост у Майкла Болтона, одного из ведущих западных тестировщиков и консультантов по процессам тестирования (https://www.developsense.com/blog/2015/02/very-short-blog-posts-25-testers-dont-break-the-software/).
Миф 4. Перфекционизм — основное качество тестировщика
Я часто вижу «перфекционизм» в описании вакансий тестировщиков. И грущу, что компании видят в нём качество, полезное в работе.
На самом деле перфекционизм сильно мешает в тестировании, как и в любой другой работе. Перфекционисту трудно понять, где та самая точка «достаточно хорошо», после которой можно прекратить тестирование. А ещё ему сложно смириться с тем, что идеально не будет никогда, и что всегда будут баги, которые заказчики решили не чинить.
Миф 5. Чтобы стать тестировщиком, надо любить математику и компьютеры
Тестирование — очень разное. В таких направлениях, как в нагрузочном тестировании, математика может действительно пригодиться. В других хватит арифметики и базовых школьных знаний.
Я думаю, что тестирование больше про людей, чем про технологии. Это люди придумывают новые идеи, люди не понимают друг друга и люди же ошибаются. А компьютеры просто делают то, что люди им сказали. Социальный, естественный и гуманитарный бэкграунд помогает не меньше технического. Такие системы зачастую сложнее, чем технические.
В тестировании пригодится весь ваш опыт из разного образования и других профессий. Я знаю отличных тестировщиц, которые пришли из журналистики, юриспруденции, филологии и других областей, и именно эти не-технические навыки им сильно помогали. Это умения и разобраться с тонной документации, и быстро учиться новому, и работать с большими сложными системами. А технические навыки быстро набираются в работе.
Миф 6. Тестировщикам не надо знать, что «под капотом» программы
На самом деле хорошие тестировщики разбираются в технологиях и архитектуре приложений. Часто помогает базовое знание языков программирования. Писать код не обязательно, но вот понимать конструкции языка полезно — что такое условие, циклы, присвоение, функции, ООП. Это поможет посмотреть в код и как-то в нём разобраться:)
С технологиями тоже часто работает высокоуровневый взгляд. Что это такое? Для чего это используется? Какие могут быть риски и проблемы? Это помогает видеть потенциально уязвимые места и задавать правильные вопросы программистам.
Миф 7. В IT проще всего попасть через тестирование, а вообще я разработчиком хочу быть
Это популярная, но плохая идея. Тестирование и разработка — две отдельные специальности, со своими наборами навыков. Случается, что тестировщики становятся разработчиками или кем-то еще, но заранее на это рассчитывать на стоит. Всё равно придется осваивать новую специальность почти с нуля. Как если бы вы мечтали стать архитектором, но пошли учиться на дизайнера интерьеров. И там, и там вы работаете с зданиями и помещениями, но суть совершенно разная.
Если же говорить про специальности в IT, для которых не нужно обязательно программировать, то на тестировании всё не заканчивается. Есть разные другие варианты — техническое писательство, аналитика, менеджмент, работа с контентом.
Миф 8. Тестирование — женская профессия
Многие считают, что в тестировании необходимы пунктуальность, усидчивость и внимание к деталям. А эти качества приписывают женщинам. Это хорошие черты, но не главные для тестировщика. Таким может быть любой человек, вне зависимости от гендера.
Часто важнее увидеть общую структуру и взаимосвязи. Кроме того, нужно видеть уровни абстракции, необходимые для своей задачи. Надо ли глубоко погружаться в код? А в работу браузера или операционной системы? Или достаточно работать с общими представлениями.
Хорошим тестировщиком может быть человек любого гендера. Про женщин в тестировании и их особые проблемы я отдельно писала здесь.
Миф 9. Можно все автоматизировать, или ручное тестирование умирает
Мне очень не нравится разделение на ручных тестировщиков и автоматизаторов. Это все люди, и все они прежде всего работают головой. Не так важно, какие инструменты они используют, пишут ли они код или нет.
Так можно ли все автоматизировать?
Краткий ответ: тестирование нельзя автоматизировать, как нельзя автоматизировать исследование. Технологии могут помочь человеку, но не заменить его. С помощью автоматизации тестирования можно только проверять значение, которое мы ожидаем, но нельзя изучать продукт.
https://twitter.com/brenankeller/status/1068615953989087232
Первое легко автоматизируется, но пользователям обычно куда интереснее второе. При этом автоматизация проверок помогает быстрее получать результат и снять часть простой работы с тестировщиков. И тогда люди займутся работой, которую никто, кроме них, не сделает. Они погрузятся в изучение продукта с учетом кучи разных контекстов — истории продукта, нормативных актов и требований, конкурентов и отраслевых стандартов, требований разных заказчиков.
Миф 10. Каждый тестировщик становится автоматизатором
В тестировании есть разные пути развития, и погружение в инструменты и технологии — только один из них.
Можно стать экспертом в большой предметной области, можно заняться менеджментом и стратегией, можно уйти в специализированное тестирование — тестирование доступности, локализации и интернализации и другие.
У всех нас свой набор навыков и умений, который определяется и нашими интересами и склонностями, и нашим карьерным путём. Автоматизация тестирования — это только одно из возможных направлений, а не обязательная для всех дорога.
Миф 11. Надо просто хорошо писать код, тогда и тестировщики не будут нужны
Тоже популярное мнение — особенно, если команда разработчиков пишет автотесты. Но чем быстрее развивается продукт и изменяется среда вокруг, чем неопределеннее требования, чем больше рисков, тем нужнее тестирование.
Майкл Болтон написал развёрнутый ответ на это замечание. (https://www. developsense.com/blog/2014/12/when-programmers-and-testers-do-their-jobs/): «Когда разработчики хорошо делают свою работу, то тестировщики находят сложные, редкие, трудноуловимые, скрытые проблемы или проблемы, которые зависят от окружения».
Миф 12. Пропущенный баг — вина тестировщика
Многие считают, что за качество продукта отвечают тестировщики. Что их работа похожа на контроль качества на заводе, где надо отделить брак от хорошего продукта. Но даже на современных производствах это уже не так, а в разработке ПО — тем более. За качество продукта должна отвечать вся команда. Тестировщики никогда не смогут протестировать всё, и даже если найдут много дефектов — не смогут их исправить. Окончательное решение, как правило, принимает человек, ответственный за бизнес, который может взвесить риски.
Майкл Болтон замечает, что мы не можем обеспечивать качество — только содействовать ему. (https://software-testing. ru/library/testing/general-testing/1145-bolton) Так же, как за пропущенные мячи в футболе отвечает не только вратарь, но и вся команда.
Миф 13. Время тестировщиков дешевле, пусть они и тестируют
Караван идет со скоростью самого медленного верблюда. Часто компания зарабатывает деньги, когда новая возможность становится доступна пользователям, поэтому важнее как можно быстрее ее сделать. Выгода не в том, чтобы как можно меньше заплатить каждому специалисту, а в том, чтобы цена всего процесса была минимальной. Если из-за «дешевых» тестировщиков приходится ждать выхода в бой, то проигрывает в итоге бизнес.
Если же говорить о качестве, то это общее дело. И хорошо, когда вся команда вносит в это вклад, а не оставляет всё на тестировщиков. Чем больше переделок, тем дольше, а значит — дороже, стоимость запуска новой идеи.
Миф 14. Тестирование тормозит разработку
Быстрее всего ничего не делать. Это мгновенно — и совершенно бесплатно! Каждый раз, когда компания добавляет еще один этап в разработку программ — аналитику, дизайн, собственно программирование, тестирование — она увеличивает общее время. Компания делает это ради целей бизнеса — лучшего попадания в аудиторию, лучшего качества продукта, снижения рисков.
Многие люди внутри компании считают тестирование простым и быстрым процессом. И надеются, что ошибок в продукте не будет. Поэтому, когда разработчики закончили свою работу, этим людям кажется, что задача уже почти готова. Но на самом деле за этим «почти» может скрываться еще много работы. Тестирование — такой же этап процесса разработки, как и все остальные. Он может быть дольше, или короче, или отсутствовать совсем. Это зависит от задачи и рисков, которые нужно покрыть. И это надо обсуждать открыто.
Миф 15. Тестировщики и разработчики враждуют
Есть много мемов про взаимоотношения разработчиков и тестировщиков, в которых они враждуют. На самом деле часто всё иначе. Если разработчики считают, что тестировщики их контролируют, то отношения становятся сложными. Или если разработчиков и тестировщиков оценивают по тому, сколько первые сделали, а вторые нашли багов.
Но профессионалы понимают, что тестировщики не оценивают их самих, а помогают сделать продукт лучше. Дать новые идеи и посмотреть со стороны пользователя. В хороших командах разработчики и тестировщики работают вместе.
Миф 16. Тестировщики радуются, когда находят баг
Многие считают, что тестировщики радуются, когда находят проблему или что-то ломается от их действий. У начинающих действительно может быть азарт найти баг, но со временем это проходит. Опытных специалистов это скорее расстраивает — ведь это означает дополнительную работу и откладывает выпуск задачи в бой. Наша эффективность не зависит от того, сколько багов мы найдем, и баги не измеряют успешность нашей работы. Результат нашей работы — достаточно хороший продукт, который решает задачи заинтересованных лиц.
Тестировщики радуются, когда разобрались, как должна работать программа. Радуются, когда получается понять причины сложного бага. Радуются, когда выходит новая функциональность. Но не тогда, когда находят баг.
Миф N. Не-тестировщики знают лучше
Я могла бы привести еще большое количество мифов, но главный вывод этой статьи — это то, никто, кроме тестировщиков, не может быть специалистом в нашей работе.
Даже среди тестировщиков часто нет единого мнения по всем вопросам. Но это не повод думать стереотипами. Хотите узнать, из чего состоит наша работа — спросите нас.
GetMentor.dev — открытое сообщество IT-профессионалов, готовых делиться опытом и экспертизой. Мы помогаем решать проблемы тем, кто к нам обращается, и сами ищем новые возможности для роста и развития. В нашем сообществе в Telegram мы обсуждаем разные вопросы, важные и не очень. Подписывайтесь — будем на связи.
Ольга Артемьева — одна из менторов, с которыми вы можете посоветоваться на нашем сайте. Ольга ведёт блог Тестирование и жизнь, где пишет заметки о тестировании, зонах ответственности, work/life balance и многих других деталях жизни IT-специалиста.
