Home

Автор: Брэндан О'Коннолли (Brendan O'Connolly).

Оригинал статьи: http://www.brendanconnolly.net/more-than-a-mindset/

Перевод: Ольга Алифанова

Наверное, вы часто слышали разговоры о некоем особом "образе мыслей" тестировщика.

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

Автор: Ким Нап (Kim Knup)

Оригинал статьи: https://punkmiktests.wordpress.com/2016/05/15/thoughts-encouraging-change-when-you-are-the-only-tester/

Перевод: Ольга Алифанова

Из моего рассказа на подкасте Testing In the Pub многие знают, как меня ценят на моей работе. Меня всегда приглашают на kick off-встречи, на которых мы говорим о том, что мы создаем и почему, и команды просят меня составить ментальные карты для тестирования.

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

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

Они все-таки решили нанять меня, а потом – целую команду тестировщиков. О том, как это произошло и чему я научилась, я и хочу рассказать.

Автор: Джефф Найман (Jeff Nyman)

Оригинал статьи: http://testerstories.com/2016/03/the-art-of-attention-to-detail-in-exploratory-testing/

Перевод: Ольга Алифанова

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

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

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

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

Тут стоит отметить, что именно в исследовательском тестировании подход "задеть лампу", как правило, наиболее эффективен (см. примечание в конце статьи). Недавно я убедился в этом, тестируя Star Wars: The Old Republic (сокращенно SWTOR) для Bioware Austin. Приведу пример.

Автор: Эрик Хан (Erik Hun)

Оригинал статьи: https://promptest.wordpress.com/2016/07/27/ever-noticed-what-do-you-do-between-finding-and-reporting-a-bug/

Перевод: Ольга Алифанова

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

Мы проводили рефакторинг одной из частей нашего приложения. Там использовался Javascript, и присутствовала корзина интернет-магазина. Я решил проверить, как она среагирует на максимально большие числа, и нашел баг. Перемножение очень больших чисел приводило, судя по всему, к фризу всей корзины. Я нажал F12, чтобы проверить, что происходит конкретно. Виноваты оказались не большие числа как таковые. Виновно было переполнение, возникающее из-за ошибки точности в Javascript (я быстро выяснил все про эту ошибку: http://www.w3schools.com/js/tryit.asp?filename=tryjs_inaccurate2). Ага, вот в чем дело! Как еще можно вызвать эту проблему? Я попробовал ввести совершенно обычные числа, которые спровоцируют ту же самую ошибку – и фриз повторился. Призванный на помощь разработчик даже не нуждался в подробных разъяснениях.

Почему бы не сообщить о баге сразу? Потому что баг, возникающий при перемножении 999999999999.99 на 99 вызовет реакцию "Какой нормальный человек так сделает", или "Ну засунь ее в бэклог, где-нибудь в 2038 году мы разберемся" – и такая реакция может быть вполне оправданной. Но демонстрация, что баг воспроизводится и на вполне обычных числах, вроде умножения 25,89 на 3, приведет к мгновенному исправлению проблемы.

Автор: Майкл Болтон (Michael Bolton)

Оригиналы: http://www.developsense.com/articles/2008-02-HowMuchIsEnough.pdf

http://www.developsense.com/blog/2009/09/when-do-we-stop-test/

http://www.developsense.com/2009/10/when-do-we-stop-testing-one-more-sure.html

Перевод: Ольга Алифанова

"Я знаю, как произнести "банан" по буквам, но я не знаю, когда мне остановиться", как сказала одна маленькая девочка.

Прелесть идеально "сценарных" задач в том, что мы всегда знаем, когда нам остановиться. Последняя нота, последняя строчка диалога в сценарии, последний кусочек пустого места на холсте означают, что конец работы близко. Если вы используете сценарный подход к тестированию, то вы останавливаетесь, если заметили проблему, или если у вас появились вопросы/любопытные идеи.

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

Как нам определить, когда нужно остановиться?

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

Я составил список эвристик для остановки тестирования, а также привел причины для сомнений в каждой из них.

А вы задумывались когда-нибудь, кто такой идеальный тестировщик? Усидчивый? Разносторонний? Ответственный?

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

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

Вредные привычки в тестировании, Андрей Мясников, Wargaming, Минск, Беларусь

Хороший тестировщик может всё, Юлия Абрамова, Группа компаний РЕЛЭКС, Воронеж, Россия

Правила отбора: как отобрать правильных тестировщиков в свою команду, Александр Орлов, Стратоплан.Ру, Санкт-Петербург, Россия

Уже открыта регистрация на следующую конференцию для специалистов в области качества программного обеспечения - SQA Days-20, Минск, ноябрь.

Как обычно для читателей нашего портала действует промокод на получение 10% скидки.

Промокод для получения 10% скидки - s-t.ru

Обсудить в форуме

Автор: Джефф Найман (Jeff Nyman)

Оригинал статьи: http://testerstories.com/2016/07/modern-testing-and-resilient-strategy/

Перевод: Ольга Алифанова

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

Эластичность и давление

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

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

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

Автор: Джеймс Бах (James Bach)

Оригинал статьи: http://www.satisfice.com/blog/archives/34

Перевод: Ольга Алифанова

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

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

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

Нас не беспокоит неустойчивое поведение, если оно а) так и задумано б) не несет в себе тайны, даже если оно не вполне предсказуемо. Например, результат подброшенной монеты или шанс выбить 777 в игровом автомате – вполне себе неустойчивое поведение. Даже загадочное неустойчивое поведение не волнует нас, если мы уверены, что оно не вызовет проблем. Когда я тестирую, я не думаю о магнитных полях или мелких скачках напряжения, хотя они влияют на мою работу постоянно.

Многие плавающие баги никем не обнаружены просто потому, что они еще ни разу не проявились (или проявились, но никто их не заметил). Все, что мы можем сделать – это позаботиться о создании наилучшего тестового покрытия и придерживаться этого подхода. Нет в мире алгоритмов для автоматического определения или предотвращения всех плавающих багов.

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

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

Перевод и адаптация: Кристина Журавлева (ПрактиТест)

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

Хотелось бы все-таки разобраться почему. В этом мне поможет англоязычная статья Джоэля Монтвелиски. Конечно перевод будет вольным с небольшими отступлениями и моими мыслями на эту тему.

Правда, что вы можете научить собаку нескольким трюкам, но вы уж точно не сможете научить ее летать.

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

1. “Родительские чувства” к коду

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

2. Акцентирование на позитивных моментах

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

3. Работа на основе принципа упрощения сложных вещей

Рассматривание сложных сценариев с целью нахождения багов является одной из составляющих процесса тестирования. В двух словах мы берем простую вещь и придумываем как ее можно усложнить.

Разработчики поступают ровно наоборот. Они берут сложный процесс или проект и разбивают его на более мелкие компоненты с целью найти решение проблемы.

Оригинальная публикация

Статья опубликована с согласия компании 1cloud

/ фото Sistema Bibliotecario Vimercatese CC

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

Работа в команде – ответственное занятие, поскольку в этом случае люди отвечают не только за себя, но и за окружающих, они общаются, помогают друг другу. Как бы это ни было банально, ключом к продуктивному общению между людьми всегда является вежливость и взаимоуважение. Однако все же есть определенный список фраз, которые – даже когда они звучат вежливо и корректно – не стоит употреблять в разговоре с разработчиками и тестировщиками, если вы их коллега, заказчик, «владелец» или руководитель проекта.

1. «Можешь закончить тестирование поскорее?»

Тестирование должно проводиться вдумчиво и тщательно, чтобы не пропустить критичные недоработки. Хорошее тестирование – залог качественного продукта. Разумеется, есть инструменты для ускорения процесса (вот несколько туториалов по автоматизации тестов, предложенные резидентами Stack Exchange), однако, даже автоматизированные тесты приходится поддерживать и постоянно модифицировать.

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