В Новый год многие подводят итоги, анализируя прошедший год, вспоминают все свои результаты и строят планы на будущее. В 12-ом выпуске нашего календаря Анастасия Ронжина, тестировщик сервиса Контур.Маркет, расскажет о том, почему стоит пробовать что-то новое, менять свои взгляды, подходы, ошибаться и снова пробовать.
Зачем мне это надо?
У меня всё хорошо, я отлично работаю, меня хвалят, зачем мне что-то менять? Вполне логичный вопрос. В ответ цитата из книги «Алиса в Зазеркалье»:
Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!
Пока мы сидим и просто тестируем задачки, мир не стоит на месте. Джеймс Бах с Майклом Болтоном проводят очередное исследование и ищут подходы к тому, чтобы за короткое время тестировать с высоким качеством.
Эволюционирует место тестировщика в процессе разработки, да и сами процессы. Например, Максим и Ирина из нашей компании рассказывали про эволюцию автотестов, о том, как можно ускорить разработку с помощью тестов и изменении взглядов на то, кто и на каком этапе их должен писать. Лена и Илария рассказывали о том, что можно менять свои инструменты, подключаться к общению с пользователем, к подготовке ТЗ и прототипов, чтобы повысить качество продукта.
Мне очень грустно, когда я очередной раз слышу мнение, что тестировщик может достичь своего предела за 1,5 года, а дальше либо в автоматизацию, либо смена роли на менеджера, аналитика, разработчика и т. п. Когда твой каждый день — это просто повторение алгоритма: почитал аналитику, посмотрел прототипы, потестировал, запостил баги, перепроверил баги — то легко понять, почему ты устаёшь и разочаровываешься в профессии. Это же просто скучно!
Но когда ты меняешь подходы к изучению задачи, подходы к генерации тестов, способы тестирования, то:
- Во-первых, ты находишь то, что позволяет тебе тестировать быстрее, то, что позволяет тебе провести глубокий анализ фичи и ничего не упустить. Думаю, от улучшения своей работы и от появления свободного времени никто не откажется :).
- Во-вторых — это действительно весело! Лично мне очень трудно изо дня в день выполнять типичные задачки стандартным алгоритмом.
Ты можешь копать определенную тему и стать узким спецом. Ты можешь расти вширь. Со временем к тебе потянутся люди, потому что неожиданно ты начнешь отвечать на вопросы «своей темы». Тебя могут звать в другие команды наладить процесс или какой-то инструмент, обучить чему-то. Ещё один профит — своим интересом, своими знаниями ты можешь вдохновить других коллег на развитие, а значит, в мире станет ещё больше хороших тестировщиков :).
К чему именно можно менять подход?
1. Артефакты или документация тестирования
Каждый из нас где-то фиксирует план тестирования, декомпозицию задачки, схему работы продукта, инструкции, баги, договоренности. Это может быть листок бумаги, файл на компьютере или какая-то программа. Мы создаем тест-кейсы, чек-листы, интеллектуальные карты, таблицы, схемы, диаграммы, инструкции…
О чем здесь стоит подумать, так это о целях: для чего и для кого вы это делаете? Документация тестирования — это продукт или инструмент? Насколько быстро меняется у вас продукт? А какой поток новых тестировщиков? Есть замечательный набор вопросов, описанный в уроке 148 из книги Lessons Learned in Software Testing: A Context-Driven Approach, Cem Kaner, James Bach and Bret Pettichord. Если у вас нет под рукой книги, есть перевод этого урока.
У одной команды я видела автотесты — как основную самоподдерживающуюся документацию, почему бы и нет?
2. Техники тестирования
Это, наверное, самый очевидный пункт, но куда без него. Ответьте честно себе, какие техники вы сейчас применяете? Нет, не знаете, именно применяете! А давно ли пытались найти что-то новенькое?
Я часто сталкиваюсь с тем, что тестировщики знают теорию тест-дизайна, но почему-то не применяют её и тестируют, как когда-то научились, на уровне интуиции, возможно, по привычке или после неудачных попыток применения техник. Есть классная мысль у Канера в уроке 26 из той же книги:
Intuition is a fine beginning, but a lousy conclusion (Интуиция хороша для начала, но паршива под конец).
Да, в начале нас спасает это чутьё, мы натыкаемся при тестировании на баги, у нас вроде получается. Но со временем с боевой начнут прилетать пропущенные баги. Например, внезапно оказывается, что при совмещении конкретных значений параметров что-то происходит не так, или при каком-то действии внезапно объект перешел в новое состояние, а мы этого не заметили при тестировании. Техники позволят тебе избежать всего этого, они позволят тестировать эффективнее, ты сможешь решать быстрее и качественнее задачки.
У Алексея Баранцева была очень хорошая аналогия с ориентированием. Когда ты хорошо научился ориентироваться на местности (интуитивно использовал техники, неосознанно), то изучив карты, модели, ты будешь ещё лучше ориентироваться. Новые техники дадут тебе новые возможности перемещения по местности. Например, научился скалолазанию — теперь можешь не только обходить гору, но и забираться на неё. Техники очень сложно идут вначале, пока ты их изучаешь, но со временем ты тренируешься и потом используешь их на автомате.
Где найти новые идеи по техникам? Прочитайте или, если уже читали, снова пролистайте книгу A Practitioner's Guide to Software Test Design, Lee Copeland, или возьмите себе в пару коллегу, выберите любой тест-тур Виттакера (Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design, James A. Whittaker) и «попутешествуйте» по своему продукту. Тряхните стариной и запишитесь на курс по тест-дизайну. Пробуйте!
3. Техники анализа и генерации идей
Да-да, именно анализа всей постановки задачи, изучения функциональности, изучения объекта тестирования. Если вернуться к рассуждению об интуиции, причиной пропуска ошибок ещё может быть недостаточно проанализированная задача, не полностью собранная информация. Что здесь можно изменить?
Можно изучить, какие бывают оракулы тестирования. Наверняка вы откроете для себя новый источник информации. Или, если вы их и так знаете, посмотрите, например, на продукт вашего конкурента и изучите, как там реализованы ваши фичи.
Поищите техники анализа, изучайте моделирование, ведь мы тестируем именно по своему представлению программы, по своей модели. Возьмите объекты вашей системы и проведите анализ по ДПЗ (действия — параметры — значения).
Сначала выделяйте все объекты, которые у вас есть, расписывайте все действия, которые можете совершить над этими объектами, затем параметры, влияющие на действия, а потом конкретные значения параметров.
Почитайте книги Эдварда Де Боно про и придумывание нестандартных решений. Возьмите книгу «Рисовый штурм» и потренируйте . Мы каждый день штурмим над задачками, придумываем, а что ещё могло повлиять на нашу задачу. Тренировки помогут делать это быстрее и продуктивнее.
4. Окружение и процессы
Я не говорю про смену команды или компании, хотя в каких-то ситуациях почему бы и нет? :) Я хотела поговорить про то, что вокруг тестирования.
Возьмите и поменяйте свой любимый браузер или разрешение экрана. Если вы тестируете веб-приложение, уверена, что посмотрите на продукт по-другому.
Смените Microsoft Visual Studio на JetBrains Rider (или наоборот). Попробуйте использовать другой инструмент для тестирования API. Поизучайте другие решения, вполне возможно, появилось что-то новое и более удобное для вас.
Вы постоянно получаете на тестирование ветку, в которой не собирается проект или в которой в первые же минуты находите баги? Или всегда находите очень много багов? И при этом у вас ещё и большая очередь на тестирование? Поизучайте эвристики прекращения тестирования (да-да, сырую ветку можно просто взять и завернуть обратно), меняйте требования к ветке на входе, привлекайте коллег к тестированию. А может, некоторые ветки в действительности не нуждаются в тестировании, разработчик уже сам всё проверил?
А иногда очень полезно просто взять и пересесть в другой конец комнаты, поближе к разработчикам или другим тестировщикам. Смена места поможет освежить взгляд на работу.
5. Роль и обязанности тестировщика
Моё любимое. Исследуйте, кем является тестировщик в соседних командах, в других проектах или даже в других странах. У нас на конференции ДАМП как-то было интервью с Джеймсом Бахом, и некоторые ответы просто удивляли. У Джеймса совершенно другое представление о том, кто такой тестировщик, бывают ли автоматизаторы, и о том, что самое интересное в тестировании!
Сходите на несколько собеседований. Именно просто ходите. Вы узнаете, что происходит в других компаниях, что ценится в тестировщиках, что от них ожидают.
Вы до сих пор принимаете решения о том, релизить или нет? Или выполняете то, что обычно делают менеджеры? Прочитайте книгу Джерри Вайнберга Perfect Software And Other Illusions About Testing, и она перевернет ваш мир! А потом обязательно дайте почитать своему менеджеру.
Вы считаете, что обеспечение качества входит в обязанности тестировщика? Джеймс Бах в том же интервью привел хороший пример с охранником на военной базе.
Ты, конечно, можешь просто охранять базу, а можешь ещё и изучать, почему люди хотят проникнуть на эту базу, делать это дисциплиной в военном училище. Означает ли это, что можно не охранять базу? Конечно же, нет! Кто-то должен охранять. Но, уже применительно к тестированию, если ты изучишь и начнешь внедрять то, что будет уменьшать количество багов, то да, ты можешь снизить число «охранников».
На тему обеспечения качества и роста тестировщика на этой же конференции был хороший доклад-рассуждение от Максима.
Вы всё ещё считаете, что есть автоматизаторы и ручные тестировщики? Послушайте Джеймса, послушайте доклад о том, как в проекте автотесты пишут только разработчики, или о том, как в команде роль автотестера эволюционировала и теперь в команде все пишут автотесты и отдают в тестирование ветку только с зелеными тестами, в том числе новыми тестами по фиче.
Какими видами тестирования вы занимаетесь? Только функциональным? А вы можете ответить — почему? И кто отвечает за другие виды? Подумайте, возможно, увидите какие-то пробелы.
Поизучайте другие роли, например, как писать аналитику («Современные методы описания функциональных требований к системам» Алистера Коберна), кто такой менеджер и что он должен делать («Идеальный руководитель» Адизеса). Это позволит вам больше понять другие роли, их позицию. А также почерпнуть новые идеи.
6. Ещё кое-что
Тестировщики много общаются с другими и много пишут. Нам приходится объяснять ошибки или пытаться задавать вопросы, когда мы придумали жутко хитрую ситуацию. Поэтому развивайте эти навыки. Например, есть хорошая книга Максима Ильяхова и Людмилы Сарычевой — «Пиши, сокращай». Просто поищите по тематике на сайтах издательств или магазинов.
Ещё одна неожиданная идея — вы можете потестировать себя! Или своё развитие! Как это сделала Екатерина Боброва.
Что нам мешает
Давайте рассмотрим самые популярные стоп-факторы, которые нам мешают попробовать другой подход.
Нет времени
Это, наверное, самое простое. Сходите на курс по тайм-менеджменту, читайте книги про эффективность. Например, «Джедайские техники» Максима Дорофеева.
Не знаете, как сделать первый шаг
Выделите конкретное время, конкретную задачу, можно начать даже с 15 минут. И в эти 15 минут копайте свою тему, пробуйте что-то по-другому. Не обязательно пробовать сразу всё, что изучали. Выберите 1–3 новые практики и пробуйте их делать. Главное, делайте это каждый день. Такие маленькие шажки приведут к большим результатам. Подробнее об этом есть на вебинаре с Екатериной Ленгольд.
Боязнь ошибиться
Каждый из нас, думаю, сталкивался с боязнью принять решение, попробовать что-то в первый раз. А вдруг у меня не хватит компетенций и я приму неверное решение, подведу проект и своих коллег? Нужно помнить, что ошибки — это норма для процесса обучения. На них мы понимаем, как не нужно делать, а значит, теперь знаем, куда стоит идти. Вспомним историю изобретения лампочки. Эдисон провел около 2 000 опытов, прежде чем достиг успеха.
— Скажите, мистер Эдисон, каково это — терпеть неудачу две тысячи раз подряд, пытаясь создать одну лампочку?
— Молодой человек, — ответил Эдисон, — я отнюдь не ошибался две тысячи раз, создавая эту лампочку. Я обнаружил одну тысячу девятьсот девяносто девять способов, как не следует делать лампочку.
Информационная перегрузка
В книге «100 способов изменить жизнь. Часть 2» Лариса Парфентьева рассказывает о такой штуке, как информационная перегрузка. Со временем мы обрастаем знаниями, и это нам мешает быстро справляться с задачами, принимать решения, пробовать что-то новое и рисковать. Потому что перед тем как попробовать, мы начинаем анализировать, продумывать всё до мелочей и… в конечном итоге так и не пробуем.
Выход простой — начните хоть с чего-нибудь. Просто выберите первую же технику и попробуйте. Вы либо потом поймете, что ошиблись, — а это хороший результат, теперь у вас есть опыт и новая информация. В таком случае берите следующую технику, подход. Либо техника взлетит, и вы тогда тоже в выигрыше. Когда у самой писательницы возникает такой паралич, она говорит себе: «Да пофиг!» и начинает писать первое, что приходит в голову.
И вот ещё вам цитата Альберта Эйнштейна:
Все с детства знают, что то-то и то-то невозможно. Но всегда находится невежда, который этого не знает. Он-то и делает открытие.
Не хватает вдохновения
Лично меня вдохновляют коллеги, книги о тестировании и не только, выступления и изобретения коллег из другого города, другой страны. Хочется тянуться за такими людьми, творить, делать что-то полезное и не стоять на месте.
Во всё той же книге Лариса Парфентьева делится правилом успеха актера и режиссера Харольда Рамиса.
Найдите самого талантливого человека в комнате и, если это не вы, держитесь рядом с ним. Следуйте за ним повсюду. Старайтесь быть полезным ему. А если однажды вдруг окажется, что самый талантливый человек в комнате — это вы, ищите другую комнату.
Найдите то, что придает именно вам энергию, силу, заряжает вас на изменения, и питайтесь этим!
Если вы чувствуете, что вам нужен ментор, напишите на листочке список 20 человек, кто может подойти, пусть это будут даже самые известные тестировщики, свяжитесь с этими людьми. Кто-то из 20 точно не откажет вам!
Напоследок
Приведу ещё одну цитату из книги «100 способов изменить жизнь. Часть 2».
В людях, которые добиваются выдающихся успехов, нет ничего особенного, чего нет в любом человеке! Они такие же нерешительные, сомневающиеся в себе, рефлексирующие, они часто ошибаются, падают, грустят, сравнивают себя с другими, не знают, какое решение принять, и иногда им тяжело встать с постели. Единственное их отличие — они постоянно что-то делают, несмотря на все это.
Пробуйте новые техники, новые инструменты, изобретайте свои. Выберите самое будничное занятие и займитесь им осознанно. Меняйте процессы, пересматривайте свои взгляды. Придумайте какую-нибудь безумную и интересную идею и попытайтесь воплотить её!
Этой статьей мы заканчиваем годовой цикл «Календарь тестировщика», в котором 16 тестировщиков Контура рассказали о своих рабочих инструментах, практиках и процессах. Для многих из них это был новый опыт, интересный и полезный.
Мир тестирования не ограничивается только поиском багов, у него много граней и в этом мире можно и нужно экспериментировать. Спасибо, что были с нами :)
Список статей календаря:
Разумное парное тестирование
Обратная связь: как это бывает
Оптимизируй тесты
Прочти книгу
Тестирование аналитики
Тестировщик должен поймать баг, прочитать Канера и организовать движуху
Нагрузи сервис
Метрики на службе у QA
Протестируй безопасность
Узнай своего клиента
Разбери бэклог
Автор: ylian_demakova
