Выступление Александра Хози на онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA.
Не все начинающие тестировщики попадают в компанию с большим количеством классных тестировщиков-менторов. Поэтому некоторым из нас волею судеб пришлось начинать свой рост в тестировании с «обезьянок». И не всегда получается перерости этот этап, изжить «обезьянку», которая поселилась внутри вас.
В своем докладе я расскажу вам о том, как и почему появляются такие «обезьянки» и что можно с этим сделать.
Вот некоторые из них:
отсутствующий (или некомпетентный) наставник;
слаборазвитые процессы разработки и тестирования внутри компании;
вытекающее из слабости процессов: «Ну потестируй что-нибудь, ты же QA»;
отсутствие «вопросительности»
непонимание цели тестирования;
тестирование используется как вход в IT;
в профессию пришли за деньгами;
карма/другое :)
Также расскажу личную историю тестировщика-обезьянки: как я боролся с обезьянкой внутри меня :) как боролся с публичным мнением: «Тестировщик мобильных приложений – обезьянка». Кстати, иногда даже стоит давать обезьянке волю. Мы разберемся с ситуациями, когда это приносит пользу, и что я использую для этого.
Тестировать – непростой труд, особенно для новичков. Несмотря на то, сколько времени вы потратили на изучение тестирования, развитие своих навыков и попытки научиться тестировать лучше, вам все еще кажется, что вы топчетесь на месте. Или – еще хуже – вы не уверены, что эта профессия для вас.
По опыту скажу – дело не в вашей профнепригодности. Вы просто чересчур много нервничаете по поводу того, что на самом деле не очень-то и важно. Перестаньте нервничать, и все будет хорошо.
Регулярно на форуме или в почту нам приходят сообщения с вопросом "как стать тестировщиком, с чего начать"?
С одной стороны, новичку очень легко учиться, узнавать что-то новое. Потому что всё вокруг новое :)
С другой стороны, это скорее мешает, чем помогает: непонятно, с чего начать. Нужен какой-то план освоения нового материала.
Наш тренер Ольга Киселева подготовила статью «Как стать тестировщиком, с чего начать», а в прошлом году мы совместно с Ольгой запустили сайт Testbase, на котором собраны основные навыки, необходимые тестировщикам, а также разные полезные ссылки по теме.
Эту статью и этот сайт можно использовать как "дорожную карту" для самообучения.
А что делать, если вы уже вроде бы всё прочитали, но всё равно чувствуете, что вы пока не готовы идти работать тестировщиком? Или для самообучения не хватает самодисциплины? Или нужно срочно-срочно и нет времени всё это читать?
Тогда приходите к нам на курсы (базовый или интенсивный), где сможете попрактиковаться под присмотром тренера. Ведь зачем нужны курсы в наш век интернета, когда вся теория доступна бесплатно? Исключительно ради практических заданий и фидбека тренера.
Разумеется, за неделю или даже месяц хорошим тестировщиком вы не станете ни на каких курсах. Разве что это будет 8-часовая ежедневная стажировка. Цель курсов -- заложить базу, дать представление о тех навыках, которые вам предстоит развивать в течение следующих несколько лет.
А уже потом, поработав хотя бы год, приходите совершенствовать свои знания, у нас есть курсы не только для новичков :)
KISS, бритва Оккама... Все мы слышали мудрый совет быть проще и не усложнять ничего без нужды. Совет этот мог касаться пользовательского опыта по работе с вашим ПО, а мог относиться к вашему подходу к тестированию. Однако всегда ли этот совет полезен?
Иногда он может означать следующее:
Не нарушай статус-кво
Стремление повышать качество всего, к чему мы прикасаемся, естественно для тестировщиков. В результате мы можем начать "раскачивать лодку". В большинстве программ есть свои "скелеты в шкафу", которым не помешало бы пристальное внимание тестировщика. Не думайте, что мы ограничиваем себя поиском багов в софте - мы умеем находить их в процессах, документации, и даже в том, как люди размышляют о ПО.
Не удивляйтесь, если в ответ на ваши тестировщицкие тирады вы услышите совет быть проще, или нечто похожее.
У нас совсем скоро стартует курс Комплексная система подготовки тестировщиков по программе ISTQB, а вокруг ISTQB постоянно ходят споры. Что именно демонстрирует сертификат? Это ненужная бумажка или показатель уровня знаний? Представляем перевод статьи Дороти Грэм (Dorothy Graham) про суть и цели ISTQB.
Что меня шокировало, так это масштаб негатива в адрес сертификации. Заданный вопрос звучал как "Что вы думаете о профессиональной сертификации тестировщиков?". В США есть квалификационные модели для тестировщиков, появившиеся раньше ISTQB, но большинство опрошенных по умолчанию предположило, что их спрашивают именно про ISTQB-сертификацию.
Выступление Алексея Баранцева на уроке профориентации в 5-ом классе (в роли родителя, естественно).
Вряд ли наши читатели смогут почерпнуть в этом видео что-то новое для себя, но возможно, что кому-то из детей наших читателей будет интересно послушать чем их мама или папа занимаются на работе :-)
Читая лекции студентам в одном из технических вузов (а я им рассказывал про тестирование), я заметил, что никто из них не планировал в будущем стать тестировщиком. Я учил будущих разработчиков, менеджеров, дизайнеров, системных администраторов -- и ни одного будущего тестировщика. Но при этом по статистике процентов 20 из них в итоге всё таки попадали в тестировщики, и нисколько не были разочарованы. Почему? Что это за профессия такая?
Непрестижная или просто неизвестная? Чем вообще тестировщик отличается от разработчика или системного администратора? С точки зрения постороннего человека все они "компьютерщики" или "айтишники". Но заглянув на внутреннюю кухню разработки компьютерных программ, можно выяснить, что разные тестировщики отличаются от друга весьма и весьма сильно (впрочем, некоторые разработчики также отличаются друг от друга гораздо сильнее, чем тестировщик отличается от разработчика). Приходите, я расскажу вам о том, чем занимаются эти странные люди, про которых все думают, что они "ломают программы".
Я много размышлял о проверках и тестах и том, как заставить их гармонично сосуществовать, и подумал, что мы упускаем что-то важное, создавая проверки. Я сконцентрируюсь на автоматических проверках, но думаю, что мои мысли применимы и к неавтоматическим.
Некоторые команды сейчас достигли неплохого прогресса в создании автоматических проверок. Они перенимают передовой опыт. Классы, методы и объекты грамотно названы, и совершенно очевидно, что именно они делают. Условия ясно сформулированы, и если они не выполняются, об этом сообщается четко и внятно. Проверки создаются с хорошим уровнем абстракции и повторным использованием кода, они достаточно производительны и выполняются быстро и надежно. Все это очень здорово выглядит.
Но почему эта чудесная, хорошо составленная и удобопонятная проверка вообще есть? Почему она существует? Почему из всех вариантов проверок была выбрана именно она? Я могу ее прочитать (как я уже говорил, она хорошо написана), я вижу, что именно она проверяет, но этим информация о ней исчерпывается. Как я пойму, что шаги и условия проверки соответствуют ее первоначальной цели? Что именно в этой проверке или этом поведении системы сделало их достойными кандидатами на автоматизацию? Я не знаю.
Случалось ли, что вы бесились, пользуясь компьютером?
Для такой реакции есть тысячи причин. Долго грузится сайт. Дурацкие сообщения об ошибках мешают вам работать. В пунктах меню совершенно невозможно найти то, что вам нужно.
Каждый раз, когда вас бесит что-то подобное, вы сталкиваетесь с тем, что в тестировании называют багом. Проще говоря, баг - это что-то, что вас раздражает, а моя задача - предотвратить проникновение багов к вам.
Чтобы сделать это, я разговариваю с людьми бизнеса, которые заказывали программу, с дизайнерами, решающими, как она будет выглядеть, и с аналитиками, определяющими, как именно она будет работать. Я вспоминаю прошлый опыт и стараюсь предотвратить повторение старых ошибок.
Я сижу рядышком с разработчиками, пишущими код, и подмечаю проблемные моменты, пока они трудятся. Иногда они что-то упускают, или я могу не согласиться с их подходом.
Когда программа готова, я проверяю, работает ли она. Я раздумываю, какими способами люди могут, случайно или намеренно, сломать ее, и стараюсь убедиться, что программа с этим справится. Я удостоверяюсь, что она работает на разных компьютерах и мобильных устройствах. Я проверяю, удобно ли ее использовать, отзывчива ли она, безопасна ли.
Все это время я занимаюсь тестированием. Я тестирую, когда я общаюсь с людьми. Я тестирую, пользуясь приложением на своем компьютере. Я тестирую, создавая автоматические проверки, которые можно прогонять неоднократно, чтобы убедиться, что различные части программы правильно работают.
Тестирование помогает устранить раздражающие вас штуки. Люди должны быть счастливы, используя программу, и тестирование вносит в это важный вклад.
Большая часть тестирования сейчас отдается на аутсорсинг. Я живу в Индии и полагаю, что большинство популярных веб-продуктов тестируются именно у нас. Мне повезло - недавно я получил возможность подключиться к тестированию реального продукта и отследить его путь от истоков до релиза.
Когда я учился, мне рассказывали о множестве видов тестирования. Я узнал о куче концепций - белый ящик, черный ящик, интеграционное тестирование, проверка исправности, тестирование ядра, компонентов, и так далее. Мы активно пользовались этими определениями, нанимаясь на работу. Если эти строки читают выпускники ВУЗов - готовьтесь, сенсационное сообщение! Реальный мир очень отличается от книг!
Итак, предлагаю вам свою историю и свой опыт по тестированию реального коммерческого продукта. Сразу скажу, что "минутка час бережет" - отличный лозунг тестировщика. Тестирование должно начинаться как можно раньше - в идеале, с первого же дня старта проекта. Хорошие методики тестирования должны быть гибкими и подстраиваться под ход разработки. Наша команда приступила к тестированию с первого же дня.
Хм-хм. А что проверять-то в первый день? Еще ничего не сделано, нет никакой функциональности, так что же нам тестировать?