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

Подписаться

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

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

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

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

.
Анализ и управление требованиями
Можно ли организовать тестирование без качественных требований?
21.07.2020 00:00

Да, если вы внедрите в свою работу методы восстановления информации о продукте!

17 августа 2020 стартует курс Тестирование без требований: выявление и восстановление информации о продукте.

Тренер Соковикова Виктория расскажет, как организовать и обеспечить глубокое тестирование, если на проекте отсутствуют идеальные требования.

На курсе вы научитесь:

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

Студенты получат шаблоны и чек-листы, которые помогут оптимизировать рабочий процесс.

Предлагаем вам познакомиться с автором курса и посмотреть короткий отрывок одного из уроков про то, как работать с неявными требованиями:


А вот несколько отзывов довольных студентов с первого потока курса:

Подробнее...
 
Comaqa Spring 2019: документация тестирования
16.06.2020 00:00

Публикуем подборку докладов с конференции Comaqa Spring 2019, посвященную требованиям и тест-кейсам.

  1. SQA Mate – Алексей Соцков, Dino Systems (Санкт-Петербург).
  2. 2. Как не надо оформлять требования – Юлия Носакова (Калининград).
  3. 3. На страже качества: test case review – Руслан Остропольский (Москва).
Подробнее...
 
Можно ли протестировать техническое задание за полчаса
18.05.2020 12:39

Автор: Виктория Соковикова, тренер курса “Тестирование без требований: выявление и восстановление информации о продукте

Можно ли протестировать техническое задание за полчаса?

Вы уже 18-й день готовите тест-кейсы на новый модуль системы. Написана не одна сотня сценариев. Вдруг обнаруживаете, что один из отчетов накладывает ограничение, которое не было нигде задокументировано. Действительно, аналитик забыл ограничить множество значений, а вам теперь переделывать 30% тестовой документации. Естественно, без возможности увеличить сроки своей работы. И как же теперь быть? Сроки поджимают, заказчик ждет результатов, нехватка времени давит со  всех сторон, все злятся друг на друга. Можно ли было этого избежать? Определенно да, если уделить немного времени тестированию технической документации.

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

Подробнее...
 
Ретроспективные уроки исследовательского тестирования: тестирование документации – больше, чем документация
25.06.2019 00:00

Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи: https://mrslavchev.com/2018/11/26/hindsight-lessons-about-exploration-testing-documentation-think-outside-the-dox/
Перевод: Ольга Алифанова

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

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

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

Подробнее...
 
Сладкоголосое пение тест-метрик
22.10.2018 14:42

Автор: Ким Энджел (Kim Engel)

Оригинал статьи

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

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

95% тестов прошло, 1% упал, 4% не прогонялись

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


Подробнее...
 
Видеозапись доклада Юлии Багрий с онлайн-конференции для тестировщиков КоТэ
02.07.2018 00:00

Публикуем запись доклада Юлии Багрий "Как тестировать идейно и быть Customer Success Advocate"

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

В данном докладе мы детальнее рассмотрим:

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

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


Обсудить в форуме
 
Тестирование требований. Особенности
12.01.2018 00:00

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

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

Введение

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

Тестирование требований направлено на то, чтобы уже на начальных этапах проектирования системы устранить максимально возможное количество ошибок. В перспективе, это позволяет:
Подробнее...
 
Тестирование «без» требований: поиск и организация информации
25.12.2017 00:00

Автор: Дженнифер Харрелл (Jennifer Hurrell)

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2015-June.pdf#page=3

Автор: Ольга Алифанова

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

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

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

Что же такое «требование», и почему тестировщикам оно необходимо?

Подробнее...
 
Зачем и почему нужна тестовая документация?
30.03.2017 15:59

Автор: Антонина Бжассо

Оригинальная публикация: http://quality-lab.ru/the-purpose-of-test-documentation/

Давным-давно…

Когда-то в юности я начала работать сотрудницей отдела тестирования в одной компании. Тестовая документация там существовала в виде чек-листов в Excel и каких-то требований на 1-2 странички для разработчиков, куда также иногда могли заглянуть и тестировщики. Со временем компания перестала выделять время на написание ЧЛ, но документация для разработчиков все еще оставалась в более или менее достойном виде. Так как компания занималась обычной разработкой программного обеспечения для мобильных устройств, то поддерживать актуальной тестовую документацию и вообще её создавать для тестировщиков оказалось накладно. Спецификация стала редкостью.

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

— Мы закончили делать in-app покупку тем!
— Ad-hoc сборка уже собралась! Через час надо выложить!
— Ещё мы критические баги исправили и вот эту “штуковину” засунули в код.
— Прогоните какой-то смоук, вдруг что-то сломалось!
— и т. д.

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

— Слушайте, а кто-нибудь помнит, что тут было? Кто-то знает, как оно должно работать?
— Не помню уже. Надо спросить у разработчиков…
— Хм… Думаешь, я помню, что я делал три месяца назад? У меня 5 приложений! Я уже не помню, где и что я когда-то писал…
… (время уходит)
— Да не знаю. Ну, пусть так будет.
— У меня твой баг не повторяется. А-а-а… ты э-э-ту кнопку нажимаешь при выходе?.. А я всегда ту нажимаю…
— Слушай, а ты не помнишь, как мы проверяли такие подписки? И вот это каким должно быть? Кажется, оно не должно быть таким… Не помню.

И спросить не у кого. Специалистов, которые бы занимались документацией, нет. Тестировщиками часто проводилось полное тестирование приложения, что отнимало много времени – целые недели, а иногда, и месяцы. И на вопрос: “Когда вы закончите проверять?”, следовал ответ: “Критические баги лезуууут!” Не было четкого понимания, сколько времени необходимо для тестирования программы. А время, как известно, – деньги. В итоге получалось нечто, что начинало жить своей жизнью…

Подробнее...
 
Кто такие аналитики и какие у них зарплаты
21.02.2017 16:49

Автор: Таисия Рыбак, тренер курса "Управление требованиями"

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

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

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



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