Урок 53: Оценочные (evaluation-based) техники фокусируются на том, как определить, что тест выполнен или провален

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Сергей Талалаев

Оценочные техники описывают методы для определения того, что программа выполнила или провалила тест. Они не определяют, как тестирование должно выполняться, или как должны собираться данные. Они говорят вам, что если вы можете собрать определенные данные, то вы сможете их оценить.

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

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

Сравнение со спецификацией или другим авторитетным документом. Различие со спецификацией - это (возможно) ошибка.

Эвристическое соответствие. Соответствие - это важный критерий оценки
программы.Несоответствие может быть поводом для создания отчета об ошибке или отражать сознательное изменение дизайна. Мы используем в работе 7 основных соответствий:
1. Историческое соответствие. Текущие поведение функции соответствует её поведению в прошлом.
2. Соответствие в представлении. Поведение функции соответствует тому, что организация ожидала от проекта.
3. Соответствие со сравнимыми продуктами. Поведение функции соответствует поведению подобных функций в сравнимых продуктах.
4. Соответствие утверждениям. Поведение функции соответствует тому, как, по мнению людей, это должно быть.
5. Соответствие ожиданиям. Поведение функции соответствует тому, что, по вашему мнению, хочет пользователь.
6. Соответствие продукту. Поведение функции соответствует поведению сравнимых функций или функциональных шаблонов в продукте.
7. Соответствие цели. Поведение функции соответствует её истинной цели.

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

Read more...

Урок 49: People-based техники фокусируются на том, кто проводит тестирование.

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Сергей Талалаев

Вот несколько примеров таких техник, отличающихся исполнителями.

Пользовательское тестирование / User testing. Тестирование людьми, которые обычно используют ваш продукт. Пользовательское тестирование может выполняться в любой момент разработки на вашей стороне или их, в строгом соответствии с подготовленными сценариями или на усмотрение пользователя. Некоторым видам пользовательского тестирования, таким как анализ задач, больше подходит совместное исследование (с привлечением как минимум одного пользователя и одного члена вашей тестовой команды), чем тестирование одним человеком.

Альфа тестирование / Alpha testing. Внутреннее тестирование, выполняемое тестовой командой (и возможно другими заинтересованными, внутренними ресурсами).

Бета тестирование / Beta testing. Это вид пользовательского тестирования, проводимый потенциальными пользователями вашего продукта, а не тестировщиками вашей компании. Разработка тестирумого продукта обычно близка к завершению. Многие компании рассматривают любую передачу предрелизного кода клиенту как бета-тестирование; они обозначают все бета-тесты как "бета". Это ошибка. В действительности существует множество различных типов бета-тестов. Дизайн-бета тестирование, требующее от пользователей (в первую очередь экспертов) оценки дизайна, должно быть проведено как можно раньше, чтобы оставить время для внесения изменений по результатам тестирования. Маркетинг-бета тестирование, проводимое с целью убедить крупных клиентов в необходимости приобретения данного продукта и установки его на своих крупных сетях, должно проводиться существенно позже, когда продукт уже достаточно стабилен. При проведении бета-теста совместимости ваш клиент запускает ваш продукт на аппаратных и програмных платформах, полноценное тестирование на которых было сложным для вас. Данный вид тестирования должен проводиться до того момента, когда уже слишком поздно выявлять и исправлять проблемы совмеcтимости. Для любых типов бета-тестирования, которые вы проводите, вы должны сначала определить цели тестирования и лишь затем принимать решения о том, как и когда вы будете его проводить.

Баг-штурм / Bug bashes. Внутреннее тестирование с привлечением секретарей, программистов, менеджеров по продажам и всех, кто доступен. Обычный баг-штурм занимает пол-дня и проводится, когда продукт близок к релизу. (Замечание: мы рассматриваем данную технику в качестве примера, не настаивая на ней. Некоторые компании находят её полезной по различным причинам, другие - нет.)

Тематическое экспертное тестирование / Subject-matter expert testing. Передача продукта эксперту для проверки некоторых проблем, возникших с продуктом и требующих детального анализа (дефектов, замечаний и дополнений). Эксперт может и не являться возможным пользователем вашего продукта, ценность эксперта - это его знания, а не его значимость как потенциального покупателя.

Парное тестирование / Paired testing. Два тестировщика работают вместе над поиском ошибок. Обычно они делят один компьютер во время тестирования.

"Ешьте сами свою заливную рыбу" / Eat your own dogfood. Ваша компания использует предрелизную версию своего продукта, обычно дожидаясь, когда продукт станет достаточно устойчив для реальной работы до начала его продаж.

Read more...

Урок 6: Работайте с программистами сообща

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Наталья Густыр

Поддержка программистов – это, наверное, ключевая часть вашей миссии. Когда вы тестируете вещи, которые программисты разрабатывают прямо сейчас, или недавно разработали, ваши отзывы помогут им работать более эффективно. Когда они что-то доставляют, вы тестируйте это. Когда они вносят какое-либо изменение, вы тестируйте это изменение. Ставьте перед собой цель предоставлять обратную связь наиболее коротким и быстрым путем. Пока программисты «пережевывают» баги, которые вы только что нашли, вы свободны для того, чтобы искать еще больше новых багов. Идеальная ситуация (для тестировщиков) – это та, в которой разработчики заняты исправлением проблем настолько, что вы можете явно дать понять, кто в проекте – узкое место (они, а не вы!).
Read more...

Урок 238: Нанимайте людей, которые любят свою работу

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Сергей Талалаев

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



Read more...

Урок 244: После принятия решения - оперативно завершайте процедуру найма

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Сергей Талалаев

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



Read more...

Урок 68: Не игнорируйте очевидные дефекты

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Ольга Балашенко

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

Такое случается даже с серьёзными дефектами. Все знают о существовании ошибки, и все думают, что кто-то другой её уже зарегистрировал. Однажды явный баг так и не был исправлен, пока Систему не отдали в эксплуатацию!
Read more...

Урок 237: Найм по согласованию

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Сергей Талалаев

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

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

Урок 9: Вы не найдете все баги

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Наталья Густыр

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

Вы должны делать выбор в отношении того, как тратить свое время, зная и принимая то обстоятельство, что Вы не можете сделать абсолютно все.
Read more...

Урок 19: Тестирование находится в вашей голове

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Наталья Густыр

Разница между превосходным и посредственным тестированием заключается в том, как вы думаете: ваши варианты дизайна тестов, ваша способность интерпретировать то, что вы наблюдаете, и ваша способность поведать об этом. Все остальное тестирование – это просто офисная работа в большей части. Если вы видите двух тестировщиков, работающих рядом, вы не можете определить, работает ли один лучше, чем другой. Видимая часть их работы выглядит совершенно одинаково, что наталкивает на две мысли:
- Многие люди думают, что тестирование – это просто, потому что они без труда могут копировать видимую часть поведения хорошего тестировщика, и у них нет других стандартов для хорошего тестирования.
- Если вы хотите быть хорошим тестировщиком, научитесь думать, как он, а не выглядеть, как он.
Read more...

Урок 67: Регистрируйте дефекты сразу же после обнаружения

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Ольга Балашенко

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

Урок 66: Никогда не используйте систему регистрации дефектов для оценки эффективности работы тестировщиков

Lessons Learned in Software Testing
Авторы: Cem Kaner, James Bach и Bret Pettichord
Перевод: Ольга Балашенко

Если Вы (тест-менеджер) поощряете тестировщиков за количество найденных дефектов, то Вы можете добиться нежелательного эффекта:
- чтобы увеличить количество найденных дефектов, тестировщики, будут искать поверхностные, легко находимые дефекты и избегать сложно воспроизводимых дефектов;
- тестировщики будут чаще регистрировать несколько вариации одного и того же дефекта;
- увеличится количество «не дефектов», т.е. дефектов, которые на самом деле не являются ошибками;
- тестировщики будут тратить большую часть своего времени на поиск дефектов, что повлечёт за собой игнорирование других задач и обязанностей.
Read more...

Lessons Learned in Software Testing

В недавнем прошлом нам повезло держать в руках книгу – мечту каждого тестировщика!
Авторы Cem Kaner, James Bach и Bret Pettichord собрали воедино удивительный материал и нарекли его «уроками» - Lessons Learned in Software Testing.


“We follow the context-driven approach in software testing. We expect that a method that works wonderfully under some circumstances will not work under others” – в этих словах выражена основная идея книги.
« Lessons…» – не догма и даже не лучшие практики. Это – реальный опыт реальных людей. Многие из уроков до сих пор вызывают споры между самими авторами, и они были бы счастливы, если бы книга побуждала также и читателей к обсуждениям и дебатам.

Книга предназначена для тестировщиков с опытом, и крайне не рекомендуется новичкам. Последним она может показаться тяжелой и утомительной.

Книга состоит из 293 уроков, объединенных в 11 частей.
Некоторые уроки на русском (в собственном переводе) мы представим и вашему драгоценному вниманию!

Как пишут сами авторы, книгу запрещается (!) читать от начала и до конца. Ее нужно читать с любого места, по 1-2 урока за раз. И только после того, как вы осмыслите прочитанное, можно приступать к дальнейшему чтению. Мы, беспрекословно следуя советам авторов, не будем торопиться и соблюдать порядок уроков…

Наталья Густыр
Read more...