«Ad hoc testing is a commonly used term for software testing performed without planning and documentation»
Я часто слышу от людей близких к разработке ПО, но далеких от тестирования фразы типа: «все тестеры — задроты». Вероятно, такое мнение образовалось из-за того, что нам, тестировщикам, приходится большую часть времени заниматься рутинной работой, например, составление и анализ сотен однотипных тест-кейсов и последующее прохождение их, в лучшем случае, перед каждым релизом, или проведение теста приемки каждый раз когда выходит новый билд. Для такой работы характерна четкая определенность процесса тестирования, т.е. взял кейс №1, воспроизвел процедуру, поставил отметку о прохождении, взял кейс №2, и т.д. Никакого творчества и само собой шаг влево-право = расстрел.
Таким образом эта рутина не может не угнетать здоровый и молодой мозг тестировщика, который, устраиваясь на работу, прочитал в интернетах что «тестеры – люди творческие», и тут на помощь приходит эксплоринг, а именно эд хок тестирование, хаотичность которого объясняется свободным поиском багов, хочу туда кликаю, хочу сюда, а хочу и с БД балуюсь, и на первый взгляд, вот оно творчество, но не все так просто. Думаю, что любой более-менее опытный тестировщик перед началом тестирования какой-нибудь функциональности в голове составляет план тестирования и все те же тест-кейсы №1-100500, которые в другом случае были бы написаны, и только после этого приступает к работе. Этим я объясняю приставку «псевдо». Таким образом, чередование интуитивного тестирования с прохождением тест-кейсов позволяет снимать напряжение с мозга.
Каждый тестировщик как минимум должен знать свой проект. С приходом нового тестировщика встает вопрос: «А как его научить знать проект?». В одних компаниях тестера сразу бросают в бой – дают пару сотен кейсов на выполнение. Действительно, зачем учить, если в процедурах все и так написано. Таким образом, компания приобретает «мартышку» на 3-5 месяцев, до тех пор, пока он не пройдет большую часть тестовых комплектов. После этого тестировщик достаточно хорошо знает проект, чтобы выполнять другие функции помимо воспроизведения шагов. Давайте представим, что этот же тестировщик вместо прохождение кейсов, неделю(40-50 часов) должен будет бессистемно искать баги, там где он захочет, параллельно читая спеки и диздоки об интересующих его объектах. Уже через неделю наш тестировщик будет знать 70% от того что узнал бы проходя кейсы 3-5 месяцев.
Например, игрок пишет что у него клиент упал после изучения заклинания «Хабрахабр». Простейшая процедура воспроизведения будет выглядеть так:
1. зайти в башню магии
2. выучить заклинание «Хабрахабр»
Ожидаемый результат: клиент с грохотом упал.
Фактический результат: заклинание выучилось.
Что делать если баг не воспроизвелся, но игроку мы доверяем? Можно попросить вспомнить все, что он делал последние 15 минут до падения. 80% что он не вспомнит. Тогда остается только эд хок. Под девизом: «воспроизвести любой ценой» мы открываем клиент и штурмуем мозг всевозможными алгоритмами поведения пользователя. Итого: через 2-100 часов баг воспроизведен, а у игрока горят уши пропорционально количеству потраченных часов. А баг оказался простым: стабильное падение клиента на компах где установлен скайп, во время получения сообщения в icq6.
Плюсы интуитивного тестирования:
1. «Псевдохаотичность» тестирования
Я часто слышу от людей близких к разработке ПО, но далеких от тестирования фразы типа: «все тестеры — задроты». Вероятно, такое мнение образовалось из-за того, что нам, тестировщикам, приходится большую часть времени заниматься рутинной работой, например, составление и анализ сотен однотипных тест-кейсов и последующее прохождение их, в лучшем случае, перед каждым релизом, или проведение теста приемки каждый раз когда выходит новый билд. Для такой работы характерна четкая определенность процесса тестирования, т.е. взял кейс №1, воспроизвел процедуру, поставил отметку о прохождении, взял кейс №2, и т.д. Никакого творчества и само собой шаг влево-право = расстрел.
Таким образом эта рутина не может не угнетать здоровый и молодой мозг тестировщика, который, устраиваясь на работу, прочитал в интернетах что «тестеры – люди творческие», и тут на помощь приходит эксплоринг, а именно эд хок тестирование, хаотичность которого объясняется свободным поиском багов, хочу туда кликаю, хочу сюда, а хочу и с БД балуюсь, и на первый взгляд, вот оно творчество, но не все так просто. Думаю, что любой более-менее опытный тестировщик перед началом тестирования какой-нибудь функциональности в голове составляет план тестирования и все те же тест-кейсы №1-100500, которые в другом случае были бы написаны, и только после этого приступает к работе. Этим я объясняю приставку «псевдо». Таким образом, чередование интуитивного тестирования с прохождением тест-кейсов позволяет снимать напряжение с мозга.
2. Форсированное обучение новых сотрудников
Каждый тестировщик как минимум должен знать свой проект. С приходом нового тестировщика встает вопрос: «А как его научить знать проект?». В одних компаниях тестера сразу бросают в бой – дают пару сотен кейсов на выполнение. Действительно, зачем учить, если в процедурах все и так написано. Таким образом, компания приобретает «мартышку» на 3-5 месяцев, до тех пор, пока он не пройдет большую часть тестовых комплектов. После этого тестировщик достаточно хорошо знает проект, чтобы выполнять другие функции помимо воспроизведения шагов. Давайте представим, что этот же тестировщик вместо прохождение кейсов, неделю(40-50 часов) должен будет бессистемно искать баги, там где он захочет, параллельно читая спеки и диздоки об интересующих его объектах. Уже через неделю наш тестировщик будет знать 70% от того что узнал бы проходя кейсы 3-5 месяцев.
3. Основной плюс метода — возможность поиска «хитрых, коварных» багов, которые не только трудновоспроизводимы, но и неизвестно как их воспроизводить
Например, игрок пишет что у него клиент упал после изучения заклинания «Хабрахабр». Простейшая процедура воспроизведения будет выглядеть так:
1. зайти в башню магии
2. выучить заклинание «Хабрахабр»
Ожидаемый результат: клиент с грохотом упал.
Фактический результат: заклинание выучилось.
Что делать если баг не воспроизвелся, но игроку мы доверяем? Можно попросить вспомнить все, что он делал последние 15 минут до падения. 80% что он не вспомнит. Тогда остается только эд хок. Под девизом: «воспроизвести любой ценой» мы открываем клиент и штурмуем мозг всевозможными алгоритмами поведения пользователя. Итого: через 2-100 часов баг воспроизведен, а у игрока горят уши пропорционально количеству потраченных часов. А баг оказался простым: стабильное падение клиента на компах где установлен скайп, во время получения сообщения в icq6.
