Научить тестировать за 1,5 часа. Эксперт из Новосибирска Алина Жердева побывала в ИТ-парке

25 октября в ИТ-парке прошел мастер-класс по тестированию и юзабилити. Наш эксперт Алина Жердева специально прилетела из Новосибирска, чтобы поделиться опытом с челнинскими программистами и всеми, кому интересно делать качественный продукт.  Одним из важнейших направлений при разработке программных продуктов является их тестирование. Чтобы узнать, насколько удобен, к примеру, сайт для пользователей, надо спросить об этом у них самих. Конечно,  это кропотливая работа, отнимающая много сил и времени у разработчика. Но благодаря тестированию можно проверить, имеет ли приложение ошибки в программном коде, определить максимальную нагрузку на сервер и т.д. В конечном итоге владелец ресурса может быть уверен в качестве своего продукта.  Алина Жердева поделилась со слушателями 6-летним опытом  тестирования и секретами создания успешного продукта. Пересказывать нет смысла. Поэтому предлагаем раскадровку мастер-класса.  О себе. «Меня зовут Алина. Я из славного города Новосибирск. Там теплее, чем у вас, как ни странно. По образованию я программист, закончила Новосибирский государственный технический университет. После института поняла, что программистом я не буду никогда. Но бэкграунд (прим.: накопленный жизненный опыт, формальное и неформальное образование) был достойный, помогающий в работе. 6 лет проработала тестировщиком, через какое-то время начала заниматься юзабилити-тестированием. Понравилось, забросила функциональное тестирование просто потому, что больше захотелось общаться с людьми, а не с машинами. Склад характера у меня такой. После этого поняла, что юзабилити-тестирование – это, конечно, хорошо, но должно быть продолжение. Начала заниматься проектированием интерфейсов и продуктовой аналитикой, по сей день этим занимаюсь.  Так получилось, что практически год была руководителем стартапа med-room.com в Новосибирске и Барнауле. Я оттуда ушла, но он успешно работает». Бац-бац, и в продакшн! «По моему опыту, когда начинается новый проект, его хочется быстро сделать: запустить и сразу получить много денег. Персонаж на слайде из South Park (прим.: американский мультсериал). Рекомендую посмотреть 1 серию последнего сезона - для стартаперов то, что надо. Такая система, конечно, хорошая, ее очень хочется использовать, но поговорим о том, что тестирование в этом цикле все-таки нужно». Тестирование по стратегии черного ящика. «Для старта я рекомендую начать со стратегии черного ящика. Черный ящик – это наша программа, мы не знаем, что происходит внутри, мы не разбираем сам код, хотя многие тестировщики это делают. Смотрим, какие нам нужны входные данные и какие данные мы должны получать на выходе. Каким образом проверяется? Для этого пишется тест-кейс. Способов и видов тестирования очень много. Начинающим тестировщикам я рекомендую книгу Романа Савина «Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах». В ней все разложено по полочкам, написано простым языком, рассказано про все виды тестирования, которые существуют. Я про все рассказывать не буду, это долго. Расскажу про то, с чего имеет смысл начинать».  С чего начать?  Для начала мы определяем функции продукта, если это первый «подход к снаряду», то имеет смысл описать все функции: что умеет ваш продукт, чтобы ничего попутно не забыть.  После этого пишется тест-план – это планирование тестирования в процессе разработки и планирование тестирования как такового.  В тест-плане есть тест-кейсы. Для начала необходимо написать тест-кейсы к основным функциям. Business Critical функции – описать. Пройтись по этому плану, пройтись по этим тест-кейсам, протестировать.  Как только у вас появляется новая функциональность, вы начинаете весь этот цикл сначала – вы описываете новую функцию, которая появилась, включаете ее в тест-план, пишите для нее тест-кейсы и тестируете. Чем полезны тест-кейсы? Они позволят вам не забыть что-нибудь проверить. Вы будете знать, что у вас есть список функциональности продукта, и вы не забудете его протестировать. И у вас будет больше уверенности в том, что ваш продукт работает правильно, так, как вы задумали».  Кто должен тестировать?  «Не разработчик! Почему не разработчик? Во-первых, это его детище, как же он сам будет это все ломать?! Во-вторых, разработчик знает, где может сломаться, поэтому он подсознательно будет обходить эти места, придумывать такие тесты, чтобы эти места обходить. Поэтому тестировать должен человек, который не имеет отношение к написанию кода этого продукта. Либо это тестировщик – специальный человек, который пишет тест-планы, пишет тест-кейсы, тестирует, вкатывает багги разработчикам, ругается с разработчиками, что это баг, а не фича. Либо, если это начинающий проект, студенты или сторонние люди. В своем стартапе я была тестировщиком, так как нужен был человек с техническим складом ума. Тестировщик – это не тот человек, который ломает, это тот человек, который смотрит, чтобы все работало так, как запланировано. Когда, еще работая тестировщиком, я приходила на собеседование и меня спрашивали: «Разработчики написали, такие умницы, а вы приходите и ломаете, топчетесь там своими грязными ногами». Я говорила: «Ребята, я же делаю мир лучше! Если мы выпустим качественный продукт, который будет отвечать заявленным требованиям, это же хорошо».  Тест-план – что это такое? «В тест-плане описывается, какой конкретно продукт мы тестируем, то есть краткое описание, чтобы не забыть - особенно, если у вас заказная разработка или у вас их много.  Если сюда напишите пару слов о бизнес-целях этого продукта, чтобы просто держать их в голове во время тестирования, будет тоже хорошо.  Пишем цель тестирования, то есть, какие функции мы хотим проверить. Если вы тестируете систему биллинга для интернет-провайдера – это будут, например,  подключенные услуги и их корректная работа; если деньги списываются, то они списываются правильно.  После этого мы описываем, как мы будем тестировать, то есть методы тестирования. Определяем, какие функции мы тестируем, в каком порядке. Те функции, которые мы в пункте 2 описали, приоритезируем и в зависимости от приоритета проверяем. Практика показывает, что все происходит в режиме цейтнота, времени никогда не хватает, поэтому первыми проверяются те, что критичны для бизнеса, то, что должно работать в обязательном порядке. Затем мелкие фичи, переходы. На мой взгляд, тестирование того, поехала верстка или не поехала – это стоит повыше поднять. Потому что если у вас поехала верстка, не будут нажиматься кнопочки в нужный момент; если поехала верстка, это будет создаваться соответствующее впечатление о вашем продукте, которое вам не очень нужно.  После того, как вы эти функции приоритезировали, вы начинаете писать на эти функции тест-кейсы и описываете тестовую среду – какая программная среда вам нужна для того, чтобы запустить тесты».   Из чего состоит правильный тест-кейс? «Для него пишется название. Чтобы вам не путаться, когда их большое количество, имеет смысл группировать их по каким-то функциям (1 функция – список тест-кейсов).  Описание того, что вы хотите проверять в этом тест-кейсе.  Предусловия – это то, что должно быть в системе перед тем, как этот тест будет выполняться. Например, вам надо проверить, что у вас списываются деньги со счета. В качестве предусловия эти деньги у вас на счете должны быть. Это надо описать, чтобы потом не забыть.  Описываются действия, которые должна делать система – пошаговые действия.  Постусловия – в каком состоянии будет находиться система после того, как вы прогнали тест. Например, у вас в базе на запуск теста 200 рублей должно быть, после того, как прогнали тест на счету должно остаться 100 рублей. Эти условия надо писать, потому что эти действия могут повлиять на выполнение следующего теста.  И последнее – это описывается ожидаемый результат. Если мы списываем деньги со счета, списали 100 рублей, значит ожидаемый результат – сумма на счету  должна уменьшиться на 100 рублей. После проверки тест-кейса, есть еще 2 поля – это фактический результат (пишите то, что реально получилось) и графа Pass/Fail (пройден тест или нет). Мы идем в баг-трекер и описываем там баг, причем описываем, что мы делали, что мы ожидали и что у нас получилось. Отправляем это разработчику, который идет все править. Так вы прогоняете весь список тестов по вашему тест-плану и по тем тестам, которые Fail, вы пишите баги, пишите разработчику, что что-то не соответствует ожидаемому результату. После этого разработчик правит, вы смотрите то, что у вас было Fail, и перепроверяете по тем же самым тест-кейсам. Если тест прошел - хорошо, не прошел – снова возвращаете разработчику».  Сколько тестов нужно? «Естественно, все очень сильно зависит от системы, от размеров, от функциональности, от того, насколько она наворочена. Можно разделить тест на классы по эквивалентности. Два тест-кейса являются эквивалентными, если ожидается, что программа будет обрабатывать их одинаковым способом.  Например, вычисление факториала числа. Есть допустимые значения чисел для этого теста – это целые положительные числа и ноль. То, что мы на входе подаем и то, по каким данным мы получим результат нормальный. Есть недопустимые значения – это все нецелые и отрицательные числа, на которые наша система должна нормально среагировать и сказать: «Парень, ты не прав и ввел что-то неправильное». То есть система не должна «упасть», сломаться, она должна адекватно на него среагировать.  Вам не нужно перепроверять всё – в чем плюс разделения на классы эквивалентности. Если вы посчитаете факториал пяти, то вам не нужно считать факториал шести, семи, восьми и т.д. Все эти вычисления будут проводиться одинаково. Почему здесь стоит отдельно ноль? На границе классов эквивалентности, то есть целые положительные числа и целые отрицательные числа, чаще всего, меняется поведение системы, поэтому эти пограничные случаи нужно обязательно проверять. Ввести 0 – то есть мы проверяем граничные значения, ввести 10 – целое число, ввести -5- отрицательное и ввести нецелое число – 3,5».  Сколько времени тратится на тестирование? «Здесь я вас немножко расстрою, потому что, как показывает опыт, оно примерно равно времени разработки. Способы его ускорить? Например, писать тест-кейсы. Если у вас есть команда тестировщиков или у вас несколько человек тестирует, то написанные вами тест-кейсы, если вы сейчас занимаетесь другой задачей, можете отдать другому человеку и этот человек будет спокойно сидеть и по ним проверять, ему ничего не надо сочинять - он просто проходится по твоим тестам и смотрит. С другой стороны, если появилась какая-то новая функциональность, естественно, придется писать самому. В этом случае еще помогает автоматизация тестирования. Но это на старте очень долго. Нужно настроить тестовую среду, нужно настроить так, чтобы эта тестовая среда дружила со средой разработки, адекватно туда «ходила», запрашивала базы и т.д. Нужно написать и проверить сами автотесты Не быстро на старте, скажу сразу, но потом, по моему опыту, дает выигрыш по времени. Тестировать лучше небольшими итерациями. Если сразу делаете огромное количество функциональности, заваливаете своего пользователя супер-мега фичей, нужно понимать, что на тестирование этой фичи уйдет очень много времени. Это не только время самого тестирования, здесь учитывается время, когда тестировщик ждет, когда пофиксят баг. То есть он протестировал, отдал разработчику, разработчик пофиксил, отдал тестировщику, тестировщик перепроверяет, снова отдает разработчику, если что не так. И вот этот цикл продолжается, пока мы не будем удовлетворены качеством. Часто бывает так, что есть несколько незакрытых багов к моменту запуска – просто дедлайн и невозможно ждать. Это нормально, этого не надо пугаться.  Важно, чтобы те ошибки, которые остались у вас нерешенными, не влияли на основную функциональность. Единственное, не позволяйте им накапливаться в больших количествах, чтобы не произошел прорыв. Не забывать про регрессионные тесты, то есть каждый раз, когда у вас выпускается новая функциональность, перепроверять бизнес-критичный функционал. Время надо изначально закладывать в тест-план. Это примерно половина времени разработки. Приходить к тестировщикам и задавать вопрос: «Сколько вам времени нужно на тестирование?». Григорий Бакунов, директор по распространению технологий «Яндекса», на вопрос: «Как вы рассчитываете время на разработку?», ответил: «Когда мне говорят, что на это нужно 3 дня, я умножаю на 3, и заказчик на это нормально реагирует. Если разработчик говорит 3 месяца, а мы заказчику 9 месяцев, это вызывает подозрение. Поэтому я считаю так: все равно появятся нюансы в аналитике, появятся «хотелки» бизнеса, которые необходимо срочно внедрить. Я беру время, которое мне сказал разработчик, считаю его радиусом окружности, потом вычисляю срок как половина длины окружности (радиус*Пи) плюс прибавляю 2 недели». После этого ему задают вопрос: «Григорий, а почему 2 недели?». Григорий: «Когда разработчик за 2 недели вообще не написал ни одной строчки кода, то в принципе за 2 недели я сам на коленке могу собрать любой продукт». Эта формула реально рабочая. Мы, кстати, у себя проверяем ее на работе, насколько она рабочая, пока попадаем». Какой эффект можно получить от тестирования? «- Снижение количества претензий к качеству продукта. Многие боятся говорить, что у них где-то были баги, что-то «падало». Лучше напишите об этом честно, получите лояльность пользователей, их отзывы, потому что пользователи увидят, что вы работаете и будут писать отклики. Багги есть в любой программе. - Сокращение ресурсов на исправления. Да, написание тест-кейсов, тест-планов, написание автотестов, если вы решите заниматься автоматизацией занимает много времени. Но тестирование сокращает ресурсы на исправление багов. Гораздо проще поправить ошибки до того, как вы выложите продукт в продакшн, чем когда вам написала разгневанная толпа пользователей, что сделали какую-то ерунду. Например, это актуально в AppStore, где 10 дней проверяется приложение. Вы выложили приложение. У вас там баги, вам написали, что у вас там всё «упало», вы это пофиксили за час и 10 дней ждете, чтобы выложить это снова. То есть вы теряете кучу времени, вы теряете кучу лояльных пользователей, большую часть своей аудитории.  - Сокращение ресурсов на сопровождение. Особенно это актуально для больших проектов, когда у вас есть отдел поддержки (support), который принимает звонки от пользователей. Я сейчас работаю над интернет-банком, у нас есть отдельный отдел поддержки, куда звонят пользователи и говорят, что мы не может что-то сделать. Если бы мы это не проверяли, у нас бы support повесился бы, наверное, на работе. Потому что и так звонят много, особенно если что-то переделывается с точки зрения интерфейса, а если еще что-то будет ломаться, поддержка просто будет в шоке. - Улучшение репутации. Качественные продукты найдут положительный отклик  людей, а значит, улучшится репутация. Как-то мы выпускали одно приложение для Windows Phone, очередное обновление. Мы что-то пофиксили, баги пофиксили, радостно выложили это. Кажется, 5 дней оно там проверялось, после чего начинается сыпаться огромное количество негативных отзывов, что «у вас приложение падает». Как оказалось, тестировщики не проверили, что при установке приложения все хорошо, а при обновлении оно «падает» после запуска на старте и ничего нельзя сделать, помогает только переустановка. Самое ужасное, что в Windows Store отвечать пользователям нельзя. У нас была паника. Конечно, через 5 дней мы выложили правильную версию. Это был хороший опыт, потому что такие вещи тоже надо проверять. - Уменьшение времени на введение нового сотрудника. Тестируя по тест-кейсам, человек сможет быстрее изучить продукт.  Можно привлекать студентов».   Презентация здесь: http://www.slideshare.net/ssuser1e6dd3/1-40818705