Новая версия доступна. Обновить?

В жизни приложений, помимо "просто работы", есть масса интересных, пусть и относительно редких событий.
Приложение должно корректно устанавливаться – и нам нужно проверять это.
Приложение должно корректно удаляться (а вдруг!) – и нам нужно проверять это.
Приложение должно корректно обновляться до новой версии – и нам… подождите-подождите… нужно проверять это!
Об апгрейдах и пойдет речь.

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

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

Но не всегда тестировщик заранее знает, что что-то в поведении продукта изменится. Приходит он на работу, берет свежий билд приложения и видит, что добавились/пропали/переехали контролы в 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, гуманистами и мыслителями: получайте обратную связь быстро и часто. Глядя на последнюю модель - меньше задач и более короткие проекты - мы можем предположить, что чем короче и управляемей проект, тем меньше шансов у Черного Лебедя нанести вред любому отдельно взятому проекту.

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

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

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

Оставляйте проблемные задачи незавершенными; допускайте потерю функциональности

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

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

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

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

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

Линейная модель, которую я предлагал, не соответствует реальности в нескольких аспектах, но до сих пор я особо не говорил об этом. Вот лишь несколько недостатков этой модели.

• модель неявно предполагает, что все задачи должны выполняться в определенном порядке.
• модель неявно предполагает, что все задачи одинаково важны.
• модель не учитывает информацию о зависимостях и взаимозависимостях между задачами.
• модель предполагает, что, столкнувшись с Потраченным Утром, Потерянным Днем или Гадким Утенком, мы не можем (и не будем) ничего с ними сделать.

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

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

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

В последние месяцы в сети активно обсуждалось оценивание:

• Ward Cunningham написал в твиттере: "Оценивание - выдуманная проблема, на решение которой профан тратит десятки дней"
• Pradeep Soundararajan опубликовал в блоге развернутую статью, посвященную оценке затрат на тестирование.
• Некто, назвавшийся Nathaniel'ем, изложил интересную точку зрения на успешные оценки на сайте Terralien.
• Jens Schauder опубликовал 8 причин, почему оценки слишком низки.
• Andre Dhondt недавно подключился к спору со статьей “Оценки ведут к убыткам, резервы приносят пользу”. (Вообще-то я не согласен. Резервы не приносят пользу, а вносят некоторый вклад в создание благоприятных условий, позволяющих создать нечто полезное. Достаточное количество резервов позволяет снизить угрозы.)

Все это сподвигло меня опубликовать результаты некоторых численных экспериментов, начатых в ноябре 2009-го и основанных на мысленном эксперименте, придуманном Джеймсом Бахом (James Bach). Эта работа совпадает по времени с Лебединой Песней, колонкой для Better Software, в которой я обсуждал книгу Талеба (Nassim Nicholas Taleb) "Черный Лебедь".

Черный Лебедь - невероятное и неожиданное событие, меняющее наше представление о реальности и обладающее тремя качествами.