Сегодня Виктория Слинявчук, специалист в области тестирования ПО, расскажет всю правду о нелегкой доли Agile-тестировщика :)
На одном из тренингов меня спросили: «Как выжить тестировщикам при Agile?». Думаю, ответ на этот вопрос можно найти в книге Гривз и Лэинг «Growing Agile». Agile-тестирование – это не просто такое же тестирование, как обычно, только в спринтах. Agile-подход должен изменить весь ход мыслей команды.
Мы больше ценим тестирование во время, чем тестирование в конце
Традиционно тестирование понималось как фаза, которая следует за разработкой. Однако в Agile-разработке тестирование – это деятельность, которая должна произойти, наряду с программированием, написанием документации и всем прочим.
Если на вашей доске задач есть отдельная колонка «Тестирование», это говорит о том, что вы по-прежнему рассматриваете этот процесс как отдельную фазу, а деятельность тестировщиков все еще отделена от остальной работы команды.
Agile-коучи Карен Гривз и Саманта Лэинг рекомендуют другой подход: задачи по тестированию должны проходить через те же этапы, что и все остальные: «В планах», «В процессе», «Готово».
Если вы хотите добавить отдельную колонку, обозначающую этап верификации задачи – отличная идея! Смысл этой колонки в том, чтобы каждую задачу просматривал еще кто-то из команды, сразу после того, как она выполнена. Peer review, пусть даже небольшие, можно проводить и для кода, и для документации, и для тест-кейсов.
Мы больше ценим предотвращение багов, чем нахождение багов
«Лучший бой – тот, который не состоялся», китайский стратег и философ Сунь-цзы.
Так же и с багом – лучше предотвратить, чем найти и исправить. И чем раньше вы это сделаете, тем лучше. Значительная часть багов вносится еще на этапе требований. Происходит это так: люди делают допущения по поводу требований и реализуют задание в соответствии со своими предположениями. Проясняется это только во время тестирования, когда обнаруживается баг. Поэтому, лучший способ предотвращать баги – задавать вопросы, чтобы быть уверенными, что все – и заказчики, и программисты, и тестировщики – одинаково понимают, как все должно работать.
Гривз и Лэинг в книге «Growing Agile» рассказывают о кейсе, когда их команде нужно было реализовать создание отчета, содержащего средние показатели продаж за последние 6 месяцев. Все считали, что они прекрасно понимают требования и особых обсуждений здесь не нужно, но авторы решили задать несколько вопросов:
- Если я запущу отчет 1 февраля, данные за февраль будут включены или нет? А если 29-го февраля?
- Как именно должны подсчитываться средние показатели – средний показатель каждого месяца или одно среднее арифметическое за все 6 месяцев?
- Этот средний показатель должен сохраняться где-то или подсчитываться «на лету»?
- Отчет должен храниться где-либо или создаваться по запросу?
- Из каких полей в базе данных высчитывается средний показатель?
- Кто будет использовать этот отчет и для чего?
И выяснилось, что никто даже не задумывался об этих вещах. Представляете, сколько багов бы нашлось и сколько переделок бы потребовалось, если бы за разработку этой фичи взялись, не получив ответов на эти вопросы?
Мы больше ценим тестирование понятности, чем проверку функциональности
Тестировщикам, которые считают, что их работа состоит в проверке соответствии продукта ТЗ, трудно свыкнуться с Agile. Но если бы работа тестировщиков заключалась только в этом, то все тестирование можно было бы автоматизировать, и живые люди в этом деле были бы не нужны. Кроме того, компьютеры выполняют подобные задачи быстрее, не уставая и не отвлекаясь. Поэтому, Agile-тестировщики должны стать адвокатами заказчиков, они должны глубоко понимать, кто их пользователи и каких целей они хотят достигнуть при помощи продукта. Тестировщики должны всегда смотреть на продукт с точки зрения заказчика, со стороны пользователя, и проверять, насколько продукт соответствует настоящим потребностям заказчиков, а не только спецификации или даже тому, что заказчик попросил.
Когда заказчик хочет добавить какую-то фичу, спросите: «Как вы убедитесь, что это работает?» Это поможет понять, какого результата на самом деле ожидает заказчик.
Мы больше ценим разработку лучшей системы, чем попытки ее сломать
В связи с этим принципом вспоминается старый анекдот: приходит тестировщик на собеседование. Заходит в комнату, ему указывают на стул и говорят: «Садитесь, пожалуйста!». Тестировщик садится – и стул под ним немедленно ломается. «Вы приняты!».
Анекдот хоть и забавный, но не совсем соответствует реальности. Хотя существует такое распространенное представление, что тестировщики занимаются исключительно разрушительной деятельностью, в этом только доля правды.
В самом деле, многие, кто выбрали эту профессию, любят что-то ломать и от души радуются, когда находят дефекты Да, тестировщик может играть роль злонамеренного пользователя и пытаться что-то испортить, но это лишь один из аспектов нашей работы.
Позитивное тестирование не менее (а то и более) важно, чем негативное. Порой тестировщики, особенно начинающие, слишком увлекаются сложными негативными тестами: а что если ввести 15 цифр после запятой? а что если ввести строку из 5000 символов? а что если отправить сообщение со всеми спецсимволами вместе, вроде такого: «~!@$%^&*()_+{}:;'`"?><[]»? Всё это очень увлекательно, но в то же время не стоит забывать о главной цели – создать продукт, несущий некую ценность и выполняющий свои функции как следует. Поэтому простые позитивные тесты, приближенные к реальным действиям пользователям, всё-таки приоритетнее.
Мы больше ценим командную ответственность за качество, чем ответственность тестировщика
Вообще говоря, ответственность всей команды за качество – один из основополагающих принципов Agile. Но многие ли чувствуют эту коллективную ответственность? Когда возникают сложности, как поступаете вы и другие люди в вашей команде – доказываете, что виноват кто-то другой, или думаете: «А что я мог(ла) бы сделать, чтобы это предотвратить или исправить?».
Если обнаруживается проблема с качеством, винят ли в этом исключительно тестировщиков или же команда разделяет ответственность? Собственно, тестировщики не могут улучшить качество, роль тестирования – определить уровень качества и проинформировать о нем заинтересованных лиц. Улучшение качества возможно только совместными усилиями всей команды.
Присоединяйтесь к IBS Training Center и освойте профессию тестировщика!
#технологии #it #программирование #тестирование #agile #баги