суббота, 4 февраля 2012 г.

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

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

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

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

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

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

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

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

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

четверг, 2 февраля 2012 г.

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

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

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

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

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

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

среда, 1 февраля 2012 г.

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

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

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

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

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

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