Где учиться начинающим тестировщикам более-менее понятно всем: существует много статей, курсов, книг и мануалов. А вот что делать тем, кто вырос из джуна в мидла — непонятно. В преддверии конференции DUMP, мы решили спросить известных тестировщиков, что они посоветуют джуниорам, которые хотят расти. Первым на наши вопросы ответил «дедушка русского тестирования» Александр Александров — тест-менеджер в компании Luxoft, кандидат физико-математических наук, эксперт RSTQB.
После какого события джун перестает быть джуном и становится тестировщиком?
Тестирование — это область, которая, на первый взгляд, кажется очень простой для освоения и работы в ней: «Знать ничего не надо, нажимай на кнопки и всё».
Джун перестает быть джуном, когда у него проявляется интерес к этой инженерии, к этой деятельности. Тогда перед ним открываются дороги в профессию и дальше всё зависит от него — он может расти. Он может быть джуном с точки зрения опыта, квалификации, выполненных проектов. Но у него может быть склонность, талант, везение к этой работе. И вот формально он джун, он работает у вас вторую неделю, но делает вещи, которые у вас, у квалифицированного человека, не получаются, потому что его «боженька поцеловал в лобик». Это очень важно, потому что какие-то вещи можно развить до определенного уровня. При этом если ты не хочешь, но обязан этим заниматься, это становится трудной работой. Джун перестанет быть джуном, когда ему становится интересно то, что он делает, когда у него просыпаются азарт и амбиции стать лучшим. Ему интересно копать, работать лучше, чем он работает сейчас.
Тестирование — очень сложная деятельность. Тестировщик ищет ошибки в ПО. Он не знает, есть ли они, сколько их, где они, как их найти, но он их находит! Как сапёр, только без миноискателя и с завязанными глазами. Если он это делает, то он не совсем обычный человек. А тестировщики — они все такие, у них у всех завязаны глаза. Никто не знает, где эти дефекты, но они же их находят. Поэтому тестирование — это сложная задача. Это задача для человека, которому, с одной стороны, это интересно, а с другой — для человека, который не боится сложностей. Если человек делает всё, как написано, от сих и до сих, то это похоже на приготовление блюда по рецепту — есть можно, но «вау» не будет.
Насколько сильно команда влияет на становление тестировщика?
Команда может влиять очень сильно, и здесь я бы не стал выделять тестировщика. Она ведь на то и команда, что все друг на друга влияют, и важно, чтобы был правильно выстроен процесс этого влияния. Чтобы процесс был направлен на достижение общих целей — на изготовление продукта с высоким качеством. Это так называемый team spirit — командный дух, сплоченность.
Очень часто из тестировщиков делают «козлов отпущения». Как говорят иногда, что успех проекта — это же вот, разработчики-молодцы написали классный код, менеджер тоже хорошо поработал. А тестировщики они так, просто ошибки искали и без них бы нашли. Но если ошибку находят во время эксплуатации, то «почему тестировщики ее пропустили, почему они ее не нашли?» Получается — кому вершки, а кому корешки. Это ни в коей мере не способствует нацеленности команды. Потому что если вы выполняете свою работу и ничего, кроме негатива, вам за нее не достается, то в какой-то момент у вас исчезает мотивация, у вас пропадает желание работать в этой команде. А 3-4 такие команды — и специалист начнет думать «а зачем я занимаюсь тестированием, если оно никому не нужно?» Поэтому два важных качества должны быть у тестировщика: занудство и железная нервная система.
Курсов и материалов для начинающих тестеров много, а что делать «продолжающим?» Как найти действительно хорошие конференции и события?
Нет общих рецептов. Как писал Толстой: «Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему». Тестировщики имеют дело с несчастьями по своей сути — с проблемами в проектах. Я уверен, что эти проблемы у каждого проекта свои. Поэтому, в значительной степени, продолжающим тестировщикам надо уметь оглядываться назад, замечать собственные ошибки и промахи, которые есть у каждого. И стараться их преодолевать. И когда тестировщик будет их преодолевать, он будет точечно искать решение проблем. Ответ на вопрос «как не пропустить такую багу» можно найти в книжках, тренинге, на какой-то конференции. Но универсального совета «клад зарыт вон под тем деревом» — нет.
Очень важно при этом не успокаиваться и видеть свои недостатки или просить кого-то другого указать на них, при этом это должны быть абсолютно реальные недостатки. Не так, чтобы на вас вешали всех собак — «смотрите, дефект в проде». Да, его пропустили тестировщики, но создали-то его разработчики. Про это никто никогда не вспоминает — все винят тестировщиков. Поэтому активность тестировщика хороша еще и тем, что это профессия, в которой приходится непрерывно учиться и непрерывно совершенствоваться.
Конференций по тестированию не так много, поэтому продолжающим я бы предложил всё смотреть. Но даже это не гарантирует, что тестировщик найдет там ответы на свои вопросы. Потому что всё равно должен быть кто-то первый, кто справится с новой проблемой.
Из материалов я бы рекомендовал обратить внимание на международную организацию по сертификации тестировщиков ISTQB. У нее есть региональные отделы, в том числе и в России, его возглавляет Андрей Конушин. В ISTQB сосредоточена довольно большая экспертиза. Материалы, которые есть в этой организации, абсолютно доступны. Они могут заставить человека думать и действовать. Там нет ответов на вопросы, но там есть мировой опыт тестирования, который может быть полезен тем самым пытливым мальчикам и девочкам в тестировании, которые хотят расти и развиваться. Там большая линейка уровней, для каждого уровня есть свой силлабус.
При этом я, конечно, не сбрасываю со счетов и конференции типа SQA Days, и сайты software-testing.ru (ведет Алексей Баранцев) и testitquickly.com (ведет Алексей Лупан). Но опять же, этим надо заниматься весьма регулярно.
Опытный крутой тестер вашей мечты. Как вы узнаете его из тысячи?
Надо посмотреть, как он выполняет свои производственные обязанности. Из «толпы» узнать его нельзя, пока он не начнет заниматься тестированием. А когда он начнет — тут всё и встанет на свои места.
Это как в любой области. Если человек не «в бою», то он рассуждает, он говорит, хвалит или ругает себя. Ну а зачем хвалить, когда можно показать, что ты можешь.
Чем бы вы занимались, если не тестированием? :)
Я, конечно, хотел бы заниматься внуками, но внуков у меня пока, к сожалению, нет. Не знаю, я занимаюсь тестированием достаточно давно, с 1974 года. Мне даже на SQA Days подарили звезду, на которой внизу написано «дедушка русского тестирования». Это прозвище придумал мой друг и коллега Сергей Смирнов, а потом кто-то услышал и в результате мне подарили вот такой памятный знак.
Я не знаю — я ведь долгое время был и разработчиком тоже, и писал большие программы, скажем 30 тысяч строк на ассемблере. В том, что я занимаюсь тестированием, огромная заслуга моего научного руководителя с 3-го курса, с курсовой до диссертации, и моего большого друга, с которым мы поддерживаем отношения и сейчас — профессора Виталия Кауфмана. Он с 1991 года живет и работает в Финляндии, поэтому видимся мы редко. Это человек, которому я очень многим обязан с точки зрения моего становления, как профессионального, так и личностного. Он совершенно замечательный мужик, и мы постоянно переписываемся и общаемся по скайпу. Общение с ним привило мне интерес к тестированию. Потому что именно он в 1974 году как раз «нащупал» ту предметную область, которой я стал заниматься под его руководством. Фактически это был первый путь в тестирование.
Не знаю, наверно, кем-то был бы :) Скорее всего, был бы разработчиком или техническим писателем, потому что это тоже получается. Сейчас, например, сочетаю работу тестировщика и технического писателя.
Мне слишком много лет, и я слишком долго занимаюсь тестированием, чтобы сейчас всё «отмотать назад» и представить, чем бы я занимался 40 лет назад. Но внуками, надеюсь, гораздо интереснее заниматься :)
В следующем посте — советы от Максима Захарова (СКБ Контур), Ильи Вахрушева (Exadel), Арсения Батырова (Badoo) и Анастасии Асеевой (Альфа-Лаборатория).
После какого события джун перестает быть джуном и становится тестировщиком?
Тестирование — это область, которая, на первый взгляд, кажется очень простой для освоения и работы в ней: «Знать ничего не надо, нажимай на кнопки и всё».
Джун перестает быть джуном, когда у него проявляется интерес к этой инженерии, к этой деятельности. Тогда перед ним открываются дороги в профессию и дальше всё зависит от него — он может расти. Он может быть джуном с точки зрения опыта, квалификации, выполненных проектов. Но у него может быть склонность, талант, везение к этой работе. И вот формально он джун, он работает у вас вторую неделю, но делает вещи, которые у вас, у квалифицированного человека, не получаются, потому что его «боженька поцеловал в лобик». Это очень важно, потому что какие-то вещи можно развить до определенного уровня. При этом если ты не хочешь, но обязан этим заниматься, это становится трудной работой. Джун перестанет быть джуном, когда ему становится интересно то, что он делает, когда у него просыпаются азарт и амбиции стать лучшим. Ему интересно копать, работать лучше, чем он работает сейчас.
Тестирование — очень сложная деятельность. Тестировщик ищет ошибки в ПО. Он не знает, есть ли они, сколько их, где они, как их найти, но он их находит! Как сапёр, только без миноискателя и с завязанными глазами. Если он это делает, то он не совсем обычный человек. А тестировщики — они все такие, у них у всех завязаны глаза. Никто не знает, где эти дефекты, но они же их находят. Поэтому тестирование — это сложная задача. Это задача для человека, которому, с одной стороны, это интересно, а с другой — для человека, который не боится сложностей. Если человек делает всё, как написано, от сих и до сих, то это похоже на приготовление блюда по рецепту — есть можно, но «вау» не будет.
Насколько сильно команда влияет на становление тестировщика?
Команда может влиять очень сильно, и здесь я бы не стал выделять тестировщика. Она ведь на то и команда, что все друг на друга влияют, и важно, чтобы был правильно выстроен процесс этого влияния. Чтобы процесс был направлен на достижение общих целей — на изготовление продукта с высоким качеством. Это так называемый team spirit — командный дух, сплоченность.
Очень часто из тестировщиков делают «козлов отпущения». Как говорят иногда, что успех проекта — это же вот, разработчики-молодцы написали классный код, менеджер тоже хорошо поработал. А тестировщики они так, просто ошибки искали и без них бы нашли. Но если ошибку находят во время эксплуатации, то «почему тестировщики ее пропустили, почему они ее не нашли?» Получается — кому вершки, а кому корешки. Это ни в коей мере не способствует нацеленности команды. Потому что если вы выполняете свою работу и ничего, кроме негатива, вам за нее не достается, то в какой-то момент у вас исчезает мотивация, у вас пропадает желание работать в этой команде. А 3-4 такие команды — и специалист начнет думать «а зачем я занимаюсь тестированием, если оно никому не нужно?» Поэтому два важных качества должны быть у тестировщика: занудство и железная нервная система.
Курсов и материалов для начинающих тестеров много, а что делать «продолжающим?» Как найти действительно хорошие конференции и события?
Нет общих рецептов. Как писал Толстой: «Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему». Тестировщики имеют дело с несчастьями по своей сути — с проблемами в проектах. Я уверен, что эти проблемы у каждого проекта свои. Поэтому, в значительной степени, продолжающим тестировщикам надо уметь оглядываться назад, замечать собственные ошибки и промахи, которые есть у каждого. И стараться их преодолевать. И когда тестировщик будет их преодолевать, он будет точечно искать решение проблем. Ответ на вопрос «как не пропустить такую багу» можно найти в книжках, тренинге, на какой-то конференции. Но универсального совета «клад зарыт вон под тем деревом» — нет.
Очень важно при этом не успокаиваться и видеть свои недостатки или просить кого-то другого указать на них, при этом это должны быть абсолютно реальные недостатки. Не так, чтобы на вас вешали всех собак — «смотрите, дефект в проде». Да, его пропустили тестировщики, но создали-то его разработчики. Про это никто никогда не вспоминает — все винят тестировщиков. Поэтому активность тестировщика хороша еще и тем, что это профессия, в которой приходится непрерывно учиться и непрерывно совершенствоваться.
Конференций по тестированию не так много, поэтому продолжающим я бы предложил всё смотреть. Но даже это не гарантирует, что тестировщик найдет там ответы на свои вопросы. Потому что всё равно должен быть кто-то первый, кто справится с новой проблемой.
Из материалов я бы рекомендовал обратить внимание на международную организацию по сертификации тестировщиков ISTQB. У нее есть региональные отделы, в том числе и в России, его возглавляет Андрей Конушин. В ISTQB сосредоточена довольно большая экспертиза. Материалы, которые есть в этой организации, абсолютно доступны. Они могут заставить человека думать и действовать. Там нет ответов на вопросы, но там есть мировой опыт тестирования, который может быть полезен тем самым пытливым мальчикам и девочкам в тестировании, которые хотят расти и развиваться. Там большая линейка уровней, для каждого уровня есть свой силлабус.
При этом я, конечно, не сбрасываю со счетов и конференции типа SQA Days, и сайты software-testing.ru (ведет Алексей Баранцев) и testitquickly.com (ведет Алексей Лупан). Но опять же, этим надо заниматься весьма регулярно.
Опытный крутой тестер вашей мечты. Как вы узнаете его из тысячи?
Надо посмотреть, как он выполняет свои производственные обязанности. Из «толпы» узнать его нельзя, пока он не начнет заниматься тестированием. А когда он начнет — тут всё и встанет на свои места.
Это как в любой области. Если человек не «в бою», то он рассуждает, он говорит, хвалит или ругает себя. Ну а зачем хвалить, когда можно показать, что ты можешь.
Чем бы вы занимались, если не тестированием? :)
Я, конечно, хотел бы заниматься внуками, но внуков у меня пока, к сожалению, нет. Не знаю, я занимаюсь тестированием достаточно давно, с 1974 года. Мне даже на SQA Days подарили звезду, на которой внизу написано «дедушка русского тестирования». Это прозвище придумал мой друг и коллега Сергей Смирнов, а потом кто-то услышал и в результате мне подарили вот такой памятный знак.
Я не знаю — я ведь долгое время был и разработчиком тоже, и писал большие программы, скажем 30 тысяч строк на ассемблере. В том, что я занимаюсь тестированием, огромная заслуга моего научного руководителя с 3-го курса, с курсовой до диссертации, и моего большого друга, с которым мы поддерживаем отношения и сейчас — профессора Виталия Кауфмана. Он с 1991 года живет и работает в Финляндии, поэтому видимся мы редко. Это человек, которому я очень многим обязан с точки зрения моего становления, как профессионального, так и личностного. Он совершенно замечательный мужик, и мы постоянно переписываемся и общаемся по скайпу. Общение с ним привило мне интерес к тестированию. Потому что именно он в 1974 году как раз «нащупал» ту предметную область, которой я стал заниматься под его руководством. Фактически это был первый путь в тестирование.
Не знаю, наверно, кем-то был бы :) Скорее всего, был бы разработчиком или техническим писателем, потому что это тоже получается. Сейчас, например, сочетаю работу тестировщика и технического писателя.
Мне слишком много лет, и я слишком долго занимаюсь тестированием, чтобы сейчас всё «отмотать назад» и представить, чем бы я занимался 40 лет назад. Но внуками, надеюсь, гораздо интереснее заниматься :)
В следующем посте — советы от Максима Захарова (СКБ Контур), Ильи Вахрушева (Exadel), Арсения Батырова (Badoo) и Анастасии Асеевой (Альфа-Лаборатория).
INCorpes
У нас всегда винят разработчиков, вот прям всегда. Ни разу не припомню, чтобы сказали, что вот тестировщики ай ай ай пропустили баг. И пусть эта функциональность даже в Acceptance Criteria явно прописана, тоесть это не регрессия какая то, это не «скрытый баг», который появляется на хитрых данных или при нагрузочном тестировании… нет, этот баг в функциональности, которая явно прописана в задаче и тестер не смог её найти за неделю =\. И это, конечно, не снимает ответственности за невнимательность с разработчиков, но в нашем случае выкинуть тестеров и просто посадить еще одного разработчика на код ревью уменьшило количество (!) неотловленных (!) багов на порядок
lxsmkv
Эти обиды все — бред.
От ошибок не застрахован никто. Ни разработчик, ни тестировщик, ни кассир в магазине, ни главбух в многомиллионной корпорации. Ошибаются судьи и отправляют живых людей на смертную казнь.
Надо перестать думать, что мы, люди, должны обладать какими-то суперспособностями, только потому что «мы-ж программисты», «мы-ж тестировщики». Профессиональная специализация не избавляет человека от человеческих недостатков, он просто в одной из областей деятельности эффективнее другого. Всего лишь эффективнее. Я быстрее и яснее пришу багрепорт, разработчик быстрее и лаконичнее пишет рекурсивную функцию.
Не ошибаться не относится к профессионализму никак. Это вредный, глупый миф. Если бы профессиональные шахматисты не делали ошибок, противник не смог бы у них выиграть. Но постоянно кто-то ошибается. Хотя и очень хорошо делает свою работу. И эти ошибки видны со стороны, но не видны тому кто их допускает.
Если вы не допускаете ошибок — вы робот. Винить человека в том, что он ошибается, все равно, что винить его в том, что он дышит воздухом.
Искать виноватых вообще очень вредный умственный настрой. Я стараюсь в себе за этим следить и ребенка отучаю как себя винить так и других. Просто нужно слово «вина» искоренить, разучить, забыть навсегда. Станет лучше жить. Причина ошибки программы не в человеке, она в коде. Вот код и надо исправить. А кто это сделает лучше чем разработчик?
Надо любить своих разработчиков. Я хочу чтобы найденные мной проблемы были устранены, я хочу гордиться тем, что наш продукт нравится клиенту. Мне хочется, чтобы клиент работал именно с нашей командой.
Я часто хвалю разработчиков, за то что они очень быстро решают проблемы. Я проверяю их фиксы. Ведь самое большое удовольствие, когда проблема была исправлена и при верификации она была действительно устранена и не вызвала регрессии.
Я не потираю злобно руки находя баг. Я пишу репорт, как можно более старательно и полно, включая любую доступную мне информацию которая ускорит устранение дефекта. Чтобы разработчик не тратил драгоценное время пытаясь понять «бессвязную охинею» или ища нужное место в стомегабайтном трейсе.
Тикет это ценный документ. И оформлен он соответственно. И от разработчиков я требую соответствующего отношения, занесения решения, и всех нужных аттрибутов, чтобы через год можно было его прочитать и понять где что было сломано и где и как было исправлено.