Год назад произошло интересное – придумали необычный способ тестировать наш продукт. Подход повлиял на все процессы в компании и сказался на росте клиентской базы. Сейчас проведено уже более 50 тестов, и есть чем поделиться.
Метод скорее относится к инструментам Customer Development и затягивает в анализ всю команду разработки. Каждый тест с интересом смотрят и программисты, и дизайнеры. Мгновенно разгораются споры и обсуждения, как пофиксить баг или UX-проблему. График роста числа активных пользователей системы в день
Пробовал рассказать про подход другим продуктовым командам, но без примеров тема остается не раскрытой. Одна команда из четырех попробовала – и тоже получила отличный результат. Под катом – попробую рассказать подробно о том, как не совсем обычно мы тестируем YouGile, с примерами и деталями.
Автор: Пол Симан (PaulSeaman) Оригинал статьи Перевод: Ольга Алифанова
В моей прошлой статье "Не все могут тестировать" я отметил важность способности рассказывать о своем тестировании. Если вы хотите, чтобы люди понимали вклад тестировщика и ценность, которую привносят в разработку хорошие тестировщики и тестирования, вам нужно уметь рассказывать ясные, основанные на фактах, увлекательные истории. Если вы хотите возвысить тестирование в восприятии далеких от него людей, убрать слово "ручное" из термина "ручное тестирование", провести четкую грань между тестированием и автоматизацией тестирования – рассказывайте соответствующие истории. Рассказывайте истории с внятным контекстом, внятными сообщениями, истории, нацеленные на вашу аудиторию (да, это значит, что одна и та же история не сработает на разные аудитории). Возможно, кто-то удивится, что я использую термин "истории" вместо того, чтобы просто сказать "расскажите", и это логичный вопрос. Использование этого термина – намеренный выбор, потому что истории – хорошие истории – это мощный способ коммуникации с людьми. См., например, отрывок из Harvard Business Publishing.
Автор: Татьяна Рыжова — преподаватель английского языка в компании Лаборатория Качества, тренер курсаАнглийский язык для тестировщиков.
Каждый тестировщик сталкивается с формулировками, которые по своей длине могут состязаться с железнодорожным составом. Чего только стоят «check storage procedures», «passenger view function».
Даже если понятно значение каждого отдельного слова, велика вероятность того, что все словосочетание целиком будет переведено неправильно из-за того, что в английском языке зависимость между существительными выстраивается иначе, чем в русском языке. Такая сложность особенно характерна для технического английского.
В чем же все-таки тайна этих фраз, где есть только существительные? Этим я поделюсь в своей статье на примерах терминов, которые используют тестировщики в своей повседневной деятельности.
Автор: Ноэми Феррера (Noemi Ferrera) Оригинал статьи Перевод: Ольга Алифанова
На ряд концепций обращается очень много внимания в ходе разработки, но их обычно забывают при тестировании. Так, с моей точки зрения, происходит с многозадачностью и паралеллизмом. Я бы хотела обсудить их важность для тестирования.
Автор: Рикард Эдгрен (Rikard Edgren) Оригинал статьи Перевод: Ольга Алифанова
На EuroSTAR 2019 я читал доклад о характеристиках качества вместе с Хенриком Эмильссоном. Больше всего в этих конференциях мне нравится то, что ты никогда не знаешь, что произойдет. Как-то раз я закончил свой ответ фразой "если тестировать легко, вы что-то не так делаете". Помню, как доволен я был, сказав это. Эта фраза отлично подходила для контекста, в каком-то смысле подытоживая мое отношение к тестированию и причины, по которым я его так люблю.
Я забыл об этом, читая лекцию, но вспомнил, когда мы получили обратную связь от аудитории. Обратная связь была очень хорошей, но всем понравиться нельзя (если это происходит, вы что-то делаете не так).
Один из участников (не помню, кто, да это и не важно) был очень негативно настроен и сказал, что говоря, что "если тестировать легко – вы что-то делаете не так", мы показываем себя плохими, непрофессиональными тестировщиками.
Настало время объяснить, что я имею в виду. Кто-то наверняка со мной не согласится, но это может привести к интересным обсуждениям (или неконструктивным комментариям).
Цель видео не в том, чтобы вы буквально использовали этот список, чтобы заставить ваших коллег багроветь от злости от одного упоминания о вас! Намерение состоит в том, чтобы помочь вам сделать шаг назад и посмотреть, есть ли у вас плохие отношения с разработчиками и совершаете ли вы эти ошибки.
Теперь, когда с этим разобрались — давайте поговорим о том, как вызвать ненависть разработчиков к себе, если ты тестировщик!
Автор: Алан Ричардсон (Alan Richardson) Оригинал статьи Перевод: Ольга Алифанова
Краткое содержание: для испытаний системы в тестировании используются модели, и наша информация ограничена теми моделями, которые мы используем и строим. Мы можем варьировать их, чтобы увеличить вероятность нахождения информации, связанной с багами. Надо быть осторожными, чтобы не впасть в ложную уверенность.
Заметки о тестировании, вдохновленные цитатами Акоффа, Эшби, Дейкстры и Вайнберга.
На конференциях и в неформальных беседах на работе нет-нет да и возникает разговор о важности работы QA-инженера и его роли в проекте. Это может быть и робкий вопрос коллеги-программиста «А, может, выпустим без QA?», и объёмный доклад.
Проблема, как мне кажется, связана с тем, что эффективность труда сотрудников отдела QA обратно пропорциональна количеству «срочных, внезапно возникающих» сложных задач. Назовём это «парадоксом немецкого сантехника», который получает зарплату, когда у него нет вызовов: чем меньше протечек и аварий на его участке, тем качественнее и эффективнее его работа. Но чем меньше у него вызовов, тем больше кажется со стороны, что он ничего не делает.
Автор: Роберт Сабурин (Robert Sabourin). Оригинал статьи Перевод: Ольга Алифанова
Я нахожусь в постоянном поиске новых идей для тестирования. Некоторые из наиболее ценных идей приходят в голову непосредственно в ходе тестирования. Вот список из десяти источников тест-идей, которыми я пользуюсь при тестировании динамических тест-проектов:
Проектировщики самолёта отвечают на вопрос о его безопасности:
— Ничто не вечно, но современные авиалайнеры невероятно устойчивы, а самолёт — самый безопасный транспорт в мире.
Инженеры-строители отвечают о безопасности лифтов:
— Лифты защищены множеством отказоустойчивых механизмов. Их практически невозможно уронить в свободное падение.
Программисты отвечают на вопрос об электронном голосовании:
— Это просто ужасно.
— Серьёзно?
— Абсолютно. Не доверяйте программам для электронного голосования и не верьте никому, кто уверяет в их надёжности.
— Почему?
— Не совсем знаю, как это выразить, но вся наша область плоха в том, что мы делаем, и если вы будете полагаться на нас, то все умрут.
— Говорят, что надёжность гарантируется технологией под названием «блокчейн».
— А-а-а-а-а!!! Что бы они ни говорили, не прикасайтесь к этому! Закопайте поглубже. Не забудьте перчатки! Источник: XKCD, лицензия Creative Commons 2.5
