«Календарь тестировщика» за декабрь. Попробуй другой подход

    В Новый год многие подводят итоги, анализируя прошедший год, вспоминают все свои результаты и строят планы на будущее. В 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
    Протестируй безопасность
    Узнай своего клиента
    Разбери бэклог

    Контур
    110,00
    Делаем веб-сервисы для бизнеса
    Поделиться публикацией

    Комментарии 15

      0

      По-моему в тестировании достаточно следовать всего одному принципу — "Все, что может быть автоматизировано, должно быть автоматизировано"… тогда и другие подходы придумывать не придется… некогда будет.


      Сейчас уже наверное можно автоматизировать любое или почти любое тестирование.

        0
        Сейчас уже наверное можно автоматизировать любое или почти любое тестирование.


        Тестирование это чуть сложнее, чем клики. Всё еще не автоматизируется «думать» и «оценка рисков». Плохо поддается автоматизации стандартная проблема тестовых фреймворков — эффективность тестового набора.

        Проектов по тотальной автоматизации с не отрицательным ROI всё еще меньше, чем один на десять.

        Я допускаю, что «тотальная» автоматизация возможна в заказной разработке, где клиенту продаются часы, а не качество, но если вы автоматизируете тестирование своего продукта за свои деньги, то заявления будут намного менее безапелляционными.
          0

          "Думать" да, не автоматизируется, а "оценка рисков" автоматизируется вполне успешно сплошь и рядом.


          Где вы увидели у меня призыв к немедленной тотальной автоматизации? Я написал "ВСЕ, что МОЖЕТ быть автоматизировано".


          Насчет сопоставления стоимости ручного и автоматизированного тестирования я не понял. Вы предполагаете что автоматизированный сценарий тестирования интерфейса, написанный с использованием какого-нибудь Selenium-а, будет в долгосрочной перспективе в эксплуатации обходиться дороже, нежели ручной тестировщик?

            0
            Я не предполагаю, я точно знаю, что в 4 случаях из 5 автоматизированный сценарий дороже, чем ручной тестировщик. Потому как к этому сценарию прилагается «автоматизатор», который, как правило, умеет писать сценарии, а пользу — не умеет.
              0

              Какой такой "автоматизатор"? Я как разработчик пишу сначала тесты, потом код. Когда начинается проект, я настраиваю новое задание в CI сервисе (Jenkins), которое загружает мой код из GIT репозитория после каждого его обновления, и автоматически собирает приложение, запускает тесты, загружает данные и снова запускает тесты. При этом мне не нужен никакой специальный дополнительный автоматизатор. Один раз настроил и оно работает. Один раз написал тест, и он при каждом прогоне будет гарантированно выполняться и проверять продолжает ли приложение работать как ожидается.


              Когда мы обнаруживаем какой-то новый сценарий использования приложения, для которого у нас еще нет теста, мы просто добавляем новый тест к существующим наборам.


              У меня сейчас в бэкенде, в проекте, который стартовал два месяца назад, только модульных тестов 1100. Больше сотни тестов REST API, которые ежедневно выполняются по нескольку десятков раз. Какая тут мне может быть польза от ручного тестировщика?


              Когда я занимался фронтендами, у меня в небольшом относительно проекте было порядка 50 e2e сценариев (Selenium), которые проверяли основную функциональность SPA Web приложения. При разработке, в течение дня я иногда запускал эти сценарии по нескольку десятков раз. Если бы я делал это руками, у меня бы дня рабочего не хватало чтобы только тесты прогнать. Вы правда думаете что ручной тестировщик сможет адекватно протестировать 50 сценариев, 10 раз за день?

                0
                Какая тут мне может быть польза от ручного тестировщика?


                Для тестирования апи, как правило, выделенный тестер не нужен. Но область знаний того самого «ручного» тестировщика помогла бы тратить меньше времени на тесты бесполезные и больше — на полезные.

                Для такого небольшого приложения, где можно быстро написать 50 e2e кейсов и запускать их настолько регулярно в режиме отладки тестировщик мог бы спросить, а нужны ли тесты вообще…

                Кстати, на текущем уровне развития автоматизации 50 тестов через браузер вручную прогнать быстрее живым человеком.

                Вы поменяли предмет спора. Я не говорил, что автоматизация не нужна. Я говорил, что сейчас закодированные тесты тестирование заменить не способны в большинстве случаев.
                  0
                  Кстати, на текущем уровне развития автоматизации 50 тестов через браузер вручную прогнать быстрее живым человеком.

                  Вы это серьезно? Продемонстрировать можете? У меня вот есть видео с куском из 22-ух e2e тестов, выполняемых на почти старинном ноутбуке, записанное год назад. Selenium год назад делал это за 34 секунды. Можете показать что-нибудь подобное, что делает ручной тестировщик быстрее?

                    0
                    Легко.
                    *Видео, где я 20 секунд смотрю дифф кода, потом прогоняю руками 1 кейс, который действительно нужно прогнать*

                    Я не собираюсь соревноваться с машиной в том, в чем она явно лучше.

                    Еще раз, в чем предмет спора?

                    Вы считаете, что автоматизировать уже можно всё? Как долго вы будете писать скриншотные тесты, которые не пропустят все ошибки верстки, которые пропустит тест с видео? Еще примеров того, что автоматизировать нельзя? Сколько человеко-тысячелетий потрачено на код, который разработчики писали, забыв спросить «а зачем?»…
                      0

                      Ошибки верстки для проектов, в которых я принимал участие, составляли не более 3% от общего объема проблем. Причем часть из них отлично обнаруживается в процессе функционального тестирования тем же Selenium-ом (наложение-перекрытие элементов управления). Ну а "Pixel Perfect" для меня неактуален. Я в таких проектах участия не принимаю

                        0
                        Тем не менее позволяете себе заявления:
                        Сейчас уже наверное можно автоматизировать любое или почти любое тестирование.


                        Я бы согласился с «нужно пытаться» или «стоит прикладывать усилия». Но «уже можно».
                          0

                          Поэтому я и написал "уже наверное можно", а не "уже точно можно". Я считаю что в задачах, которые относительно недорого формализуются нет смысла полагаться на ручной труд. Это заведомо проигрышная стратегия.

            0
            Почему-то всё еще бытует заблуждение, что автотесты находят баги. Хотя на самом деле автотесты находят небаги.
            Баги только люди могут найти.
              0

              Тесты, не для того, чтобы находить ошибки, а для того, чтобы быть уверенным в том, что код ведет себя так, как предполагается. Особенно это актуально в случаях, когда требования заказчика часто меняются, и код приходится дорабатывать и рефакторить.


              Не смотря на это я не раз имел возможность убедиться в том, что и автотесты находят ошибки. Если вы не сталкивались, то существуют случаи, когда ошибка проявляется не каждый раз, в лишь при некоторых обстоятельствах. При этом у автоматических тестов, которые запускаются десятки раз в сутки, шансов обнаружить такую ошибку соответственно в десятки раз больше, нежели при ручном тестировании.

                0
                Ну, зачем нужна автомагическая регрессия знают уже почти все. И continuous testing тоже уже худо-бедно приживается.

                Но расследовать все равно же руками приходится. Ибо павший тест не обязательно может быть багом. Test fragility тоже никто не отменял.
          0
          Мимо, комментарий выше.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое