Home

Автор: Джоэп Шууркс (Joep Schuurkes)
Оригинал статьи
Перевод: Ольга Алифанова

Джеймс Линдси создал ряд потрясающих загадок черного ящика. Это крошечные приложения, которые подталкивают вас разобраться, что же они делают (поддержать Джеймса в создании этих загадок можно на его Patreon-страничке). У двух из этих загадок –29 and 31 – теперь есть не только интерфейс, но и API.

Это навело меня на мысль. Если исследовать загадки через графический интерфейс, то начинаешь с ввода – пробуешь различные виды ввода в надежде выявить логику вывода. Затем эта логика поощряет дальнейшее исследование.

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

Три важных замечания, прежде чем я расскажу вам, как и что я делал.

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

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

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

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

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

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

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

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

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

• Инструменты для тестирования блокчейн-приложений – Люсьян Стапп, Stowarzyszenie Jakości Systemów Informatycznych.
• Когда научная фантастика становится реальностью тестировщика: глубокое обучение и тестирование интернета вещей – Ярослав Гришко, SJSI - Polish Testing Board (Вроцлав).
• Тестирование инфраструктуры в AWS – Ксения Чистова, Exness.
• Как приручить SmartTV зоопарк – Наталия Борисова, Онлайн кинотеатр Okko (Санкт-Петербург)

 Видео докладов ниже.

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

Я работаю тестировщиком несколько лет, и привыкла к различным типам тестирования – таким, как приемочное, регрессионное, исследовательское, смоук. Но недавно меня познакомили с новым типом, о которым я раньше не задумывалась – с предварительным тестированием.

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

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

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

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

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

Материал подготовлен компанией SimbirSoft

Успех IT-проекта во многом зависит от того, насколько грамотно организована система тестирования и обеспечения качества (Quality Assurance, QA) на всех этапах его жизненного цикла. 

Для специалиста по QA один из самых надежных способов подтвердить свои профессиональные качества ─ наличие международного сертификата ISTQB. Сегодня поговорим о том, что дает такая сертификация сотруднику, работодателю и бизнесу, а также о том, как мы в SimbirSoft поддерживаем квалификацию QA инженеров.

Автор оригинала: Hillel Wayne

Оригинальная публикация
Перевод статьи

Должен признаться: я читаю ACM Magazine. Это делает меня «ботаником» даже по меркам программистов. Среди прочего, я узнал из этого журнала о «метаморфическом тестировании». Раньше я никогда о нём не слышал, как и все люди, которых я спрашивал. Но научная литература по этой теме на удивление объёмна: есть множество невероятно успешных примеров её применения в совершенно разных областях исследований. Так почему же мы не слышали о нём раньше? Существует только одна статья для людей вне научных кругов. Пусть теперь их будет две.

Автор: Джеймс Бах (James Bach)
Оригинал статьи: https://www.satisfice.com/blog/archives/5290
Перевод: Ольга Алифанова

Рим был построен не за один день, но хватило всего шести дней, чтобы он по случайности сгорел дотла в 64 году нашей эры. Он был заново отстроен с учетом пожарной безопасности. А когда в 1903 году при пожаре в театре "Ирокез" в Чикаго погибло 502 человека, уже в 1904 году нормы пожарной безопасности повысились. Пожар на фабрике "Трайангл" в Нью-Йорке (146 погибших) привел к основанию Нью-Йоркского Бюро пожарной безопасности, а Национальная Ассоциация Пожарной Безопасности сейчас поддерживает несколько сотен различных норм и требований – и многие из них появились вследствие особо трагичных пожаров. Люди учатся на трагедиях.

Наша компания разрабатывает систему КОМПАС-3D для построения трехмерных моделей и чертежей. Проект зрелый – в этом году ему исполнилось 30 лет. Над продуктом работают 9 команд в двух городах – Коломне и Рязани.

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