OpenQuality.ru
Качество программного обеспечения
Миф 1. Чем больше багов находишь в продукте, тем меньше их остается.
На первый взгляд, такое утверждение выглядит достоверным. “Вася, у тебя есть три яблока, два яблока ты съел, сколько яблок у тебя осталось?” “Одно,” - ответит Вася и будет прав. Но что происходит при тестировании? Зачастую баги, лежащие на поверхности, препятствуют глубокому тестированию продукта. Ваше приложение падает с дампом после трех часов работы? Это серьезно, но что будет с приложением (и операционной системой) через трое суток? Да, починка “трехчасового” бага объективно уменьшает общее количество дефектов, но в то же время может привнести новые. И даже если не привнесет, то непременно позволит найти хорошо запрятанные старые баги, которые ранее были недоступны.
Миф 2. Чем больше находишь багов в продукте, тем лучше.
И снова предположение выглядит логичным. Но на самом деле лучше меньше, да лучше. Баг багу рознь. Пять опечаток в графическом интерфейсе не идут ни в какое сравнение с неработоспособностью базовой функциональности продукта. Архитектурные баги могут приводить к серьезным изменениям в коде, а значит и к сдвигу сроков релиза. Если сдвинуть сроки не удается, то урезается функциональность продукта и/или период времени на тестирование. Именно поэтому такие баги в программах нужно находить как можно раньше. Нам важно качество, а не количество, верно?
Миф 3. Цель тестировщика - убедиться, что программа работает.
С точностью до наоборот. Тестирование может показать лишь наличие ошибок, но не их отсутствие. Тестировщик должен изначально исходить из предположения, что “все плохо”. Если программа выполняет нечто более сложное чем вывод на экран “Hello, world!”, то баги в ней непременно существуют. Никогда нельзя быть уверенным, что найдены все баги, но необходимо в отведенное на тестирование время найти самые зловредные из них. И чем больше уверенности в их существовании, чем сильнее желание их найти, тем меньше у багов шансов на выживание.
Миф 4. Заблуждений у тестировщика всего три.
Далеко не так. Список достоин расширения. Оставайтесь с нами.
Что такое качество программного обеспечения и как его улучшить: теория и практика, задачи и решения, подводные камни и обходные пути.
Автор комментария : Brezenix | September 30, 2008
Интересно где вообще такое заблуждение нашли? Или тестировщиков с такими заблуждениями? lol
[Ответить]
Автор комментария : Капитан Аляска | September 30, 2008
Brezenix, спасибо за комментарий.
Специально не искал - встречаются :) Впрочем, это не страшно. Если у человека есть задатки и стремление работать тестировщиком, то заблуждения исчезают очень быстро.
[Ответить]
Автор комментария : brezenix | September 30, 2008
Согласен =)
А вот, по поводу второго: “Пять опечаток в графическом интерфейсе не идут ни в какое сравнение с неработоспособностью базовой функциональности продукта”, не совсем согласен. Подобного рода ошибки очень отвлекают от дальнейшего тестирования (по крайне мере меня =) и считаю нужным сразу сообщать об этом, а то, что это отнимет какое-то время, то в следующий раз разработчик будет более внимателен. А отмаз, по поводу того, что это не главное не подойдет, потомучто следуя этой логике: мыться можно, а вот одежду стирать не обязательно? Кто-то так делает? Я думаю нет. А интерфейс и его грамотное построение это и есть “одежка” ПО, а встречают как известно именно по ней =)
[Ответить]
Автор комментария : Капитан Аляска | September 30, 2008
Brezenix, ну что ж, и я соглашусь :) Встречают по одежке, театр начинается с вешалки и т.п. Безусловно, такие вещи нужно исправлять - даже если они не отвлекают от дальнейшего тестирования. Кстати, далеко не всегда GUI и базовый функционал создает один и тот же разработчик.
Если эти баги на поверхности, то, конечно же, их нужно (как и грязную одежду) передать в стиральную машину. Но _сознательные_ усилия тестировщика должны быть в первую очередь направлены именно на базовый функционал продукта. Тестировщик должен понимать, что именно в этом его первичная задача. Одежка одежкой, но если фундамент плохой заложим, то будет не до бантиков.
[Ответить]
Автор комментария : brezenix | September 30, 2008
Согласен =)
А вот такой вопрос: Как относитесь к написанию контрольных примеров (taste-case)? Нужли ли они? И кто должен писать?
Поясню: в западной литературе (нашей покак особо и нет =) (к примеру Л. Тамре “Введение в тестирование программного обеспечения”) примеры пишет тестировщик. У нас же некто тест-дизайнер. И если есть баглист, каждая запись в котором по сути и есть тестовый пример (Что делал - что должно быть -что получилось в результате), то нужна ли отдельна система для записи контрольных примеров?
[Ответить]
Автор комментария : Капитан Аляска | September 30, 2008
1. Test cases. Да, нужны. Но не как прокрустово ложе, с которого шаг вправо-влево - расстрел. Скорее, они нужны вот в каком качестве:
а) ориентиры при тестировании, базовые сценарии работы с продуктом. С них можно начать, а в дальнейшем ориентироваться на exploratory testing.
б) первые кандидаты на автоматизацию
2. Идея каждый баг “оборачивать” в test case - неплохая, но удобно ли будет тестировщику воспринимать такие test cases, работать с ними? Будут ли они достаточны? И еще: баги - это следствие, результат тестирования, которое надо на чем-то строить. Test cases позволяют охватить все поле тестирования в целом и ничего не забыть. Единственное: не стоит ударяться в крайность, чтобы не погрязнуть в ворохе документов, в которые никто не смотрит.
3. Безусловно, гораздо лучше, если баги, test cases, исходный код, MRD, план проекта будут в одной системе. К сожалению, не всегда удается.
[Ответить]
Автор комментария : brezenix | September 30, 2008
Да в том то и дело…
Сейчас создаем собственную систему отслеживания ошибок (баглист), хотим прикрутить к ней систему написания и хранения тест-кейсов. Когда я пришел в проект, то идея была такая: много, скажем так, неквалифицированных тестировщиков, которые просто выполняют тест-кейсы, в которых описано практически все (но это же смешно и не возможно все описать). А если к концу дня придумали новую функцию, к вечеру надо протестировать, ее сначала надо описать в тест-кейсе, хорошо - тест-дизайнер пишет, а что в это время делают тестировщики… играю в контру или читают башорг? =)
Я же всячески отстаиваю точку зрения что лучше три, но грамотных тестировщика, и все строится вокруг баглиста. В этом случае нужна только спецификация на ПО (которую сейчас никто не пишет :( ), тестировщик ее изучает и начинает тестирование. Все таки, тестирование это творческий процесс, а на машинальном выполнении примеров далеко не уедешь =)
[Ответить]
Автор комментария : Капитан Аляска | September 30, 2008
Возможно, все строить вокруг баглиста - не совсем верно, но, как говорил Володя Шарапов, “действие ведете в верном направлении”.
Думаю, что нет какого-то одного сценария, который будет приемлем во всех случаях: для любого продукта, в любом проекте. Context-driven testing - это не просто так придумали. Важен результат.
Если текущее положение устраивает руководство, ситуация не будет меняться. Возможно, у руководства есть причины для выбранной схемы работы. Не всегда эти причины озвучиваются, но от этого они не становятся менее существенными. Как бы то ни было, время все расставит на свои места.
[Ответить]
Автор комментария : brezenix | September 30, 2008
Ну почему же “не совсем верно”?
Схема примерно такая:
Аналитики | спецификация | | разработчики тестировщики | | исправления баги (ошибки, дефекты, задачи, идеи) | | баглиствсе взаимодействие строится через баглист, что значительно убыстряет процесс доведения и бага до разработчиков. Также все требования которые описаны в спецификации тоже заносятся в баглист и там отрабатываются
[Ответить]
Автор комментария : Капитан Аляска | September 30, 2008
На мой взгляд, в представленной схеме test cases неявно присутствуют в одном из двух вариантов:
1) test cases изначально есть в спецификации (если она достаточно подробна, что далеко не всегда бывает). Иными словами, нет самого заголовка “test cases”, но сценарии однозначно прослеживаются.
2) если предыдущий пункт неверен, то эти test cases непременно появятся в виде багов исходя из взглядов тестировщиков (и не только их) на функциональность продукта.
То есть, test cases все равно остаются. Просто они будут законспирированы под словом “баги”. Нужно ли это, будет ли это полезным, сократит ли издержки - вопрос открытый, и ответы могут быть разными в зависимости от проекта.
[Ответить]
Автор комментария : brezenix | September 30, 2008
“test cases все равно остаются. Просто они будут законспирированы под словом “баги”” Вот в этом и суть, все описывается в баглисте, и доступно разработчику и другим тестировщикам для воспроизведения, да, и спецификация, и требования в ней - суть теже самые тест-кейсы, но не в таком явном виде как если бы они были в таблице контрольных прмеров. На это и расчитано, что бумажной (электронной =) волокиты меньше, а качество и эффективность труда - больше.
[Ответить]
Автор комментария : Капитан Аляска | October 1, 2008
Test case - это сценарий. Где он будет описан - в отдельном документе или в багтрэкинговой системе - большой роли (имхо) не играет. Да, возможно, удастся избежать некоторых перекрытий, когда один и тот же сценарий будет описан дважды, но это палка о двух концах. Станет больше багов и, возможно, работа с ними покажется избыточной для разработчиков. Если описать в баге сценарий, который еще просто не реализован, то на этот баг разработчику придется потратить время - прочитать, выполнить действия, закрыть, передать тестеру. Разработчик и без этого планировал эту работу - согласно спецификации. И еще: бывает так, что тест-кейсы необходимо передать третьей стороне - на аутсорсинг, для подготовки “Best practices” и т.п. В такой схеме тест-кейсы нужны скорее в виде use cases, чем в виде багов. То же самое - для smoke-тестов.
Возможно, в каких-то случаях хранить тест-кейсы в багтрэкинговой системе удобнее, но, имхо, далеко не во всех.
[Ответить]
Pingback : OpenQuality.ru | Майская лента: лучшее за месяц | June 1, 2009
[…] Linda Hayes, удачно дополняют ранее упомянутые три заблуждения начинающих […]