Home

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор: Владимир Янц (Badoo)
Оригинальная публикация

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

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

На Badoo PHP Meetup в марте я рассказывал, как организовать мутационное тестирование для PHP-кода и с какими проблемами можно столкнуться. Видео доступно по ссылке, а за текстовой версией добро пожаловать под кат.