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

Подписаться

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

Конференции

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

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

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

.
Достаточно – это сколько? Тестирование как рассказ
09.10.2019 00:00

Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

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

Наша миссия не в том, чтобы выполнять определенный набор действий. Для большинства из нас миссия в том, чтобы узнать о продукте достаточно важной информации, чтобы наши клиенты (в основном разработчики и менеджеры) могли принимать информированные решения.

Подробнее...
 
Автоматизируй это! Как мы улучшали интеграционное тестирование
08.10.2019 00:00

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

В давние времена у нас было всего несколько сервисов, и выложить за сутки обновление более чем одного из них на production — было большой удачей работой. Потом мир ускорился, система усложнилась, а мы трансформировались в организацию с микросервисной архитектурой. Теперь у нас около сотни сервисов, и вместе с ростом их числа увеличивается и частота релизов — их более 250 в неделю.

И если новые фичи тестируют внутри продуктовых команд, то задача команды интеграционного тестирования — проверить, что изменения, включенные в релиз, не ломают функциональность компонента, системы и других фич.

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

Про изменения в релизном цикле и развитие механизма выкладки рассказывали со стороны ops и dev в одной из прошлых статей. Я же расскажу про историю изменения процессов тестирования в ходе этой трансформации. 

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

Подробнее...
 
Четыре причины для тестирования валидации ввода (хоть это и скучно)
05.08.2019 15:45

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова


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

Подробнее...
 
Как закрывать задачи в баг-трекере
04.10.2019 00:00

Автор: Назина (Киселева) Ольга (автор тренинга Школа для начинающих тестировщиков)

Аналогичную статью я написала в рабочем конфлюенсе в 2013 году. И на момент написания этой статьи (2019 год) она все еще была актуальна.

Исходно чек-лист записала как напоминание, в том числе и себе. Потому что к задачам приходится возвращаться, в том числе людям, которые их НЕ проверяли. Например, во время регрессии надо хотя бы базово проверить функционал.

И вот ты открываешь задачу, листаешь до последнего комментария посмотреть, какая документация, что как работает, а там… Пусто. Или скромное «Все проверено, все ок». А документация где? Я же не в теме задачи, я хочу прочитать побольше!

Или если заказчик пишет, что у него что-то не работает, а ты хочешь проверить, покрыта ли ситуация автотестами. Идешь в задачу, а там нет ссылки на автотесты. Их вообще не писали? Или просто ссылку не дали? Приходится выяснять…

image


Подробнее...
 
Покрытие кода и тест-покрытие: субъективность и полезность
03.10.2019 00:00

Автор: Дэн Эшби (Dan Ashby)
Оригинал статьи
Перевод: Ольга Алифанова

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

У моего сына Ангуса довольно давно есть игрушка-ходилка. Она помогла ему удерживать равновесие – сейчас, в возрасте 17 месяцев, он носится очень шустро, и нет сомнений, что в том есть заслуга игрушки.

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

Подробнее...
 
Эвристики для дебага интеграционных проблем
02.10.2019 00:00

Автор: Санджит Хохар (Sunjeet Khokhar)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

Подробнее...
 
Опыт использования BDD
01.10.2019 00:00

Автор: Сунагатов Ильдар, Юшкова Юлия (Haulmont)

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



    Около семи лет назад Dan North в своей статье описал практическое применение BDD подхода, который позволяет сделать процесс разработки более понятным и управляемым путем налаживания внутренних коммуникаций. Индустрия с каждым днем проявляет всё больший интерес к этой методологии, нацеленной на продуктивное взаимодействие стандартных команд типа «аналитика-разработка-тестирование».

    Однако, сейчас лишь малая часть компаний решается на использование BDD. Почему?

    Подробнее...
     
    Эвристики автоматизации, доклады по экономике тестирования и обучению тестировщиков, методы валидации результатов и продолжение серии статей о том, как отказаться от тест-кейсов: самые интересные новости тестирования за конец сентября-2019
    30.09.2019 13:18

    Опубликован очередной выпуск рассылки за вторую половину сентября.

    В выпуске собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

    Содержание рассылки доступно по ссылке.

    Подписаться на рассылку

     
    Легкий способ бросить тест-кейсы (часть 6)
    27.09.2019 00:00

    Автор: Майкл Болтон (Michael Bolton)
    Оригинал статьи
    Перевод: Ольга Алифанова

    Часть 1
    Часть 2
    Часть 3
    Часть 4
    Часть 5

    В прошлый раз мы остановились на вопросе "Как сфокусировать работу тестировщика, который уже что-то знает о продукте, не переусердствовав в этом?"

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

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

    Подробнее...
     
    SQA Days 25: подборка докладов по обучению тестировщиков
    26.09.2019 00:00

    Публикуем доклады с конференции SQA Days 25, посвященные вопросам обучения.

    • Buzzword Driven Management – Сергей Атрощенков, EPAM.
    • 4 цвета команды - простые основы – Петра Бускова, Tesena s.r.o.
    • Грабли вхождения в автоматизацию – Анастасия Заречнева, Noveo (Санкт-Петербург).
    • Хиромантия джуна или линии погружения новичка в распределенную команду – Роман Буданов, ООО "Лаборатория Качества" (Буденновск).
    • Создание программно-ориентированной программы для тестировщиков – Пол Джеррард, Gerrard Consulting (Мейденхед).
    • Взгляд изнутри на курс по тестированию или как самому создать эту машину – Ольга Изюрьева, АО "ПФ "СКБ Контур" (Екатеринбург).

     Записи докладов ниже

    Подробнее...
     
    Три способа тестирования валидации результатов
    25.09.2019 00:00

    Автор: Кристин Джеквони (Kristin Jackvony)
    Оригинал статьи
    Перевод: Ольга Алифанова

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

    Тестируя вывод, нужно думать о трех основных моментах:

    Как отображается результат?

    Отличным примером результата, внешний вид которого стоит проверить – это телефонный номер. Когда пользователь добавляет телефонный номер в базу данных вашего приложения, то этот номер (я надеюсь) сохраняется без любых скобок, точек и дефисов. Однако при отображении телефона для пользователя вы, возможно, не захотите выводить его как 8008675309 – это тяжело читается. Вы предпочтете, чтобы номер форматировался так, как этого ожидает пользователь. Для пользователей из США номер будет отображаться как 800-867-5309 или (800) 867-5309.

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