Цель практически всех проектов по разработке ПО – это разобраться, как именно система будет добавлять бизнесу ценность. Эта цель достигается путем постоянных переговоров, в ходе которых исследуется, разрабатывается и расширяется общее понимание того, что именно нужно создать и почему. Тестировщики должны вносить свой вклад в эти переговоры проактивно, а не заниматься исключительно чтением результатов чужих обсуждений и тупым выполнением задач, переданных в тестирование.
Эластичность и давление
Когда я говорю об эластичности, я имею в виду способность системы (неважно, людей или технологии) подстраивать функциональность перед, во время или после изменений или неувязок так, что система продолжает функционировать как в ожидаемых, так и в неожиданных условиях.
Коммуникация между командами – это способ повлиять на проектные решения приложения, сформировать список возможностей для развития и быстро принять решение, какие фичи нужно разрабатывать. Для того, чтобы этот подход был успешным, тест-команда должна быть эластичной.
Что это значит на практике? Это значит, что не нужно привязываться к куче артефактов или огромным тест-сьютам (неважно, автоматизированным или нет) – их сложно каждый раз менять по результатам вышеописанных переговоров. Если учесть, что в идеальном мире такие переговоры итеративны, тест-команды должны тащить на себе минимальный "багаж" из артефактов вроде тест-кейсов и тест-инструментов.
Способность уверенно исследовать плавающие баги – одна из характеристик отличного тестировщика. Самые захватывающие истории, которые я слышал от тестировщиков, были про охоту на "белых китов" в океане сложного кода.
В отличие от багов, которые загадочным образом воспроизводятся постоянно, плавающий баг – это больше проблема тестирования, нежели разработки. Многие программисты просто не хотят гоняться за причинами таких проблем, если есть куда более доступные жертвы.
Вообще-то плавающие баги не должны вас удивлять. Все программирование, можно сказать, крутится вокруг контроля неустойчивого поведения. Итак, о чем речь?
Нас не беспокоит неустойчивое поведение, если оно а) так и задумано б) не несет в себе тайны, даже если оно не вполне предсказуемо. Например, результат подброшенной монеты или шанс выбить 777 в игровом автомате – вполне себе неустойчивое поведение. Даже загадочное неустойчивое поведение не волнует нас, если мы уверены, что оно не вызовет проблем. Когда я тестирую, я не думаю о магнитных полях или мелких скачках напряжения, хотя они влияют на мою работу постоянно.
Многие плавающие баги никем не обнаружены просто потому, что они еще ни разу не проявились (или проявились, но никто их не заметил). Все, что мы можем сделать – это позаботиться о создании наилучшего тестового покрытия и придерживаться этого подхода. Нет в мире алгоритмов для автоматического определения или предотвращения всех плавающих багов.
Итак, то, что обычно называется плавающим багом – это загадочное, нежелательное поведение системы, которое наблюдалось как минимум единожды, и которое мы не можем спровоцировать повторно.
Наша задача – превратить плавающий баг в обычный, раскрыв тайны, окружающие его. После этого он становится головной болью программистов.
Перевод и адаптация: Кристина Журавлева (ПрактиТест)
Многие слышали, что разработчики не могут быть хорошими тестировщиками.
Хотелось бы все-таки разобраться почему. В этом мне поможет англоязычная статья Джоэля Монтвелиски. Конечно перевод будет вольным с небольшими отступлениями и моими мыслями на эту тему.
Правда, что вы можете научить собаку нескольким трюкам, но вы уж точно не сможете научить ее летать.
Давайте рассмотрим несколько пунктов по которым разработчикам не суждено стать тестировщиками в привычном понимании этого слова.
1. “Родительские чувства” к коду
Разработчики привязаны к тому, что они пишут. Может быть это прозвучит глупо, но очень сложно оценивать объективно то, что ты создаешь.
2. Акцентирование на позитивных моментах
Работа разработчика основывается на позитивных сценариях и их реализации в продукте. Чтобы работать тестировщиком нужно иметь диаметрально противоположный склад ума, так как тестировщики всегда акцентируются на негативных сторонах продукта нежели чем на позитивных. Следовательно разработчику нужно поменять склад ума, чтобы стать тестировщиком, а это не кажется столь реальным на мой взгляд.
3.Работа на основе принципа упрощения сложных вещей
Рассматривание сложных сценариев с целью нахождения багов является одной из составляющих процесса тестирования. В двух словах мы берем простую вещь и придумываем как ее можно усложнить.
Разработчики поступают ровно наоборот. Они берут сложный процесс или проект и разбивают его на более мелкие компоненты с целью найти решение проблемы.
Практически каждая крупная организация нанимает в свой штат разработчиков программного обеспечения. При этом только треть из них заняты непосредственно в бизнесе, связанном с ИТ. Но вне зависимости от того, где они работают: в фармацевтической компании, образовательной или рекламной сферах, они остаются программистами.
Работа в команде – ответственное занятие, поскольку в этом случае люди отвечают не только за себя, но и за окружающих, они общаются, помогают друг другу. Как бы это ни было банально, ключом к продуктивному общению между людьми всегда является вежливость и взаимоуважение. Однако все же есть определенный список фраз, которые – даже когда они звучат вежливо и корректно – не стоит употреблять в разговоре с разработчиками и тестировщиками, если вы их коллега, заказчик, «владелец» или руководитель проекта.
1. «Можешь закончить тестирование поскорее?»
Тестирование должно проводиться вдумчиво и тщательно, чтобы не пропустить критичные недоработки. Хорошее тестирование – залог качественного продукта. Разумеется, есть инструменты для ускорения процесса (вот несколько туториалов по автоматизации тестов, предложенные резидентами Stack Exchange), однако, даже автоматизированные тесты приходится поддерживать и постоянно модифицировать.
В идеале тестирование начинается еще на этапе проектирования продукта и продолжается до самого релиза, а дизайнеры и разработчики плотно взаимодействуют с тестировщиками. Если в вашей компании происходит иначе, то, поздравляем, вы узнали рецепт задержек, ошибок и недостатка бюджета (вот еще несколько вещей, которые не любят слышать тестировщики).
В обеспечении качества различают верификацию и валидацию. Верификация отвечает на вопрос, правильно ли мы создаем продукт, а валидация – на вопрос, а то ли мы вообще создаем, что нужно. Некоторые люди проводят водораздел между обеспечением качества и тестированием, исходя именно из этих определений.
С моей точки зрения, использование терминов "верификация" и "валидация" может привести к ложным дихотомиям. Для меня тестирование – это деятельность, связанная с дизайном, и поэтому покрывает довольно широкую область. Я верю, что тесты могут стать неким "общим языком". Я верю, что тесты могут напрямую кодировать спецификации и требования. И я верю, что тесты – это источник знаний об области или продукте. Слишком большой упор на разницу между верификацией и валидацией – это неэффективный и не результативный способ понять, как именно тестирование дополняет обеспечение качества.
С моей точки зрения, неспособность воспринимать тестирование и обеспечение качества, как два различных, дополняющих друг друга процесса – это восприятие, которому явно не хватает некоторого изящества.
На самом деле я согласен, что различия между верификацией и валидацией вполне оправданы. В конце концов, эффективность – это способность делать что-то правильно. Результативность, с другой стороны – это способность выдавать правильный результат. Эффективность сфокусирована на процессе и нацелена на доведение его до конца, а результативность – на продукте (то есть, собственно, на результате этого процесса). Можно сказать и так: эффективность концентрируется в первую очередь на том, чтобы избежать ошибок, а результативность – на успехе вне зависимости от количества промахов, допущенных по пути.
Однако мне кажется, что есть способ различать эффективность и результативность, который куда лучше понимания разницы между верификацией и валидацией. Ведь тестирование прямо-таки требует гибкости и инноваций.
После очередной уборки на сервере выяснили, что у нас осталось несколько неопубликованных докладов со старых онланй-конференций. Те доклады, информация в которых еще не устарела постараемся выложить в ближайшее время.
Сегодня представляем доклад Станислав Косарева
Каждый менеджер должен уметь делегировать задачи, иначе он не менеджер. Остается только 1 вопрос: как или каким образом доверять своим подчиненным? Откуда уверенность, что все сделано правильно, откуда стойкое ощущение того, что все хорошо? Наверное, потому, что ты, как менеджер, постоянно перепроверяешь то, что делают твои ребята. Класс! Тогда другой вопрос. Каким образом ты модернизируешь свою работу? Если перепроверяешь – то тратишь время, а значит, не успеваешь даже подумать о чем-то новом, о том, что может перевернуть твою работу с ног на голову…
В своём докладе я расскажу о том, как делегировать задачи по тестированию без перепроверок, экономя своё время и не переживая за результаты тестирования.
Публикуем подборку докладов с Analyst Days – 5, которые пригодятся тестировщикам.
"To requirements and beyond..." – доклад Оливье Дену о взаимодействии тестировщиков и аналитиков и их общем вкладе в качество продукта.
"Как повысить личную информационную эффективность" – доклад Екатерины Калининой об умении эффективно работать с информацией.
"Коммуникация при различной структуре мышления - таксономия против фолксономии" – доклад Максима Цепкова о том, как эффективно взаимодействовать с людьми, чье мышление отличается от вашего.
"Ловушки прошлых проектов при разработке новых" – доклад Анны Горбатенко об обучении на прошлых ошибках.
Выступление Алексея Баранцева для сообщества тестировщиков Екатеринбурга.
Мы, тестировщики, постоянно вторгаемся в область незнаемого. Мы стремимся узнать, как работает программа, и донести полученное знание до тех людей, которым оно может пригодиться. Но полученные знания и у нас тоже остаются, мы не забываем то, что узнали однажды, а иногда даже записываем, чтобы уж точно не забыть. Потому что нам эти знания тоже могут пригодиться.
Но иногда бывают ситуации, когда знание вредно, а незнание полезно. Знание притупляет чувства. Мы знаем, чего ожидать, и это создает ложные предпосылки, мы склонны замечать то, что ожидаем увидеть, и игнорируем то, что не вписывается в наши ожидания. Как с этим бороться? Нужно постоянно подвергать свои знания критическому анализу. Отправлять свои знания обратно в незнаемое, и переоткрывать их вновь, с обостренными чувствами.
Впрочем, не стоит беспокоиться по поводу имеющихся знаний. Незнаемого гораздо больше. И оно тоже не однородно. Есть вещи, про которые мы знаем, что мы их не знаем. Это работа для аналитиков. А есть вещи, про которые мы не знаем, что мы о них не знаем. А это -- поле исследований для тестировщиков.
Несмотря на то, что инженеры-автоматизаторы в большинстве случаев автоматизируют только поверхностно, отрасль не перестает поклоняться автоматизации, и это неспроста. Однако такое положение вещей угрожает ручным тестировщикам - особенно тем, кто работает бок о бок с автоматизаторами.
Вот что могут сделать тестировщики, у которых нет навыков программирования, чтобы повысить свою ценность:
Такие браузеры, как Mozilla Firefox и Google Chrome сильно облегчают жизнь тестировщика. Я использую оба, но Chrome лидирует по количеству полезных расширений, которые я могу применять в работе.
Большинство читателей нашего сайта используют Chrome (примерно 70%). Чем не доказательство, как мы, тестировщики, любим этот браузер? Он очень облегчает наш труд. Он облегчает конкретно мой труд, и поэтому я его так люблю. Firefox, я помню о тебе!
Ранее я составлял список важных дополнений Firefox, полезных для тестировщиков, и аналогичный список для Chrome был вполне логичным продолжением. Представляю вам список потрясающих расширений Chrome для тестировщиков! Это вам не просто список случайных расширений - это наиболее полное перечисление тех расширений, которые пригодятся при тестировании ПО.
Расширения Chrome для тестировщиков
Google Chrome - это самый мощный и самый известный браузер в мире (источник). У него удобный интерфейс, он мало весит, и его можно дополнительно улучшать различными расширениями.
Это основная причина его популярности как среди разработчиков, так и среди тестировщиков.
Большинство расширений из списка ниже я применяю в работе постоянно, и они просто чудо. Дочитайте до конца, и вы согласитесь со мной!
Если вы используете расширение Chrome, которого нет в этом списке - сообщите мне об этом, и я добавлю его.
Перевод и адаптация: Кристина Журавлева (
Оригинальная публикация