Home

Автор: Майкл Болтон
Оригинальная публикация: Swan Song
Перевод: Алексей Баранцев

Чёрным лебедем в одноименной книге Нассима Николаса Талеба называются невероятные и неожиданные события, приводящие к крупным неприятностям. Одна из наиболее важных целей тестирования -- обнаружение проблем в тестируемом продукте. Что могут сделать тестировщики, чтобы помочь снизить вероятность встречи с Чёрным Лебедем?

С самого рождения индюк видит, что люди -- это добрые, внимательные и заботливые существа. Фермер кормит индюка, содержит его в сухости и тепле, защищает его от хищников. Каждый день индюк получает всё новые и новые подтверждения своей фундаментальной уверенности в доброжелательности людей. А затем, за несколько дней до Дня благодарения, индюк получает неприятный сюрприз.

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

Автор: Michael Bolton
Перевод: Баранцев Алексей

Оригинальная публикация:
Why Is Testing Taking So Long? (Part 1),
Why Is Testing Taking So Long? (Part 2)

Часть 1

Если вы работаете в тестировании достаточно давно, вам наверняка задавали этот вопрос - "Почему тестирование занимает так много времени?" Может быть, у вас есть заготовленный ответ на этот вопрос, а может и нет. Здесь я предлагаю модель, которая, я надеюсь, поможет вам справиться с менеджерами, которые задают подобные вопросы.

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

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

Автор: Джеймс Виттекер (James Whittaker)
Перевод: Юлия Нечаева

«7 plagues of Software Testing» - это цикл из семи заметок Джеймса Виттекера, в мае 2009 года присоединившегося к команде Google в качестве Test Director. Этот цикл родился из его первого выступления (tech talk) в Google, где его выводы, по признанию самого Джеймса, были признаны ребятами из Google достаточно провокационными.

Оригиналы всех семи заметок опубликованы в блоге http://googletesting.blogspot.com/. Переводы заметок можно найти по тегу whittaker в блоге Юли Нечаевой: http://jnechaeva.blogspot.com/search/label/whittaker

Автор: Налютин Никита.

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

Классическая литература такие ситуации часто обходит: считается, что четко определенный процесс тестирования в подобных условиях не существует. На самом деле процесс есть, он просто другой. Целью становится не полное покрытие и документальное подтверждение следования технологии, а постоянная оценка и пересмотр критических мест системы, поддержание целостной информации о ее состоянии, ее функциональности и дефектах. В докладе пойдет речь о возможной организации такого процесса при помощи GTD, управления конфигурациями и быстрой визуальной оценки состояния системы.

Автор: Максим Гриневич

Доклад рассматривает подход к процессу тестирования исходя из реалий жизни небольшой софтверной аутсорсной компании. От каких документов можно отказаться в процессе тестирования? Что стоит делать в первую очередь и на что обращать внимание. Какой принцип ложится во главу угла, когда тестировщики определяются с объемом работы на проекте.

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

Доклад не лишен спорных вопросов, автор намеренно призывает задуматься над тем, что обычно воспринимается как «нужное» априори.

Ещё один слайдкаст доклада с конференции SQADays 2009 Piter -- выступление Юрия Цыганенко на тему "QA как услуга". В докладе рассматриваются различные аспекты взаимодействия поставщика QA-услуг с заказчиком, приводятся положительные примеры "как лучше", а также антипримеры, показывающие, почему часто получается "как всегда".

Продолжение серии слайдкастов с конференции SQA Days 2009 Piter: доклад Сергея Слесарева "Отличия в работе тестировщика в software-development компании и в банке". Название доклада говорит само за себя: докладчик  описывает и анализирует работу специалиста по качеству в банковской сфере, проводит сравнение с тестированием в сфере разработки программного обеспечения.

Автор: Стеценко Дмитрий

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

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

Этот доклад был представлен Александром Орловым на SQAdays 2009.

Там вообще была анимация, но сервис Slide Share ее куда-то зажевал. Если есть желание поглядеть слайдики с анимацией, то их можно скачать отсюда.

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