Home

Автор: Акшай Ананд (Akshay Anand).

Оригинал статьи: https://blog.dotsandarcs.com/how-is-a-product-tested-in-the-real-world-16cc59935120#.m52yj1yzs

Перевод: Ольга Алифанова

Большая часть тестирования сейчас отдается на аутсорсинг. Я живу в Индии и полагаю, что большинство популярных веб-продуктов тестируются именно у нас. Мне повезло - недавно я получил возможность подключиться к тестированию реального продукта и отследить его путь от истоков до релиза.

Когда я учился, мне рассказывали о множестве видов тестирования. Я узнал о куче концепций - белый ящик, черный ящик, интеграционное тестирование, проверка исправности, тестирование ядра, компонентов, и так далее. Мы активно пользовались этими определениями, нанимаясь на работу. Если эти строки читают выпускники ВУЗов - готовьтесь, сенсационное сообщение! Реальный мир очень отличается от книг!

Итак, предлагаю вам свою историю и свой опыт по тестированию реального коммерческого продукта. Сразу скажу, что "минутка час бережет" - отличный лозунг тестировщика. Тестирование должно начинаться как можно раньше - в идеале, с первого же дня старта проекта. Хорошие методики тестирования должны быть гибкими и подстраиваться под ход разработки. Наша команда приступила к тестированию с первого же дня.

Хм-хм. А что проверять-то в первый день? Еще ничего не сделано, нет никакой функциональности, так что же нам тестировать?

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

Как только стартовала разработка, можно приступать к тестированию функциональности продукта. Тоже очень важная стадия тестирования с точки зрения тестировщика: к каждой функции может относиться множество различных сценариев. Разработчик проверит только наиболее базовый из них, а тестировщик должен убедиться, что абсолютно все сценарии в рабочем состоянии.

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

"Да мне плевать, что на твоей машине все работает! Мы продаем не твою машину!" ~ Vidiu Platon.

Я уверен, каждому из вас эта фраза близка) 

Дальше наступает стадия тестирования производительности. В нашем случае мы приступили к нему, когда приложение начало стабилизироваться. Помнится, бывало, что десять человек, сидя в офисе, пытались одновременно загрузить файл в систему - просто чтобы посмотреть, выдержит ли сервер нагрузку, а если выдержит, как долго будут грузиться файлы. Со временем у нас появились матрицы производительности, которые обновляются раз в неделю.

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

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

Вот чем я занимался. Я тестировал реальное приложение в течение его полного жизненного цикла в компании dots&arcs. Сейчас оно в релизе, им пользуются живые люди. Не то чтобы я хвастался, но считаю, что мы здорово справились с работой. Мы наблюдали приложение с рождения, и помогли ему вырасти в нечто замечательное - это отдельный замечательный опыт.

"Качество никогда не бывает случайным. Это всегда результат интеллектуального труда".

Я узнал, что да, тестирование - не ядерная физика, но выучить его по книгам просто невозможно. Как минимум, книги не дадут вам представления, как это делается в реальной жизни. Тестирование - это в первую очередь здравый смысл. Хороший тестировщик размышляет, как именно живой пользователь может использовать приложение, а затем проверяет свои догадки. Тестирование требует острой наблюдательности и бесконечного терпения. Если вы думаете, что я знаю какой-то секрет хорошего тестирования, то его нет!

В этом я похож на отчима Панды По - мистера Пинга. У него нет никаких секретных ингредиентов для его супа с лапшой - он просто верит, что этот суп особенный :).

Обсудить в форуме