Home

Автор: Александр Федоров

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

Автор: Наталья Руколь

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

Автор: Алексей Федорко

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

Если в качестве инструмента у вас имеется лишь молоток, каждая проблема начинает напоминать гвоздь. Абрахам Маслоу

В этой небольшой заметке я бы хотел рассмотреть инструмент для попарного тестирования от Microsoft – PICT (Pairwise Independent Combinatorial Testing). Уже несколько раз я применял его в своей работе и был доволен теми гибкими опциями, которые он имеет.

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

Критерий — это некоторый признак, который имеет три основных назначения: при помощи него производится 1) оценка, 2) определение и 3) классификация. Рассмотрим эти три назначения по очереди применительно к тестированию программного обеспечения. Критерий начала тестирования. Критерии прекращения и завершения тестирования. Еще раз о метриках и оценках.

Автор: Наталья Руколь

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

Словарь

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

Публикация компании IT-Online

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

Модель проектной группы MSF (MSF Team Model) описывает подход Майкрософт к организации работающего над проектом персонала и его деятельности в целях максимизации успешности проекта. Данная модель определяет ролевые кластеры, их области компетенции и зоны ответственности, а также рекомендации членам проектной группы, позволяющие им успешно осуществить свою миссию по воплощению проекта в жизнь.

Подведены итоги очередной онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA.
Как обычно публикуем лучший по результатам голосования доклад.
Это доклад Натальи Руколь "Тест-анализ на основе состояний и переходов".

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

• Как эти тесты продумать?
• Как обеспечить высокое покрытие не избыточным количеством тестов?
• Какие инструменты есть для тестирования состояний и переходов и как их использовать?

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

Автор: Юлия Нечаева

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

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

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

Анализ границ - эту технику каждый тестировщик осваивает, наверное, самой первой.

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

Что будет, если пользователь, случайно или намеренно, пересечёт такую технологическую границу - введёт слишком большое число или слишком длинную строку? Должен ли тестировщик пытаться это выяснить? Или может быть достаточно предупредить пользователей, чтобы они не вводили "плохие" данные, а кто ввёл - мы ответственности не несём? А если всё таки мы решили, что тестировщику следует пытаться всё это проверить -как искать эти границы, если они нигде не описаны?

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

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

{iframe src="//player.vimeo.com/video/42284184" width="500" height="234" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen}{/iframe}

Переходя все границы... (Алексей Баранцев, SQADays-11) from Stas Fomin on Vimeo.

Хотите узнать больше про различные техники тест-дизайна? Приходите на онлайн-тренинг Практикум по тест-дизайну или очный тренинг в Москве Тест-дизайн от А до Я

Автор: Илья Комендантов

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

Когда встречаю объявления типа: "В связи с расширением штата сотрудников, требуется..", "Молодая развивающаяся компания ищет.. " и подобные им, сразу представляю, как маленькое село вырастает в пгт, оно, в свою очередь, в город, а тот – в мегаполис.

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

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

Такое себе – нагрузочное тестирование. Может стоит для анализа проблем фирмы нанимать перформанс инженеров? Почему бы и нет.. Интересно, были прецеденты?