Как можно тестировать то, в чем не разбираешься?

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

Коллега Olga пишет правильное замечание:

это не работает на больших проектах. Если проект большой, часто у тестировщиков просто нет времени прочитать все существующие баги, физически. Это неправильно, но жизнь есть жизнь.

За баги, не являющиеся багами никто тестировщика не похвалит (это мягко сказано).

Комментарий сопровожден весьма внятным обоснованием.

А окопный товарищ zmei верно указывает на то, что псевдобаги в трекере никому кроме «медсестер» пользы не принесут.

«Не баги» вообще не приносят пользы разработчикам 🙂 Это внутренняя кухня тестировщиков. К тому же, это зависит от каждого тестировщика в отдельности. Я их приемлю. Другие нет.

В большинстве случаев подобные проблемы решаемы на уровне внутрикопроративных легенд, которые не документируясь, передаются устно или по внутреннему мессенджеру по мере необходимости. Я еще не встречал изрядно подготовленный свод «фич», которые не являются багами, копроративно оформленный и положенный на внутренний сервер. А вот на уровне «смотри в багтрекере» — встречал неоднократно. Любой трэкер — это и рабочий инструмент, и система хранения сделанных ошибок, так почему бы не использовать его в качестве wiki-системы?

Несколько невеских доводов

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

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

Пример для менеджера: в программе Excel есть функция поиска. И есть функция рисования диаграмм. И есть функция отображения определенных шрифтов. Предположим, все уже разработано и выпущено «в народ». Народ понемногу рапортует о найденных ошибках, а также просит улучшения функционала. Появляются изменения в некоторых функциях.

Итак, нужно проверить изменения в функции поиска, а через пять дней обещают подогнать изменения в функции диаграмм.

Разумнее что?

Разумнее сегодня направить на тестирование «поиска» всех «свободных» людей, чем выращивать спецов, которые видали в гробах все виды поиска, потому что они тестируют только диаграммы…

Завтра будет другой день, завтра будем проверять функцию «Save as…», и будет разумнее всех «свободных» направить на тестирование «сэйв эса».

Теперь представим, что я до сих пор «сидел» на диаграммах, и видывал я ваши «сэйв эсы» только в гробах. Но на сегодня у нас запланирована проверка корректности работы какой-то математической функции Excel — RANDBETWEEN.

У функции есть описание: Returns a random integer between the numbers you specify. Отличное описание, мне понятны все пробелы и все слова по отдельности. Если бы не было тест-кейсов, мне пришлось бы провести много часов надо документацией проекта, и пришлось бы задавать много вопросов окружающим. Это реально, особенно в рамках БОЛЬШОГО проекта?

Вот зачем нужны тест-кейсы. Вот зачем нужно все так детально записывать. Делай, что написано, и не морочь голову/головы.

Мне сообщают о том, что я буду сегодня тестировать такую-то функцию RANDBETWEEN в таком-то окружении (Windows 2000 / IE 6 / Office 2003). Мне выдают тест-кейсы на проверку этой функции. Я читаю буквы и тыкаю кнопки. Я не понимаю, что именно делает эта функция, и не знаю, какие входные параметры ей надо указать. Все это указано — в тест-кейсах. Через некоторое время я буду опытным пользователем этой функции. И если через некоторе время придется ее снова тестировать, мне уже будет проще. Но пока — только тест-кейсы.

Представляем дальше: одновременно со мной эту функцию тестируют мои коллеги — и тестируют ее в других окружениях. Например, в сочетании с другими версиями Excel, другими версиями Windows (их много, если кто не в курсе), другими версиями IE… Там обнаруживаются «свои» баги, которые заносятся на трекер.

Не предполагаем, а точно знаем, что некоторые баги могут быть сугубо привязаны к определенному окружению. Например, баг в одной и той же функции проявляется только в Windows XP / IE 7 / Office 2003, и совершенно не заметен в среде Windows, так сказать, Vista / IE 7 / Office 2003. А у нас поставлена Windows 2000, и у нее эта функция «баггирует» вообще неожиданным образом. И мы нашли какой-то баг — при нажатии кнопки «Cancel» функция крэшит Excel и удаляет Windows 2000. Бегом добавлять его в трекер, но сперва смотрим, не оставил ли там подобный баг кто-то из коллег. Дублировать баги — это не круто. Поэтому смотрим внимательно. И внезапно находим, что подобный баг уже добавлен….

И не только добавлен, но и помечен как Working as expected (самая страшная резолюция для опытного тестировщика), мол, смотри в такой-то документ, там написано, что во славу Ubuntu, при нажатии кнопки «Cancel» функция RANDBETWEEN ОБЯЗАНА закрэшить Excel и удалить Windows 2000…

Ладно, предположим, что при нажатии на кнопку Cancel функция прекращает свою работу, но очищает поля, в которые мы вводили входные данные.

Рассуждаем так: если я отменил операцию, значит, я буду указывать другие входные значения. И старые мне нужны, чтобы не вбивать все цифры заново. Значит, их НЕ следует удалять при нажатии Cancel. Логичное рассуждение? Да. Баг? Да, это баг (результат не соответствует ожиданиям, да еще и ведет себя «неудобно»).

Теперь представляем, что этот баг, который «не баг», воспроизводится во всех версиях Windows. И все тестировщики «на проекте» хотят его занести в багтрекер. Что, документация «скажет» им, что это «не баг»?

Поэтому — только багтрекер, и только «не баги»…

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

Есть же общие знания и понятия об интерфейсах

По следам статьи «Не баги» тоже надо заносить в багтрекер» мне было указано на несколько некорректную аллегорию про поросенка — ведь любому человеку ПОНЯТНО, что ноздрей у поросенка только две. Есть же общие знания и понятия об интерфейсах, в конце концов…

Да, все знают, сколько ноздрей у адекватного, разумного поросенка. Но теперь, на примере функции RANDBETWEEN, попытайтесь применить подход «Ну, едрить, колотить!!! Ну неужели не понятно, что третья ноздря — не ноздря?«…

Неизбежность: «не баги» всегда появляются.

Олицетворение постулата этой неизбежности: предположим, что программист, который работал над функцией RANDBETWEEN, всю свою жизнь положил на разработку именно этой функции… Он знает все ее движения, все ее варианты ответов, он знает всё, точно так же, как мы знаем о том, что у поросенков трех ноздрей не бывает.

А я, тестировщик, об этой функции НЕ ЗНАЮ ничего. С пытливостью и открытостью ребенка, я кручу и верчу эту функцию. И вполне могу найти «третью ноздрю»…

Следует ли мне уточнять, что понятие «неопытный тестировщик» НЕ означает «гнилой юзер, которые боится компьютера»? Особенно ввиду вышеизложенного.

Ну вот… В тестировании такие ситуации встречаются весьма часто (только об этом не следует знать заказчикам тестирования).

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

Документация может не помочь, потому что документация описывает то, как функция ДОЛЖНА работать. А мы видим, как она работает в действительности, проявляя чудеса, которые в документации не описаны, и не должны быть описаны, и никогда не будут…

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

Аксиома: большой проект изрядно снабжен документацией. Документация по проекту, как апостольские откровения, содержит всю правду жизни, которую надо знать тестировщику любого ранга.

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

Дальше мой опыт гласит нехорошее: младший тестировщиковский состав эту документацию «не видит и не слышит». Что, младшему составу предложено ознакомиться с архитектурой приложения и увлекательными взаимоотношениями «Клиент-Сервер»? Еще реферат на эту тему запросите…

Документов много. Но… «не баги» все равно будут появляться в трекере, и чем БОЛЬШЕ и сложнее проект, тем больше и чаще будут появляться эти самые «не баги»:

  • в проект приходят новые люди, которые не знакомы со спецификациями и требованиями
  • «старички» уходят, унося с собой «недокументированные» знания особенностей, спецификаций и требований
  • функционал проверяют то одни тестировщики, то другие
  • опытные тестировщики сходят с ума

Проблема решаема в следующих парламентских выражениях:

  1. используем ДВА багтрекера, «внутренний» для тестировщиков и «внешний», куда выносятся только те баги, которые были «просмотрены и одобрены» главными тестировщикам.В рамках БОЛЬШОЙ компании, чаще всего, так и происходит. Особенно если внешний багтрекер принадлежит компании-клиенту.Это разумно таже и потому, что «мусор» на поверхность не выносится, и у компании-клиента остается хорошее мнение о компании, которая проверяет конечный продукт.
  2. используем ОДИН багтрекер, но все баги проходят проверку у ГЛАВНОГО ответственного тестировщика, который решает, что показывать программистам, а что нет. Вопрос доверия, конечно.Это репрезентативно для небольших компаний, особенно для тех, которые поклоняются богам agile-разработки (agile — это сила!).Программисты могут видеть все «не баги», которые лежат в багтрекере, но не вмешиваются. И если все фильтруется на уровне опытного человека, то до программистов «не баги» просто «не доходят».

Как можно тестировать то, в чем не разбираешься?

Хороший вопрос: как можно тестировать то, в чем не разбираешься? Как можно доверить проверку функции RANDBETWEEN человеку, который даже о ее существовании не знал?

Честное слово, МОЖНО тестировать любую функцию из Excel, совершенно не понимая, что и как эта функция делает. Хватает общих знаний интерфейса Excel и основных команд для работы с меню и вызова функций, а также мы читаем подробно написанные тест-кейсы. А тест-кейсы эти написаны опытными людьми. Например, разработчиком. Или продакт-менеджером. Или другим тестировщиком, который уже перешел в лучший мир (в Oracle или Google), и более с нами не работает.

Вместо эпилога: «не баги» надо хранить в багтрекере, не передавая их программистам.

3 ответа на “Как можно тестировать то, в чем не разбираешься?”

  1. […] Решение в этому случае достаточно взвешенное, хотя и местами рисковое — чек-лист. Кто незамутненно уверен в том, что чек-лист — стопроцентная панацея в работе тестировщика, тот дурак. Зависит от проекта и уровня образования тестировщика. Например, без понимания софта тестировать в таком режиме почти невозможно. А вот по тест-кейсам может тестировать любой товарищ, даже не понимающий, что именно оне изволят-с тестировать и зачем. Доказательство. […]

  2. Мля, я афигею… ни хрена не нашёл тут… То что пишите.. это полный бред.. на столько бред, что я не поленился писать об этом. Не, это не бред.. это ЧЕРНОЕ СЕО.. что в разы хуже высшего!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

  3. знаю, о чём говорит автор. Работал на AlliedTesting. именно такая структура кстати — 2 багтрекера. Только внешний время от времени меняется. Весь контроль через узкое горлышко ряда тимлидов.
    Офисы у конторы в Москоу, братском Минске и Кишинёве.

Добавить комментарий