Большая часть моей работы посвящена обучению, тренировке и оценке тестировщиков. Как гуманисту, мне хочется применить тут эвристику разнообразия: наши различия могут сделать команду сильнее. Это означает, что я не могу выбрать один-единственный тип тестировщиков и оценивать людей согласно этому шаблону. С другой стороны, я вижу интересные модели навыков и темперамента у тестировщиков, и имеет смысл обсудить эти модели в широком ключе. Да, все снежинки различаются, но также верно, что все снежинки похожи друг на друга.
Итак, я выделяю как минимум семь различных типов тестировщиков: административный, технический, аналитический, социальный, эмпатический тестировщик, пользователь и разработчик. Когда я начну углубляться в объяснения, я хочу, чтобы вы поняли следующее: это модель, а не тюрьма. Это кластеры эвристик или – в некоторых случаях – ролей. Ваш стиль работы или ситуация могут подходить для нескольких моделей сразу.
При изучении любой дисциплины самое сложное/главное понять основы, базовые принципы, на пальцах, на школьных примерах, затем, на этот металлический каркас можно навесить тонны бетонной практики, получившийся железобетонный монолит станет гарантией практически не ограниченного технического роста специалиста. Звучит самоочевидно, не правда ли ..? И тем не менее, субъективный опыт автора в проведении собеседований, а это около ~500 специалистов из стран СНГ, Индии, США в Автоматизации тестирования и сопоставимые цифры в С \ С++ мире, говорит, что даже Senior разработчики в большинстве не понимают «физического смысла» ООП, не могут озвучить базовую формулировку одного из «столпов» - инкапсуляции, хотя знают как на 3 языках, 20 способами реализовать интерфейс, класс и объект, а вот вырасти дальше уже не могут, и вынужденно в течении 20 лет топчутся на месте. Вот это досадное карьерное недоразумение мы и постараемся исправить. IMHO тема будет интересна/полезна самому широкому кругу слушателей, от молодых специалистов в Ручном тестировании до Архитекторов в Автоматизации.
При изучении любой дисциплины самое сложное/главное понять основы, базовые принципы, на пальцах, на школьных примерах, затем, на этот металлический каркас можно навесить тонны бетонной практики, получившийся железобетонный монолит станет гарантией практически не ограниченного технического роста специалиста. Звучит самоочевидно, не правда ли ..? И тем не менее, субъективный опыт автора в проведении собеседований, а это около ~500 специалистов из стран СНГ, Индии, США в Автоматизации тестирования и сопоставимые цифры в С \ С++ мире, говорит, что даже Senior разработчики в большинстве не понимают «физического смысла» ООП, не могут озвучить базовую формулировку одного из «столпов» - инкапсуляции, хотя знают как на 3 языках, 20 способами реализовать интерфейс, класс и объект, а вот вырасти дальше уже не могут, и вынужденно в течении 20 лет топчутся на месте. Вот это досадное карьерное недоразумение мы и постараемся исправить. IMHO тема будет интересна/полезна самому широкому кругу слушателей, от молодых специалистов в Ручном тестировании до Архитекторов в Автоматизации.
Сейчас много говорят про DevOps, Agile-разработку и «сдвиг влево». Очевидно, эти процессные модели совершили открытие: тестировщики могут не только тестировать готовый продукт, и они могут и должны быть вовлечены в каждую стадию разработки.
Это не новость для курса «Rapid Software Testing». Мы изначально отвергли идею, что продукт должен быть завершен/соответствовать определенному уровню качества или неким «приемочным критериям», чтобы перейти в тестирование. Мы приветствуем возможность протестировать что угодно, выданное нам. Мы с радостью начнем тестирование с момента зарождения идеи продукта до момента, наступившего спустя долгое время после релиза.
Если тестировщиков приглашают на планерку, то продукт для тестирования еще отсутствует как класс. Что же нам там делать?
Тогда это казалось хорошей идеей, но сейчас я об этом жалею. Утром я проснулся рано, когда вся семья еще спала, и тихо прокрался вниз по лестнице, направляясь на кухню. Я открыл холодильник и там стояла она, полная бутылка эг-нога (напиток из взбитых яиц с сахаром, ромом или вином – прим. перев.) Я вытащил ее из холодильника, пододвинул стул к шкафу, нашел чашку и налил себе полную чашку вкусного, густого эг-нога. Когда я прикончил чашку, я налил еще одну, а затем еще, пока бутылка не опустела. Он был таким вкусным, но желудок сообщал мне, что я сделал глупость. Не буду утомлять вас деталями, но сегодня я понял, что слишком хорошо – тоже нехорошо.
Иногда я думаю о том, чего люди ожидают от вида тестировщика в процессе тестирования? Как, с их точки зрения, выглядит «тестирование»?
Если я заменю «тестировщика» на «программиста» или «разработчика» (а тестирование – на программирование или разработку), что вы себе представите? Когда я говорю, что я тестировщик, зачастую на меня тупо пялятся в ответ – как минимум тогда, когда я разговариваю с людьми, не работающими в сфере ПО. В результате я немного рассказываю про то, как я помогаю разрабатывать ПО и трачу время на выяснение, получат ли люди в итоге то, что на самом деле хотят – это определение, я надеюсь, легче для понимания. Дискуссия становится более прямолинейной, если мои собеседники тоже заняты в сфере ПО, но даже тогда я часто сталкиваюсь с целой линейкой предположений о том, что такое тестирование, или чем оно может быть.
Когда восемнадцать лет назад я проходил свой первый курс по тестированию, я узнал, что типичный тест-проект состоит из тест-стратегии, тест-плана, тест-сценариев, выполнения тест-кейсов и отчетности о результатах. Еще мне говорили, что тестирование – это профессия, и для хорошего тестирования нужны профессиональные тестировщики.
Однако иногда вы оказываетесь в ситуации, когда это не лучший способ тестировать. В этой статье я описываю проект, в котором тестирование проводилось иначе, без профессиональных тестировщиков. Теперь я знаю, что некоторые называют такой подход «охотой на баги», и я убежден, что в этой конкретной ситуации охота на баги – лучший выход.
Когда ты – единственный тестировщик – неважно, положивший ли начало или конец тест-команде – у тебя есть масса возможностей, осложненных внушительными обязанностями.
Если ты первый, кого наняла компания, то ты, возможно, отвечаешь за создание эффективных процессов тестирования для нескольких команд. Может быть, твоя обязанность – тестирование нескольких продуктов, или же ты возглавляешь найм новой команды. Одинокий тестировщик как результат сокращения команды может столкнуться со всеми этими проблемами, да еще и с дополнительным давлением – ведь нужно выполнять работу по тестированию, которую до этого делали другие люди.
В этих случаях легко сказать, что компания просто не ценит тестирование. Возможно, это даже правда, но я считаю, что в большинстве случаев это не так. В конце концов, ты еще там работаешь – то есть кто-то еще осознает нужду в тестировании. Возможно, на найм большего количества тестировщиков нет бюджета, или высший менеджмент считает, что тестирование должно быть частью команды, а не большой изолированной областью.
— Итак, поступило новое дело: в нашем распоряжении 10 дней для поиска места тестировщика в Scrum разработке. Необходимо понять, что же это такое Scrum, что входит в это понятие, кто вовлечен в этот процесс, и что именно необходимо делать тестировщику.
— Шеф, так что же такое Scrum?
— Все элементарно, коллега. Scrum – это набор принципов, на которых строится процесс разработки, позволяющий в установленные небольшие промежутки времени предоставлять заказчику (конечному пользователю) наделенное наибольшим приоритетом работающее ПО с новыми возможностями.
— И из чего состоит этот процесс?
— Из принципов, скоупа задач, определенных при планировании, и ограниченных (четко оговоренных и определенных) сроков. Учитывается и то, что качество не должно пострадать из-за скорости или установленных временных рамок.
— Шеф, и с чего начнем?
— А начнем с того, что рассмотрим наиболее простую и понятную схему для Scrum процесса: двухнедельная итерация (10 рабочих дней). При этом мы имеем определенно важный спринт, сплоченную команду разработки и тестирования, минимум документации, четкие требования к проекту и лаконичное описание требуемых разрабатываемых фич.
— И где же в этой схеме место тестировщика?
— А в этом нам предстоит разобраться, коллега!)
"Обращайтесь с читателями так, как вы хотели бы, чтобы обращались с вами. Пишите Gherkin так, что люди, не знающие фичу, поймут, о чем это".
Хороший Gherkin (как и любой язык, основанный на specification-by-example) неразрывно связан с созданием хороших заголовков для поведенческих сценариев. Заголовок – это лицо сценария: он резюмирует суть поведения. Хорошие заголовки серьезно облегчают сотрудничество в команде, а плохие – затрудняют его. Но что же делает заголовок "хорошим"? Вот несколько неплохих советов.
