Третья аксиома тестирования

Вторая аксиома тестирования

Первая аксиома тестирования

Что такое команда?

Открытый вопрос. Попробуйте уместиться в 2 предложения.

Мифы и грабли: Цель тестирования - поиск ошибок

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

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

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

Отчеты о невероятных ошибках вызовут усмешку у разработчика и разочарование у заказчика, потому что это отбирает время и ресурсы от главной цели - убедиться в том, что приложение делает то, что нужно пользователю. Если вы не верите, что пользователи будут жертвовать таким "качеством" ради функциональности, просто посмотрите на количество известных ошибок у каких-нибудь популярных продуктов (например, у вашей любимой ОС, офисного пакета или браузера).

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

Мифы и грабли: Ограниченные время и ресурсы - главная причина пропуска дефектов

Я думаю ни для одного тестировщика не в новинку работать в условиях нехватки времени и прочих ресурсов. И наверное, многие считают, что если бы им предоставили так необходимое время, они бы обязательно обнаружили все пропущенные дефекты. Действительно ли это так? Попробуйте прикинуть, сколько дефектов пропускается из-за нехватки ресурсов, а сколько из-за неправильного их использования или неверного выбора стратегии или планирования. Наверняка вам не раз приходилось выполнять работу, которая не приносила никакого результата. К примеру, это может быть написание различных документов, планов, отчетов, детализированных тест-кейсов. Автоматизация, про которую впоследствии забывают. Сбор метрик и статистики, которая так необходима вышестоящему менеджменту. Да вообще много чего. Естественно, я не говорю что наличие времени и ресурсов не важно, хочется сказать, что грамотное использование этих ресурсов, как, впрочем, выбор стратегии и планирование, это гораздо более важный момент в тестировании. Как использовать правильно - тема для другой статьи, и, в любом случае, тут выбор за вами. А времени всегда будет не хватать, ведь мы же знаем, что тестирование - процесс бесконечный.

Мифы и грабли: А ты QA?

Часто приходится слышать как нас называют QA (куа, куэй и т.п.). Многие даже сами себя так называют, я вроде даже видел футболки с надписью я - QA. А вы задумывались, что QA это не профессия, а название процесса? В каком-то английском блоге, уже не помню где, прочитал что кого-то бесит, когда его называют QA. Но, с оригинальными носителями языка, видимо, сложнее. А как к этому относитесь вы? Лично меня это не особо коробит, но вчера из троллинговых побуждений испытал замечание по данному поводу на разработчике, чем вогнал его в небольшой ступор (результатом удовлетворен). :)

Мифы и грабли: Откуда есть пошло Исследовательское Тестирование и причем тут ad hoc

Вообще, изначально был только ad hoc testing, который считался несистематичным, небрежным, неспланированным и прочее. Но на самом деле, это просто импровизация тестировщика во время тестирования. Потом, где-то в начале 90-х годов прошлого века, собрались товарищи (самый яркий представитель - Канер), которые объявили себя context-driven software testing school, усовершенствовали тот самый ad hoc и чтобы не вводить никого в заблуждение, придумали термин exploratory testing (который упоминается в книге Канера Testing Computer Software), что по сути являлось всего-навсего "умудренным" подходом к ad hoc тестированию. В последующее десятилетие, тремя китами Exploratory Testing - Cem Kaner, James Bach и James Whittaker, были разработаны специальные техники и выделены навыки, которые необходимы для применения Исследовательского Подхода. Ради интереса, можно изучить данный артефакт.

Разница между ad hoc и exploratory testing в том, что теоретически, ad hoc может провести кто угодно, а для проведения exploratory необходимо мастерство и владение определенными техниками. Обратите внимание, что определенные техники это не только техники тестирования. Ну а в настоящее время, на фронтах идут битвы за разделение понимания exploratory и ad hoc.

Написано по памяти из всяких разных источников и интервью Д.Баха, ссылки лень искать

Мифы и грабли: Пятиминутка ненависти к тестированию

Например, на собеседовании можно часто услышать вопрос, почему вы стали тестировщиком и что вам нравится в тестировании. Да и вообще, об это частенько любят потрепаться на форумах и в других местах скопления инженеров по тестированию. Это все конечно интересно, но есть же и другая сторона медали. Не знаю как вас, но лично меня некоторые вещи в тестировании периодически расстраивают. Иногда даже наблюдается пар из ушей. Я немного поразмышлял, что же делает несчастным тестировщика и для начала выделил пять пунктов. Если что-то ещё придет на ум, или подскажет кто - опубликую в другой заметке. Вы можете подумать, что я тут поплакаться решил, но не дождетесь :) - это просто издержки в профессии. У всех они свои. Итак, иногда:

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

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

3. Нас учат как правильно тестировать
Чтобы вы сразу поняли, это, к примеру, когда вам какой-нибудь умник начинает менторским тоном рассказывать, как тестировать ну, допустим, граничные значения (а вы это прекрасно знаете). То есть, какие-то азы. Или, бывает, встречаются перцы, которые считают что тестирование это обезьянья работа и я-вам-тут-щас-за-час-все-протестирую. Не спорьте с такими, выслушайте и сделайте, как считаете нужным. А вообще, я никогда не упускаю возможности чему-нибудь незнакомому научиться, и вам советую.

4. Приходится выглядеть идиотом
Да, частенько приходится задавать глупые, а порой совсем тупые вопросы. Просто чтобы выяснить что это действительно так а не иначе. Шаги для воспроизведения ошибки приходится описывать чересчур детально (порой, противоестественно для мозга). Не бойтесь выглядеть идиотом, бойтесь им оказаться.

5. Нас не устраивает наша зарплата
Думаю, это больная тема не только для тестировщиков. Изначально так повелось, что тестировщики себя противопоставляют разработчикам. И по средним показателям в плане зарплаты явно проигрывают. Тут все в ваших руках. Становитесь программистами или менеджерами, или вообще меняйте сферу деятельности - откройте лунапарк. :)

Мифы и грабли: Что такое программа?

А давайте-ка заглянем в словари (сами-знаете-на-каком-сайте) и посмотрим что такое программа.

Большая советская энциклопедия

Программа (от греч. programma — объявление, распоряжение, указ), Упорядоченная последовательность действий для ЭВМ, реализующая алгоритм решения некоторой задачи.

Экономико-математический словарь

В кибернетике (главным образом, технической) — основной элемент программного управления, строго определенная последовательность действий, предписанная объекту управления. В частности, машинная П. — алгоритм задачи, записанный таким образом, чтобы ее можно было решить на ЭВМ. Запись ведется на одном из языков программирования как последовательность команд (операторов), указывающих, в каком порядке, с какими данными и какие надо проводить элементарные операции.

ГОСТ 19781-90

Программа - согласно - данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма.

Да уж, как-то суховато и старомодно. В последнее время стало модно в качестве компетентного источника использовать Википедию. Заглянем и туда:

Компьютерная программа — последовательность инструкций, предназначенная для исполнения устройством управления вычислительной машины. Чаще всего образ программы хранится в виде исполняемого модуля (отдельного файла или группы файлов). Из этого образа, находящегося как правило на диске, исполняемая программа в оперативной памяти может быть построена программным загрузчиком. В зависимости от контекста, рассматриваемый термин может относиться также и к исходным текстам программы. И т.д.

В общем, смысл ясен, программа это сферический конь где-то в компьютере. Примерно этому нас и учили в школе и ВУЗе. Но чем плохи эти определения? Да это же грабли! Они утверждают что программы созданы для компьютера. В современных реалиях это всего лишь частный случай. К чести Википедии, в конце статьи вспоминаются многострадальные пользователи, которым приходится использовать эти программы.

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

Ура-ура!!! Программы для пользователей называются прикладным программным обеспечением. Идем дальше:

Издательский словарь-справочник

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ — совокупность программ, управляющих работой компьютера или автоматизированной системы.

Cловарь по естественным наукам. Глоссарий.ру

Программное обеспечение - комплекс программ:
- обеспечивающих обработку или передачу данных;
- предназначенных для многократного использования и применения разными пользователями.

Википедия

К прикладному программному обеспечению (application software) относятся программы, написанные для пользователей или самими пользователями, для задания компьютеру конкретной работы. Программы обработки заказов или создания списков рассылки — пример прикладного программного обеспечения. Программистов, которые пишут прикладное программное обеспечение, называют прикладными программистами.

Да, похоже, Википедию действительно иногда можно считать компетентным источником. А теперь мораль: забудьте все эти стереотипные определения. Помните, что в первую очередь ПО создается для конечных пользователей. Оно в первую очередь должно облегчать решение пользовательских задач, а не делать его заложником сложной логики и запутанного интерфейса. Создавайте программы для пользователей а не для роботов. Остальные лозунги додумайте сами.

Мифы и грабли: Цель тестирования в проверке соответствия требованиям

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

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


Но глядя со своей колокольни, я не могу считать эту деятельность тестированием. Честно говоря, я даже не интересовался, как все это должно называться. Допустим, валидация. Или верификация. Не важно, речь в заметке пойдет не об этом, а почему проверку соответствия требованиям, т.е проверку качества, я не могу считать тестированием (вы можете оставаться при своем мнении).

Итак, вы проверяете соответствует ли ваш продукт требованиям. А задаетесь ли вы при этом такими вопросами:

1. Возможно ли составить полный список требований?
2. Если нет, можно ли считать работу выполненной проверив соответствие списку требований?
3. Надо ли тестировать то, что в требованиях не описано?
4. Верны ли требования сами по себе?
   
5. Я что, долбаный робот? :) и т.д.

Если задаетесь, то вы наверняка принимаете активное участие в формировании требований. А если кто читал "Роман об управлении проектами" Демарко наверняка помнят главу про плохую спецификацию провалившегося проекта (система для аэропорта). Да и вообще, практика подключения тестировщиков к проекту на этапе формирования требований давно себя зарекомендовала с самой лучшей стороны, особенно если вспомнить правило 1-10-100.

Что по поводу качества, мне нравится высказывание Gerald Weinberg: "Quality is value to some person", т.е. у каждого свои представления о качестве. У разработчика. у менеджера, у тестировщика, у пользователя и т.д. Поэтому тестирование осложняется тем, что тестировщикам приходится часто сталкиваться с проблемами, которые влекут за собой конфликт интересов. Тут уже надо включать голову и здравый смысл. Некоторым конечно проще перевести стрелки на менеджера или лицо более ответственное, но грамотный тестировщик обычно всегда в состоянии предложить решение и донести его до заинтересованных сторон (так называемых stakeholders). Потому что у этого тестировщика сформирована общая картина проекта и он понимает что от него хочет каждая из заинтересованных сторон. Кажется, я уже ударился в проповедование context-driven testing. :)

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

Мифы и грабли: Вы не обеспечиваете качество тестированием

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

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

Из книги "Lessons Learned in Software Testing" Kaner, Bach, Pettichord

Мифы и грабли: Цель тестирования - поиск ошибок

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





То есть, этому мифу будет посвящено несколько заметок. Тем не менее, ниже я не озвучу свое видение вопроса, а приведу вольный перевод отрывка из книги Рекса Блэка Pragmatic Software Testing, который в свою очередь цитирует Бориса Бейзера (мне очень льстит такая вложенность :) ). Мне сегодня случайно попалась эта глава на глаза, показалась весьма в тему и я решил не откладывать в долгий ящик. Это неплохая пища для ума, а свое скромное мнение я напишу как-нибудь потом, тем более что с гуру трудно не согласиться.

-------
Один из трех основателей современного тестирования ПО, Борис Бейзер, определил пять стадий становления тестировщика:

• Стадия 0: Нет никакой разницы между тестированием и отладкой. Цель тестирования - помощь в поиске и исправлении ошибок;
• Стадия 1: Цель тестирования - доказать что ПО работает;
• Стадия 2: Цель тестирования - доказать что ПО не работает;
• Стадия 3: Цель тестирования не в том, чтобы что-то доказать, а в понижении предполагаемых рисков, приводящих к неработающему ПО, до приемлемого уровня;
• Стадия 4: Тестирование это не этап. Это интеллектуальная деятельность которая приводит к получению надежного и стабильного ПО без больших трудоемких затрат на тестирование.

Первые две стадии можно рассматривать как миф людей и организаций с незрелыми практиками и процессами тестирования (для исчерпывающего описания см. книгу Б.Бейзера Software Testing Techniques).

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

Однако вы можете прогрессировать до стадии 3. На этой стадии тестирование является составляющей всеобъемлющей стратегии управления рисками. Тестирование ориентировано на риски. Тестирование предоставляет информацию, имеющую отношение к рискам. Эта книга может научить вас как достичь и этого.

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

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

Думаю, в следующих заметках на эту тему я опять обращусь к кому-нибудь из классиков.

Анонс: Мифы и грабли тестирования

Всем известен постулат: "любая программа содержит ошибки". Или "тестирование это бесконечный процесс". А также многие другие. К сожалению, среди этих многих других, часто встречаются заблуждения. Например, что цель тестирования - поиск ошибок или что тестирование обеспечивает качество и так далее. Я читаю об этом на форуме тестировщиков, слышу на собеседованиях (особенно от малоопытных специалистов), припоминаю какие-то свои ошибки или сам их совершаю. В итоге, я решил начать коллекционировать эти мифы и грабли и буду пробовать потихоньку разрушать их в этом блоге. На истину в последней инстанции не претендую, поэтому все возмущения от моей дерзости с удовольствием буду принимать и парировать в комментариях. Следите за блогом.

На фото: Кэри Байрон из телешоу "Разрушители легенд"