Home

Публикуем доклады с конференции 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-кода и с какими проблемами можно столкнуться. Видео доступно по ссылке, а за текстовой версией добро пожаловать под кат.

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

Практически каждый крупный язык программирования имеет тест-фреймворки BDD, и Python – не исключение. На самом деле у Python их даже несколько? Как их сравнивать, какой из них лучше? Давайте разберемся.

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

• Бережливый подход к QA - A/B тестирование, мониторинг, автоматизация – Катерина Черникова, Wix.
• Деньги как метрика в приоритизации багов – Кристина Столяренко, ООО "Клин.ру" (Москва).
• Экономика тестирования. Версия 2.0 – круглый стол (Алексей Федоров, Андрей Павлов, Андрей Ладутько, Александр Александров, Александр Лукашев, Александр Куцан).

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

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

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

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

Недавно я имел счастье делать доклад на конференции UKStar 2019 в Лондоне, и говорил о том, как задавание правильных вопросов (подсказка – сначала спрашивайте "зачем", а потом "как") помогает командам и организациям предотвратить "автоматизацию ради автоматизации" и повысить шансы на то, что тест-автоматизация станет важной и значимой частью жизненного цикла разработки и тестирования.

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

Автор оригинала: Monica Lent

Оригинальный перевод

Скоро наступит десятый год, как я профессионально занимаюсь программированием. Десять лет! И кроме формальной работы, почти две трети своей жизни я что-то создавала в интернете. С трудом вспоминаю годы, когда я не знала HTML: даже странно, если подумать об этом. Некоторые дети учатся музыке или балету, а я вместо этого создавала волшебные миры, кодируя в своей детской.

Размышляя об этом первом десятилетии регулярного получения денег за ввод странных символов в терминал, хотелось бы поделиться некоторыми наблюдениями, как изменилось моё мышление за годы работы.

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

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

Для ясности подчеркну, что джуниоры потрясающие: просто появляться на работе, чтобы учиться новому, — это уже требует тонны мужества. Это статья о моём собственном опыте и обучении. Я вовсе не обобщаю, что все младшие разработчики так думают или ведут себя.

Надеюсь, пост вам понравится и напомнит что-то из прошлого или настоящего.

Спасибо Артёму и Саре за отзывы!