Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Лучшие вакансии

.
Тест-анализ и тест-дизайн
Расширяем тестирование граничных значений
05.12.2017 10:52

Автор: Юлия Миронова, ведущий специалист компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/extend-testing-of-boundary-values/

Самый первый метод тест-анализа, который каждый начинающий тестировщик постигает инстинктивно, – это метод граничных значений. Но так ли он прост, как это кажется на первый взгляд? Давайте разберемся!

Для сравнения разных подходов возьмем конкретный пример. Пусть у нас на сайте есть форма предварительного расчета стоимости страховки жизни, базирующаяся на очень простой формуле. Клиент вводит возраст и сумму в рублях, на которую он хочет застраховать свою жизнь. Если клиент моложе 18 лет или старше 60, выводится сообщение: «К сожалению, на данный момент у нас нет для вас подходящих предложений». Во всех остальных случаях мы просто считаем процент от введенной суммы; этот процент равен возрасту клиента. Да, я знаю, что в реальности расчет будет гораздо сложнее, но для наших целей такая модель подойдет.

Подробнее...
 
Мнемоника БМВ и ее применение: доклад Ольги Назиной на SQA Days 21
27.10.2017 11:20
Мнемоники помогают взглянуть на свой проект под новым углом или не забыть важные проверки.

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

Запись выступления Ольги Назиной на SQA Days 21 с докладом Мнемоника БМВ и ее применение
Напоминаем, что уже открыта регистрация на следующую конференцию для специалистов в области качества программного обеспечения- SQA Days-22, Санкт-Петербург, ноябрь.

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

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

Обсудить в форуме
 
Тест-аналитики – кто это?
17.07.2017 17:44

Автор: Специалист по тестированию компании "Лаборатория качества" Антон Алексеев

Оригинальная публикацияhttp://quality-lab.ru/test-analysts-who-is-this/

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

Я предлагаю читателю составить мне компанию и посмотреть, чем в течение дня занимается тест-аналитик (в мои обязанности входит работа не только тестировщиком, но и тест-аналитиком). Итак, добро пожаловать в мир аналитики!

Как выглядит мой обычный день в роли тест-аналитика

Утром мне на почту приходит письмо от заказчика с данными для получения дистрибутива продукта и формальными требованиями к нему. Плохие новости – технического задания как такового у нас нет. Хорошие новости – представитель заказчика оказался открытым к общению молодым человеком.

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

  • исследовать продукт;
  • составить логическую карту продукта;
  • разбить программный продукт на составные части;
  • расставить приоритеты тестирования.

Подробнее...
 
Кто такие тест-дизайнеры и зачем они нужны
07.04.2017 08:21

Автор: Антон Алексеев

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

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

Что такое «качественный программный продукт»? Это продукт, который выполняет поставленные перед ним задачи и удовлетворяет ожидания пользователей. Для достижения этого результата любая программа сначала проходит тестирование и только потом попадает в руки конечного потребителя. Так как сроки тестирования (как и любого процесса) имеют тенденцию стремиться к бесконечности, нам необходимо грамотное выстраивание процесса. И тут уже никак не обойтись без тест-дизайна.

Подробнее...
 
Переосмысление классов эквивалентности, часть 1
01.03.2017 11:31

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

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

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

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

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

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

"Классы эквивалентности – это техника тестирования ПО, которая делит вводимые данные на классы эквивалентных друг другу значений, на базе которых создаются тест-кейсы".

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

Подробнее...
 
Тест-кейсы – зло! Или все-таки нет?
08.02.2017 10:36

Автор: Джон Эндрюс (John Andrews)

Оригинал статьи: https://testingfromthehip.wordpress.com/2017/01/11/test-cases-are-evil-or-are-they/

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

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

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

Ряд недостатков тест-кейсов прекрасно документирован в статьях и блогах. Это обычно что-то вроде подобного списка:

Подробнее...
 
Бросьте костыли!
31.01.2017 10:57

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

Оригинал статьи: http://www.developsense.com/blog/2017/01/drop-the-crutches/

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

Эта статья – адаптация моих последних твитов. По ссылкам – ответы на некоторые из ваших вопросов. Как всегда, вопросы и комментарии приветствуются.

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

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

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

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

Есть ли в продукте проблемы, которые угрожают своевременному успешному завершению проекта?

Подробнее...
 
QA Fest 2016: Подборка выступлений о тест-дизайне
11.01.2017 11:03

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

Вы можете узнать о методиках, которые используют в работе более опытные коллеги, посмотрев видеозаписи докладов с конференции QA Fest 2016.

Подробнее...
 
Тест-план на одну страницу
12.12.2016 12:48

Автор: Клэр Рэклесс (Claire Reckless)

Оригинал статьи: https://dojo.ministryoftesting.com/lessons/the-one-page-test-plan

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

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

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

Джеймс Уиттакер писал о Тест-плане за десять минут несколько лет назад, описывая вызов, который он бросил своей команде. Его целью было получить ценность тест-плана как можно быстрее. Давайте рассмотрим этот подход с другой точки зрения, но со схожей целью. Сложность будет не во времени, а в пространстве. Как уложить тест-план в одну страничку?

А зачем его вообще писать?

Подробнее...
 
Эффективное использование тест-кейсов
28.11.2016 11:12

Выступление Елизаветы Батуриной на онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA, весна 2013 года.

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

Кейс, с одной стороны, помогает понять, что должна делать Система, т.е., что ожидается. А с другой стороны, показывает что может сломаться в данной ситуации и как это выявить.

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

Тестирование, основанное на кейсах, является более объективным, чем исследовательское тестирование. Вторым достоинством является четкое понимание времени, которое надо на проведение тестирования.

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

Подробнее...
 



Страница 1 из 5