В качестве второй части ретроспективных уроков исследования я бы хотел сконцентрироваться на теме, которая редко обсуждается. Однако, с моей точки зрения, жизненно необходимо расширить свои горизонты в этой области, чтобы улучшить свой исследовательский подход.
Зачастую, когда я спрашиваю студентов, как бы они тестировали приложение, я получаю ответы вроде "Я сравню продукт с документацией или спецификацией". Логичным образом я задаю следующий вопрос – что, если спецификации нет, или продукт еще не создан?
В этой части цикла мы поразмышляем об исследовании артефактов, приносящем пользу тестированию, и разберемся, как построить тест-стратегию, имея или не имея документации, а также о том, как найти в ней баги. Иными словами, мы научимся мыслить вне рамок документации.
Когда вы отчитываетесь о тестировании, используя метрики, это может привести к незапланированным последствиям. Какие метрики мы регулярно используем для отчетов, и какую информацию почерпнут из них заинтересованные лица? Давайте детально рассмотрим несколько реальных примеров.
95% тестов прошло, 1% упал, 4% не прогонялись
Метрики "прошло/упало" очень популярны в традиционных отчетах о прогрессе тестирования. Представьте на минутку, что вы продакт-оунер, и ваше слово – решающее в вопросе, выпускать ли продукт в релиз.
Одни из частых заблуждений тестировщиков заключаются в том, что дефекты нужно искать после того как закончена реализация продукта или его части, а аналитика — «священная корова», которая не может ошибаться. Но это отнюдь не так, и тестировщики не должны бояться брать под сомнения адекватность требований.
В данном докладе мы детальнее рассмотрим:
почему упущенные проблемы на этапе построения требований к продукту гораздо серьезнее в перспективе для пользователя и сложнее в исправлении, чем таковые на более поздних этапах;
о том, как не допустить подобного негативного явления в своей практике;
а также о том, как устранять последствия, если ситуация уже зашла далеко.
В качестве примеров будут представлены несколько кейсов, как тестировщик мог сделать жизнь пользователям проще на основе опыта тестирования интеграции.
Доклад будет интересен всем, кто сомневается в необходимости тестирования требований, а также тем, кто знает, что нужно изменить, но не может определиться, как реализовать на практике.
Требования – это первое, на что смотрит команда проекта, это фундамент для проектирования и разработки продукта. Допущенная в документации ошибка или неточность может проявиться в самый неподходящий момент. Очевидно, что гораздо проще устранить дефект в паре строк требований, чем позже «перелопачивать» несколько сотен (или даже тысяч) строк кода.
Тестирование требований направлено на то, чтобы уже на начальных этапах проектирования системы устранить максимально возможное количество ошибок. В перспективе, это позволяет:
Когда-то давно я встретилась с потенциальным клиентом, чтобы обсудить тестирование его проекта. Вскоре после начала нашей встречи он, однако, осознал, что тестировать его проект нельзя, потому что полностью отсутствуют формальные требования. Короче говоря, они ничего не записывали. Он скептично отнесся к моему заявлению, что письменно зафиксированные требования необязательны для тестирования. «Но как же вы будете тестировать без требований? Как вы узнаете, баг это или не баг?» - «Спрошу».
Я пояснила свой ответ, объяснив, что зачастую я открываю для себя требования, не читая документацию по ним. Я, помнится, сказала, что он прав – я вполне могу не понять, баг это или не баг – поэтому я буду задавать кучу вопросов и обсуждать все несостыковки с проектной командой.
По пути домой я размышляла над нашим разговором и тем, как мне, как тестировщику, справиться с ситуацией, когда требования неясны или не записаны формально. Эта статья описывает процесс, который я использовала, чтобы выкопать и организовать информацию, нужную мне для тестирования, вне зависимости от доступности ее источников.
Что же такое «требование», и почему тестировщикам оно необходимо?
Когда-то в юности я начала работать сотрудницей отдела тестирования в одной компании. Тестовая документация там существовала в виде чек-листов в Excel и каких-то требований на 1-2 странички для разработчиков, куда также иногда могли заглянуть и тестировщики. Со временем компания перестала выделять время на написание ЧЛ, но документация для разработчиков все еще оставалась в более или менее достойном виде. Так как компания занималась обычной разработкой программного обеспечения для мобильных устройств, то поддерживать актуальной тестовую документацию и вообще её создавать для тестировщиков оказалось накладно. Спецификация стала редкостью.
Аргументом для прекращения написания тестовой документации и каких-либо спецификаций стало то, что на выходе убытков было больше, чем прибыли. Спецификация и различная документация себя не оправдывали, потому что требовать высокие цены за небольшие мобильные приложения компания не могла. Да и какие могут быть чек-листы на новую функциональность, когда:
— Мы закончили делать in-app покупку тем! — Ad-hoc сборка уже собралась! Через час надо выложить! — Ещё мы критические баги исправили и вот эту “штуковину” засунули в код. — Прогоните какой-то смоук, вдруг что-то сломалось! — и т. д.
В итоге приходилось без документации думать о том, что именно и на какие части могло повлиять. В срочном порядке нужно было проводить полноценное исследовательское тестирование за полчаса! При этом, нужно было найти критические для пользователей баги. Полчаса — это максимум времени, потому что выявленные проблемы еще нужно исправлять и перепроверять. Со временем при такой организации работы начинали возникать проблемы:
— Слушайте, а кто-нибудь помнит, что тут было? Кто-то знает, как оно должно работать? — Не помню уже. Надо спросить у разработчиков… — Хм… Думаешь, я помню, что я делал три месяца назад? У меня 5 приложений! Я уже не помню, где и что я когда-то писал… … (время уходит) — Да не знаю. Ну, пусть так будет. — У меня твой баг не повторяется. А-а-а… ты э-э-ту кнопку нажимаешь при выходе?.. А я всегда ту нажимаю… — Слушай, а ты не помнишь, как мы проверяли такие подписки? И вот это каким должно быть? Кажется, оно не должно быть таким… Не помню.
И спросить не у кого. Специалистов, которые бы занимались документацией, нет. Тестировщиками часто проводилось полное тестирование приложения, что отнимало много времени – целые недели, а иногда, и месяцы. И на вопрос: “Когда вы закончите проверять?”, следовал ответ: “Критические баги лезуууут!” Не было четкого понимания, сколько времени необходимо для тестирования программы. А время, как известно, – деньги. В итоге получалось нечто, что начинало жить своей жизнью…
Много статей о том, кто такие тестировщики и разработчики, как проходить собеседования, как расти по карьерной лестнице, но должность аналитика до сих пор остается загадочной. Кто они? Откуда берутся? Где этому учат? Я собрала ответы на наиболее популярные вопросы, которые мне задают студенты.
Материал разбит на 3 части. В первой части я расскажу о том, как становятся аналитиками, какие задачи ставят перед ними и какой уровень зарплат сейчас на московском рынке. Во второй части вы сможете узнать, какие навыки нужны, чтобы стать аналитиком, что нужно делать, чтобы двигаться дальше по карьерной лестнице. Какие навыки необходимы тестировщику, чтобы стать аналитиком. И, наконец, в третьей части вы прочтете о том, как проходит собеседование и какие вопросы Вам могут задать.
Иван Перл (ведущий инженер, Oracle), выступлениена конференции CEE SECR “Разработка ПО”.
Доклад о практиках, разработанных в компании Oracle, для генерации и повышения качества REST API документации. Применения этих практик привело к существенному улучшению качества документации, а также позволило проводить sanity тестирование REST API.
Публикуем подборку докладов с Analyst Days - 4, интересных для тестировщиков.
"Шагнуть навстречу тестированию требований. Советы тестировщика" – доклад Алексея Федорова о подводных камнях тестирования требований.
"После нас - хоть потоп! Как писать документацию на века" – доклад Кристины Ерофеевой о том, как создавать хорошую документацию.
"Немного об отношениях аналитика и тестировщика" – доклад Андрея Павлова об эффективном сосуществовании тестирования и аналитики.
"Как решить проблему, о которую уже все копья сломаны" – доклад Светланы Гончар об интегральном подходе к решению сложных проблем.
"Мы - хорошие, а они - плохие. Почему так происходит и что с этим делать" – доклад Надежды Тарасюк об эффективных коммуникациях в мультинациональных командах.
"Ревью проектных документов – борьба за качество" – доклад Андрея Кудинова о процессе ревью документации.
22-23 апреля 2016 г. в Санкт-Петербурге пройдет 5-я юбилейная международная конференция по системному и бизнес анализу «Analyst Days».
Наши читатели при регистрации на конференцию могут получить скидку.
