Всего лишь пара изменений

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

Но не всегда тестировщик заранее знает, что что-то в поведении продукта изменится. Приходит он на работу, берет свежий билд приложения и видит, что добавились/пропали/переехали контролы в GUI. Или поменялась очередность шагов визарда. Или изменилась давно привычная логика работы. Да мало ли что. А чтоб такие изменения планировались, он и не слышал. Баг писать? Или так и должно быть теперь?

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

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

И вопрос - как эти изменения контролировать?

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

Баг для лога

В предыдущем посте речь шла о пользе чтения логов при исследовании и описании дефектов ПО. Сегодня я хочу зайти немного с другой стороны.

Логи, безусловно, помогают исследовать поведение приложения, но в то же время логи – часть тестируемого продукта. То есть – их тоже можно тестировать. И вокруг них тоже могут водиться баги, а как же.

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

Лог для бага

Опытным тестировщикам не нужно рассказывать о важности и пользе логов. Логи помогают исследовать проблемы, с их помощью быстрее и точнее локализуются дефекты, они могут рассказать, что происходит на самом деле (а не должно, как нам кажется, происходить).

Логи в чём-то подобны скриншотам – это такое же документальное и объективное свидетельство о работе приложения, с которым нет смысла спорить. Его можно обсуждать, изучать, уточнять сопутствующие условия, но факт есть факт, и отмахнуться от него не получится.

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

Калибан с зеркалом

Уточняя цитату про Калибана, перечёл предисловие к "Портрету Дориана Грея". Не удержался и перетолмачил это предисловие в иных терминах. Получился своеобразный манифест о тестировании :)

Я рекомендую сперва прочитать оригинал, а потом уже мои вариации на тему. Впрочем,  порядок чтения не так уж важен.

Итак. 

Границы и края

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

Так, приглядываясь к рискам, которые могут возникнуть в работе, проще всего сперва посмотреть на крайние значения. Кстати нередко вокруг таких крайних значений ломаются копья в различных спорах на тему тестирования (и вообще разработки ПО). Несколько примеров:

Все тесты должны быть описаны так, чтоб их мог выполнить человек с улицы

против

Мы тестируем, а не мараем бумажки 

40 и 90

Как и многие до меня, однажды я задумался о звучании чисел 40 и 90 в русском языке. Почему они - "сорок" и "девяносто", а не "четыредесять" и "девятьдесять"? В том же английском языке все честно: forty и ninety. И у нас вроде бы должно быть так же, если сравнивать с другими числами: "пятьдесят", "семьдесят". Что не так с этими двумя?

Наверняка я не знаю, конечно; разные есть версии на этот счет. Приведу те, что мне самому кажутся интересными и правдоподобными.

40. В христианстве вообще и православии в частности число 40 играет заметную роль - начиная с потопа, длившегося сорок суток, и заканчивая Христом, проповедовавшим сорок месяцев. Православие, как известно, пришло на Русь из Византии, и долгое время службы велись на греческом языке. Оттуда и позаимствовалось звучание числа "четыредесять", и вытеснило постепенно родной вариант.

90. Тут тоже без церкви дело не обошлось, но в несколько ином качестве. В течение долгих веков церкви отдавалась десятина. То есть десять из каждой сотни. Отсюда и пошло выражение "девятьдесять, но сто", постепенно редуцировавшееся до знакомых "девяноста".

Впрочем, речь не о числах, интересно другое. Замеченная "странность мира" (нелогичные названия чисел) позволила по-новому взглянуть на числа и связь их названий с историей страны. То есть, заметив странное и покопав в этом направлении, я узнал что-то новое.

Странности мира - отличный источник знаний о мире. 

Дефекты продукта - отличный источник знаний о продукте. 

Между роботом и обезьяной

Есть две точки зрения на тестирование, с которыми в свое время сталкивался практически каждый тестировщик. Первая - что тестировать может любой, ума тут не надо: сел и прокликал. Вторая - что вообще не надо тестировать людьми, надо просто автоматизировать все тесты и жить счастливо. Эти подходы, пожалуй, несколько, гм, наивные (кто-то все равно должен эти тесты придумать и описать; кто-то должен приглядывать за автотестами и анализировать результаты их работы, и так далее), но я сейчас не об этом. На деле, мне кажется, это одна и та же точка зрения. В обоих случаях как минимум предполагается, что можно описать тесты таким образом, что их успешно выполнит любой - хоть студент, хоть скрипт. Или в других терминах - хоть обезьянка, хоть робот. Года полтора назад Макс cartmendum Дорофеев устраивал доклад-состязание "Обезьянки против Роботов"; если вдруг кто не видел - рекомендую к просмотру. В докладе отлично сформулирована разница между этими "крайностями": "Обезьянки умеют немножко смотреть по сторонам. Роботы не могут смотреть по сторонам. Они могут смотреть в точку, но быстро и долго". Это существенное различие, которое позволяет в разных ситуациях выигрывать то Обезьянкам, то Роботам. 

На самом же деле ни Обезьянки, ни Роботы сами по себе практически ничего не умеют. Они не могут придумывать тест-кейсы и программировать роботов. Они способны учитывать только формальный критерий, описанный в тест-кейсе или скрипте, они не обращают внимания на контекст. Ну, почти не обращают: Обезьянки все-таки немножко глядят по сторонам и иногда замечают странное не предусмотренное тест-кейсами. Они не умеют задавать вопросы и разговаривать (хотя бы с гуглом). Они не стремятся понимать, как работает приложение, и почему после нажатия на кнопку с неба падает (или не падает) банан. Они не отвечают за результат. Чаще всего они не могут сообщить дополнительные сведения, если что-то сломалось. Они знают только о приложении и не работают с остальными составляющими продукта. Они ничего не помнят. У них нет своих суждений, предположений и ожиданий; есть алгоритм и результаты - ожидаемый и реальный. 

Коротко говоря - они не умеют думать. Роботы - совсем, Обезьянки - почти. И в этом смысле тестировщик круче и Обезьянки, и Робота в равной степени. Ну разве что Робот быстрее кликает. Зато тестировщик способен понять, что тут кликать вообще незачем. 

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

Если перефразировать слова Макса, то можно сказать, что тестировщик смотрит по сторонам, и делает это быстро и долго. Нужно смотреть "быстро", чтобы замечать больше дефектов (и не только в продукте :)). Нужно смотреть "долго", то есть постоянно, на всех этапах разработки. Не случайно одна из главных бед тестировщика - "замыленый взгляд".

Удачи вам, верных Роботов, смышленых Обезьянок и ясного взгляда.

О тестировании документации

Documentation is like sex: when it is good, 

it is very, very good; and when it is bad, 

it is better than nothing.

Dick Brandon

Когда заходит речь о тестировании, обычно обсуждается тестирование приложения в том или ином виде. Функциональное тестирование, тестирование безопасности, нагрузочное тестирование, тестирование требований - все это относится к приложению. Это действительно важные аспекты поведения продукта, и количество уделяемого им внимания вполне обосновано. Тестирование документации, поставляемой вместе с приложением (неважно, каким именно способом - в виде книжки, PDF файла или базы знаний на сайте), нередко проводится по остаточному принципу. С одной стороны этот подход делает актуальной фразу вынесенную в эпиграф. С другой - соображения, высказанные в этой фразе могут стать причиной, почему документация так плоха.

Отбросим случай, когда документация не тестируется вообще никогда и никем. Это крайний и маловероятный вариант, к тому же обсуждать тут особо нечего. Как мы тестируем документацию, если уж до этого дошли руки? 

Обычно документация не обновляется вся целиком. Появляются новые возможности в продукте, их описание добавляют в документацию, а потом назначенный человек (или несколько) проверяет, что "все в порядке". Это неплохой вариант, когда проверку выполняет опытный человек, хорошо знакомый с продуктом и прочим контекстом (предметной областью; языком, на котором написана документация; целевой аудиторией и так далее). Проблема в том, что часто нет никаких формальных подходов к выполнению таких проверок. Человек читает документацию, по сути - проверяя, не зацепится ли взгляд за что-то странное. Зацепился - хорошо: обсудил с окружающими, открыл баг. Не зацепился - никаких гарантий, что проблем действительно нет. 

М.Болтон: Оценка проекта и Черные Лебеди. Часть 5. Оценка тестирования.

Вольный перевод статьи Майкла Болтона Project Estimation and Black Swans (Part 5): Test Estimation

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

Давайте действовать как тестировщики – будем задавать вопросы.

Существует ли вообще такая штука, как проект тестирования? В частности, может ли проект тестирования существовать независимо от проекта разработки?

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

М.Болтон: Оценка проекта и Черные Лебеди. Часть 4.

Вольный перевод статьи Майкла Болтона Project Estimation and Black Swans (Part 4)

В нескольких последних статьях исследовательская автоматизация подсказала некоторые интересные идеи насчет динамики проектов и их оценки. Какую пользу можно извлечь из этих математических экспериментов?

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

Похоже, математика поддерживает идеи, расхваливаемые энтузиастами Agile, гуманистами и мыслителями: получайте обратную связь быстро и часто. Глядя на последнюю модель - меньше задач и более короткие проекты - мы можем предположить, что чем короче и управляемей проект, тем меньше шансов у Черного Лебедя нанести вред любому отдельно взятому проекту.