Использование персонажей - мощный инструмент тестирования, который помогает расширить понимание продукта и рождает новые идеи для тестов.
Если вы думаете и действуете, как определенный персонаж - вы можете найти баги, которые в норме не нашли бы никогда, застряв в рамках своего образа мыслей и действий.
Персонажей, которых можно использовать в тестировании, бесчисленное множество. Зачастую они изображают конкретных конечных пользователей. Но чтобы помочь вам мыслить еще более нестандартно, неплохо попробовать себя в роли персонажа-супергероя.
Предположим, у вас есть набор сценариев, которые вы гоняете ежемесячно в регрессе. Попробуйте внести в него новую нотку, воображая себя супергероем - это не только забавно, но и может помочь в поиске багов.
Затем вы можете ежемесячно менять тематику тестирования - например, почерпнуть идеи из Стар Трека, Игры Престолов, Властелина Колец, Дней нашей жизни, МакГивера, или выбрать любую другую тематику.
Каждый раз, когда вы меняете подход таким образом, задумайтесь, как бы поступали выбранные персонажи, как бы это повлияло на ваш продукт. Возможно, у вас родятся новые идеи!
Суть в том, чтобы поразмышлять над использованием выбранных персонажей в контексте вашего приложения. Может, у вас есть личное восприятие супергероев, или они использовали бы ваш продукт иначе - а может, вам нужен свой собственный набор персонажей, своя тематика, чтобы заставить мозг работать.
Ниже - список из некоторых супергероев и краткое описание, как их можно было бы использовать.
Не пришли ли вам в голову новые тесты, когда вы размышляете об этих персонажах?
22 апреля 2016 г. Пенза в восьмой раз станет IT-столицей! До конференции остаётся чуть меньше месяца, наступают самые горячие дни подготовки к межрегиональной конференции разработчиков программного обеспечения SECON’2016.
Ассоциация разработчиков программного обеспечения организует конференцию совместно с Центром кластерного развития Пензенской области уже не в первый раз и причин для этого несколько: это и низкая популярность профессии разработчика ПО, недостаточный образовательный уровень выпускников и их оторванность от реалий, катастрофическая нехватка кадров в ИТ-отрасли. Только объединив усилия, можно найти выход из создавшегося положения.
Конференция является знаковым событием для участников - программистов, веб-дизайнеров, руководителей IT-проектов и компаний, людей, которые только планируют связать своё будущее с IT – все те, кто хотят знать, что будет завтра, чтобы использовать информационные технологии уже сегодня.
На любой вкус
В этом году IT-мероприятие соберёт в стенах областной библиотеки им. М. Ю. Лермонтова, расположенной на проспекте Строителей, 168а, не менее 700 участников и более 40 спикеров из Москвы, Санкт-Петербурга, Омска, Ульяновска, Пензы и других городов России. В программе ожидаются тематические блоки, посвящённые серверному программированию, контролю качества, мобильным разработкам, базам данных, информационной безопасности, Web разработке, управлению, разработке игр, DevOps. Это наиболее актуальные темы, востребованные сегодня в среде программирования.
Среди известных в области разработок лидеров в SECONе’2016 примут участие Василий Васильков (Ecwid, Ульяновск), Алексей Лянгузов (Behavox, Санкт-Петербург), Дмитрий Евдокимов (Digital Security, Москва), Евгений Тюменцев (HWdTech, LLC, Омск), Роман Иовлев (EPAM, Санкт-Петербург), Звиад Кардава (РусБИТех, Москва), Сергей Аверин (Acronis, Москва), Юрий Куприянов (Москва), Алексей Пименов (ScrumTrek, Москва) – и это далеко не полный экспертный список ожидаемых гостей.
Я много размышлял о проверках и тестах и том, как заставить их гармонично сосуществовать, и подумал, что мы упускаем что-то важное, создавая проверки. Я сконцентрируюсь на автоматических проверках, но думаю, что мои мысли применимы и к неавтоматическим.
Некоторые команды сейчас достигли неплохого прогресса в создании автоматических проверок. Они перенимают передовой опыт. Классы, методы и объекты грамотно названы, и совершенно очевидно, что именно они делают. Условия ясно сформулированы, и если они не выполняются, об этом сообщается четко и внятно. Проверки создаются с хорошим уровнем абстракции и повторным использованием кода, они достаточно производительны и выполняются быстро и надежно. Все это очень здорово выглядит.
Но почему эта чудесная, хорошо составленная и удобопонятная проверка вообще есть? Почему она существует? Почему из всех вариантов проверок была выбрана именно она? Я могу ее прочитать (как я уже говорил, она хорошо написана), я вижу, что именно она проверяет, но этим информация о ней исчерпывается. Как я пойму, что шаги и условия проверки соответствуют ее первоначальной цели? Что именно в этой проверке или этом поведении системы сделало их достойными кандидатами на автоматизацию? Я не знаю.
Все программы, которые мы тестируем, работают с информацией. Когда одна и та же информация хранится в разных местах, то это вызывает проблемы при работе — неясно, где самая актуальная информация; при изменении надо найти все копии и синхронно их изменить; сложно разделять права доступа. Это является источником потенциальных проблем.
Во вводной лекции курса "SQL для тестировщиков" мы рассказываем, как реляционные базы данных помогли решить эти проблемы и заняли лидирующее положение в области хранения данных. Банки, страховые компании, интернет магазины используют реляционные базы данных в своих приложениях.
Чтобы не пропустить ошибок при тестировании программ, работающих с базами данных, нужно учитывать их особенности. Лекция знакомит вас с основами реляционных баз данных — объясняет структуру хранения информации, принципы связей между данными и существующие ограничения.
В трансляцию блогов еженедельно добавляются новые блоги. Их количество уже давно перевалило за отметку 100. Ну а мы продолжаем знакомить Вас с новыми блогами.
Мы занимаемся тестированием во всех его проявлениях и рады поделиться своим опытом.
О блоге:
В блоге мы будем писать о нашем повседневном тестировании. О полезных инструментах и прочитанных книгах. И обо всем другом с чем сталкиваемся во время работы.
Сайт DOU.UA публикует дайджесты, посвященные тестированию (оригинальная публикация на DOU.UA). Но так как в России у многих этот сайт заблокирован, то мы с разрешения автора будем перепубликовывать дайджесты на нашем сайте.
Меня зовут Максим, я работаю тестировщиком ПО, с интересом слежу за событиями в мире тестирования и IT. Самое полезное собираю вместе и с радостью делюсь с вами. Приятного чтения! :)
Новости
Сервис Badoo открыл охоту на баги безопасности и платит за найденные дефекты.
Случалось ли, что вы бесились, пользуясь компьютером?
Для такой реакции есть тысячи причин. Долго грузится сайт. Дурацкие сообщения об ошибках мешают вам работать. В пунктах меню совершенно невозможно найти то, что вам нужно.
Каждый раз, когда вас бесит что-то подобное, вы сталкиваетесь с тем, что в тестировании называют багом. Проще говоря, баг - это что-то, что вас раздражает, а моя задача - предотвратить проникновение багов к вам.
Чтобы сделать это, я разговариваю с людьми бизнеса, которые заказывали программу, с дизайнерами, решающими, как она будет выглядеть, и с аналитиками, определяющими, как именно она будет работать. Я вспоминаю прошлый опыт и стараюсь предотвратить повторение старых ошибок.
Я сижу рядышком с разработчиками, пишущими код, и подмечаю проблемные моменты, пока они трудятся. Иногда они что-то упускают, или я могу не согласиться с их подходом.
Когда программа готова, я проверяю, работает ли она. Я раздумываю, какими способами люди могут, случайно или намеренно, сломать ее, и стараюсь убедиться, что программа с этим справится. Я удостоверяюсь, что она работает на разных компьютерах и мобильных устройствах. Я проверяю, удобно ли ее использовать, отзывчива ли она, безопасна ли.
Все это время я занимаюсь тестированием. Я тестирую, когда я общаюсь с людьми. Я тестирую, пользуясь приложением на своем компьютере. Я тестирую, создавая автоматические проверки, которые можно прогонять неоднократно, чтобы убедиться, что различные части программы правильно работают.
Тестирование помогает устранить раздражающие вас штуки. Люди должны быть счастливы, используя программу, и тестирование вносит в это важный вклад.
Все мы знаем о делении тестирования на функциональное и нефункциональное. Споры по поводу этих терминов длились несколько лет. С моей точки зрения, это проблемные понятия, и, возможно, лучше бы вовсе обходиться без них.
Суть проблемы
Проблем, достойных рассмотрения, тут три:
Первая проблема: плохие определения, неподходящие термины
Участники процесса разработки ПО могут легко стать жертвами плохой коммуникации и понять коллег неверно, и зачастую виной тому используемые слова. Когда речь идет о новых идеях и технологиях, некоторая первоначальная путаница вполне естественна, однако не стоит использовать двусмысленную терминологию там, где этого можно избежать. Я полагаю, что "нефункциональное" и "функциональное" тестирование - это именно такая терминология. Далее по тексту я проясню свою позицию.
Ученый, рассказчик, или официальный представитель?
Мне с трудом далась четвертая глава книги Джеймса Баха "Lessons Learned in Software Testing" ("В защиту багов"). Нет, она не была менее понятной или более интеллектуально насыщенной, чем первые три. Просто она полна противоречий.
Вопрос в моем подзаголовке очень волнует меня. В некотором роде тестировщик выполняет каждую из этих ролей. Ранее я уже говорил об этом. Однозначно ответить на этот вопрос невозможно. Крутой рассказчик может быть уважаемым ученым. А прекрасный ученый - интереснейшим рассказчиком.
Но тут всплывает более интересный вопрос - а как мы должны воспринимать сами себя, когда мы создаем и курируем свои баг-репорты? Бах, Кейнер и Петтикорд дают на это очень расплывчатый ответ.
Судя по главе в книге Баха, авторы рисуют два крайне различных - и очень противоречивых - портрета тестировщика. С одной стороны, это дисциплинированный, объективный, дотошный автор отчетов, который борется с желанием все преувеличить и выдает только голые факты, необходимые для принятия рациональных решений насчет реакции на баг-репорт.
"Вы информ-бюро... Ваша задача - сообщать о багах точно и внятно, чтобы читатель понял весь объем проблемы... Если вы преувеличиваете серьезность бага, вы утратите доверие... Ваша работа - сообщать о багах, а не выяснять, почему они произошли... старайтесь быть нейтральным... Не настаивайте на фиксе каждого бага, расставляйте приоритеты..."
С другой стороны, тестировщик отстаивает баги, вкладывается в них эмоционально, и мотивирован бороться за них из политических соображений. Он готов использовать свое влияние в офисе через головы коллег, чтобы вопросы исправления багов решались так, как нужно ему.
"Любой баг-репорт - это адвокатская речь, призывающая к исправлению этого бага... это инструмент продаж, его цель - убедить людей... вы можете обнаружить сравнительно минорный баг и, исследуя его, узнать о серьезных последствиях... Чтобы баг исправили, вам нужно заставить всех ответственных за контроль изменений одобрить это исправление... Если убедить разработчиков сложно, но вы считаете, что баг надо исправить, подумайте, кому в компании еще выгодно исправление этого бага..."
Какой портрет более точный? Какую роль выбирать? Читая эту главу, определиться невозможно. На самом деле я вообще не уверен, что из этой главы можно извлечь некий универсальный принцип. Реальность такова, что иногда вы просто докладчик, а иногда - адвокат, и чтобы понять, какую роль сыграть, нужен опыт. Хотелось бы, конечно, чтобы Джеймс Бах и Кем Кейнер изложили чуть больше своих идей на этот счет.
