Баги долгожители

Сегодня собираюсь написать о багах-долгожителях, о замыленном взляде, о долгом процессе тестирования...
О насущных проблемах, на которые есть пару способов управы, да всё нет времени взяться за них обеими руками.

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

Баги в ручных тест кейсах, тех самых, что приходится делать ручками, я выделю пока следующие
1) устаревание тест-кейса. Выполнение одного и того же тест кейса много-много раз приводит к тому, что он выполняется не добросовестно - такова особенность мозга. Тестирование - интеллектуальный труд. И его эффективность сильно зависит от внимательности. И сильно зависит от интереса к объекту, на котором вы сосредотачиваете внимание.
Так вот. Чем больше раз вы делаете одно и то же, тем неинтереснее это для вас. И тем больше вероятность пропуска дефекта. Или, например, вы решите это вовсе не делать, т.к. раньше всё вроде работало.
2) Слишком общее и не подробное описание тест-кейса. Заставляет наш мозг придумать и додумать возможные мысли самостоятельно. Это влечёт за собой всегда некоторую ограниченность - нам приходит в голову только определённая часть идей из возможных и что самое опасное здесь - продумывая возможные варианты в голове, мы заранее сильно сокращаем их количество, чтобы удержать в памяти все шаги друг за другом, т.к. действовать можем, получая лишь конкретные команды из головы. А это означает, что если в тест-кейсе тест-дизайнер написал "проверить работу функции для различных пользователей" - она не будет проверена полностью и для всех возможных пользователей.
3) Не понятное описание тест кейса или описание, содержащие неточности и ошибки. Опять вспомним наш дорогой мозг, который всё это и делает с нами и нашим продуктом. Мозг, встречая ошибку в описании того, что надо делать, сразу стартует тормозящие процессы внутри себя. И мы либо часть тест кейса не делаем, либо делаем эту часть как-то иначе, на своё усмотрение.

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

Апельсин дольками.
Режьте пополам!
Так, вот, о чём мы. Лечится всё это легко. Тест-кейсы разрабатывает вся команда. Каждый выполняет тест-кейсы только те, которые не писал сам. при выполнении ты должен изменить тест-кейс - что-то добавить, исправить или удалить. Это надо сделать таким же обязательным пунктом, как предоставление результатов для каждого тест-кейса. Временно увеличивать количество тест кейсов на одну из функций приложения. Увеличить в несколько раз, провести тестирование, после нахождения всех возможных багов сократить количество тест кейсов до первоначального, основываясь на анализе найденных багов. Потом то же самое для другой функции. И по кругу.
И ещё одно правило, которое, к сожалению, тоже приходится писать - сообщать о всех выявленных дефектах/недочётах, которые были обнаружены в ходе проведения тест-кейса или в ходе ручного тестирования.

И да, ещё. Многим такая схема может прийтись не по вкусу. Что значит постоянно менять описание тест-кейса? Это значит постоянно отвлекаться. Терять много времени. И вообще "заниматься не тем". Это всё из отговорок, но они по-своему весомые.
Вообще говоря, не обязательно к паровозу прикручивать крылья. Такой режим работы можно задавать одному из членов группы и каждый раз менять "Избранного". Можно даже это обыгрывать переходящим Знаком Отличия. Кепка великого Исправителя тест-кейсов или кружка главного-тест-аналитика.
И да упасут те высшие силы в которые вы верите вас кого-то заставлять. На эту должность вам нужен человек с очень хорошим вниманием и памятью, с горящими глазами. Заставив править тест кейсы кого-то через силу, хорошего ожидать не приходится.

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

И помните про пушистых кроликов. Они любят морковку и не любят порезанный дольками апельсин. И очень хорошо держат на себе внимание и активируют воображение. Примерно на 5-10 минут.

Верификация чужих багов - или не рой яму ближнему своему

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

И вот ты сидишь и читаешь "шаги воспроизведения" к чужому багу:
иногда фича №4405 работает не очень хорошо.....
И комментарии программиста, который это исправил:
было исправлено в версии 1.3.4.55554 от 02.03.2004.

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

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

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

Тестировщики - где их обучают?

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

Так вот о чем я.

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

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

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

Первая запись в блоге о тестировнии

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

Вот обычная ситуация - человек, никогда раньше не занимающийся тестированием, решает стать тестировшиком. Проходит собеседование и приступает к работе. Но он ещё не тестировщик. Момент, когда он им станет, не заметит никто, даже он сам. Хорошо это или плохо, но однажды найдя ошибку в приложении, он захочет находить их ещё и ещё.
Но охотника судят не потому, сколько оленей он заметил в лесу, а потому, сколько принёс домой.
Найти баг, описать его. Подождать пока пофиксят и убедиться в том, что продукт стал лучше. Искать и описывать новые баги. Это увлекает, но когда же начинаешь осознавать себя тестировщиком?
Может, когда ловишь себя на мысли, что только что нашёл баг не в том продукте, над качеством которого ты работаешь, а в другом - в своём любимом текстовом редакторе, операционной системе или на сайте антивирусной компании. А может, когда посетив новый сайт первым делом пытаешься его закликать и протестировать на инъекции. Или купив пачку сухариков собираешься писать производителю письмо с предложением изменить упаковку, чтобы она удобнее открывалась. Точно сказать сложно. но однажды вы понимаете, что вы - тестировщик.

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

А вот и результат:
1. Юзабилити сервиса для создания блогов очень понравилось и оставило только приятные ощущения. Всё довольно легко, выглядит все симпатично. Только вот дизайнов маловато на выбор, но с этим можно смириться.
2. Один раз удалось вызвать ошибку доступа к странице. Забавно. Повторить не удалось, так что считаем что бага нет.
3. Создана первая запись в блоге. Пока писал, успел приготовить ужин и определиться с тем, чтобы посмотреть на сон грядущий, а так же распланировал свой завтрашний рабочий день.
4. Пролистал несколько блогов, посвящённых тестированию. Погуглив "блог начинающего тестировщика" понял, с чего не стоит начинать вести собственный блог - с комбинаций клавиш 'Ctrl+C' > 'Ctrl+V'. Остаётся неоднозначное впечатление после посещения трёх блогов с идентичными записями без ссылки на копирайт.
5. Вычислил, что стандартный русскоязычный словарь в Chromium не признаёт существование буквы ё. Обучил его нескольких словам.
6. Опубликовав запись, через 15 минут всё же нашёл баг - http://www.google.com/support/forum/p/blogger/thread?tid=0d1ee0bcfd720d13&hl=en
хоть и описал на скорую руку, но вот она, добыча ) Баг тут скорее в том, что в моём браузере нет нужного стандартного клиента, но, тем не менее, он мне об этом должен был хотя бы написать.