Home

19 ноября Юлия Нечаева провела вебинар "Тестирование для не-тестировщиков", организованный УЦ Люксофт. Вебинар получился совершенно нетехнический и очень философский. В нём был представлен взгляд на вопросы, возникающие в ходе тестирования, с точки зрения разных заинтересованных лиц. Иногда эти точки зрения вступали в противоречие, но Юля так и оставила эти противоречия открытыми, как это и случается обычно в жизни -- невозможно отдать предпочтение какой-либо из сторон, потому что обе по своему правы. В общем, смотрите, слушайте, и делайте выводы самостоятельно.

Автор: Прадип Саундараджан
Оригинал: http://testertested.blogspot.com/2009/12/why-testers-need-to-learn-to-write-code.html

Предисловие Алексея Баранцева

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

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

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

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

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

Пишите в своих блогах, публикуйте заметки в нашем коллективном блоге «Размышления о тестировании», может быть ваш опыт поможет другим тестировщикам принять решение о том, нужно ли им умение программировать, преодолеть страх перед чуждой стихией

А пока я передаю слово Прадипу.

Автор: Горбачик Лилия

Многие из нас работают на американский рынок, поэтому необходимо быть в курсе и держать руку на пульсе.
Если тестируемое вами приложение планируется продавать правительству США, то, оно должно соответствовать стандарту "Section 508".
В 1998 году Конгресс США принял закон, регулирующий право людей с ограниченными способностями на доступ к информационным технологиям. Таким образом, ПО, а также телекоммуникационные и медийные продукты, продаваемые правительству США, в обязательном порядке должны соответствовать Section 508.
В стандарте несколько пунктов, здесь будут рассмотрены только касающиеся десктопных приложений.

Автор: Алексей Лянгузов

Примечание: Данная статья была представлена в форме доклада на конференции SQA Days - 6. Доступен слайдкаст.

Какое-то время назад, я и не подозревал о том, что существует такое понятие как Context-Driven Testing, буду называть его Контекстным Тестированием (или КТ для краткости). Хотя я и сказал, что не подозревал об этом, но как оказалось, на протяжении всей моей карьеры инженера по тестированию, я руководствовался принципами, провозглашенными такими известными специалистами в тестировании ПО как Cem Kaner, James Bach и Bret Pettichord, которые являются авторами и проповедниками КТ.

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

Автор: Евгений Рыжков, ООО "СиПроВер"

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

В статье описаны технологии тестирования, используемые при разработке статического анализатора кода PVS-Studio. Разработчики инструмента для программистов делятся принциами тестирования собственного программного продукта, которые могут быть интересны разработчикам аналогичных пакетов обработки текстовых данных или исходных кодов.

Продолжаем публиковать слайдкасты выступлений на конференции SQA Days 2009 Piter: доклад Лилии Горбачик на тему "Тестирование Web Services". В начале доклада приводятся краткие пояснения архитектуры веб-сервисов для тех, кто не знаком с этим видом программных компонентов. Далее в докладе рассматриваются такие особенности тестирования веб-сервисов, как отсутствие пользовательского интерефейса, кросс-платформенность, а также необходимость проверки на соответствие стандартам XML, SOAP, WSDL. Уделено внимание не только функциональному тестированию (автоматизированному и ручному), но также тестированию производительности и защищенности веб-сервисов.

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

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

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

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

Автор: Пехов Алексей

Периодически, на всем протяжении моей работы в сфере тестирования, я, как и многие из нас, старался найти как можно больше информации в своей области, дабы облегчить и оптимизировать процесс поиска дефектов. Так уж получилось, что по части тестирования экономических программ, в частности 1С Предприятие, такой информации я, увы, не нашел, как ни старался. Теперь же, набравшись определенного опыта, хочу поделиться своими наработками и впечатлениями. Речь пойдет о тестировании системы на базе 1С Предприятие 8.1, однако жесткой привязки к производителю нет. Например, насколько я могу судить,  в Microsoft Dynamix AX много похожих моментов. Говорить буду больше не о базовой конфигурации, а о разработке конфигурации с нуля для некой компании по персональным требованиям.

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

Авторы: А. В. Баранцев, В. В. Кулямин, В. А. Омельченко, О. Л. Петренко, ИСП РАН.

Введение

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

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

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

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

Автор: Баранцев Алексей

Это эссе описывает учебный пример создания тестов для веб-приложения. Сначала показано, как создаётся и как выглядит план тестирования. Затем рассматривается модель, которая будет определять критерий отбора тестов. После чего строится собственно набор тестов.

Содержание:

1. Введение
   
2. Описание тестируемой системы, SRS
   
3. План тестирования, TP
   
4. Модель тестирования, TDS
   
5. Комплект тестов, TCS
   
6. Заключение