Разработка и Продажи

Продажи (падают из-за кулис на сцену и смирно лежат).
Разработка (выходит, спотыкается об Продажи и падает): Вот черт! Никак об Продажи!
Продажи    (поднимаясь): Мерзопакость какая! Отдохнуть не дадут! (Идут, спотыкаются об Разработку и падают). Никак об Разработку спотыкнулися!
Разработка (поднимаясь): Ни минуты покоя! (Идет, спотыкается об Продажи и падает). Вот черт! Никак опять об Продажи!
Продажи    (поднимаясь): Вечно во всем помеха! (Идут, спотыкаются об Разработку и падают). Вот мерзопакость! Опять об Разработку!
Разработка (поднимаясь): Хулиганство! Сплошное хулиганство! (Идет, спотыкается об Продажи и падает). Вот черт! Опять об Продажи!
Продажи    (поднимаясь): Это издевательство сплошное! (Идут, спотыкаются об Разработку и падают). Опять об Разработку!
Разработка (поднимаясь): Вот черт! Истинно что черт! (Идет, спотыкается об Продажи и падает). Об Продажи!
Продажи    (поднимаясь): Мерзопакость! (Идут, спотыкаются об Разработку и падают). Об Разработку!
Разработка (поднимаясь):  Вот  черт! (Идет, спотыкается об Продажи и падает за кулисы). Об Продажи!
Продажи    (поднимаясь): Мерзопакость! (Уходит за кулисы).
За сценой слышен голос Продаж: "Об Разработку!"
Занавес

P.S. Основано на вымышленных событиях

Связанные многочисленными ниточками

В больших компаниях и проектах, тем более распределенных, часто трудно согласовать работу между несколькими людьми и/или командами. Команда А ждет чего-то от команды Б, а та ожидает чего-то от А и от В, а В делает нечто важное, после чего нужно будет потрудиться еще нескольким командам. Это дополнительно усугубляется временными поясами, ролевыми разделениями, иерархией, личными отношениями им много чем еще.

Ниже — перевод статьи «Dependency Management in a Large Agile Environment», опубликованной компанией Salesforce.com. В статье рассказано, как компания решала проблемы взаимодействия команд разработки на крупном проекте. Многие подходы выглядят очень полезными.

Стоит потратить пять минут на чтение.

Краткий обзор
Департамент разработки Salesforce.com включает в себя более 30 Scrum-команд, совместно работающих над общим кодом в одной и той же ветке системы контроля версий. Статья описывает методы, используемые salesforce.com для масштабирования Scrum-подхода и для управления межкомандными взаимосвязями.

100500 конфигураций.

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

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

Сомневаюсь, что можно как-то окончательно решить эту проблему пока продукт развивается; можно только попытаться уменьшить опасность и критичность пропущенных проблем (и – снизить вероятность их пропуска, да).

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

4k+ знаков про ТО

Тестовое окружение – неизменный спутник тестирования. Неважно, какое ПО мы тестируем, без разницы, какую используем методологию: если мы выполняем тест, то, как минимум, нам нужен объект тестирования в подходящем состоянии. И как только этот объект появляется, появляется и оно, тестовое окружение.

Тестовое окружение (ТО) может готовиться заранее, а может «возникать» прямо в момент выполнения теста. Разным проектам нужны разные ТО, что естественно. ТО меняется вместе с развитием продукта, требованиями к нему, бюджетом и пониманием роли тестирования. Короче, как водится, идеального-вообще ТО не бывает, бывает – адекватное здесь-и-сейчас, решающее текущие задачи при данных обстоятельствах (ну и желательно с каким-то заделом на обозримое будущее).

Привет, Аноним в поисках вопросов

Внезапно мне пришёл комментарий:

Анонимный прокомментировал(а) ваше сообщение:
Добрый день, Павел.
Решил себя попробовать в тестировании, как мне казалась вещь очень интересная (знания брал из знаменитой для тестировщиков книги Савина), устроился в компанию, которая разрабатывает свой програмный продукт, проработав меньше месяца сбежал, т.к.было настолько скучно (тестирование - черный ящик, метод назывался "свободный поиск").
О чем спрашивать работодателя, когда принимают на работу? какие вопросы задавать по тестированию (чтобы потом не было так скучно)?

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

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

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

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

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

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

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

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

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

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

Баг для лога

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

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

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

Лог для бага

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

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

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

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

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

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

Итак.