Home

Публикуем подборку докладов с конференции Comaqa Spring 2019, посвященную общим вопросам тестирования и автоматизации.

1. 1. Тестирование по-космически – Алексей Ткаченко (Минск).
2. 2. Сказ об автоматизации тестирования – Александр Пушкарев (Минск).
3. 3. Автоматизация инфраструктурного тестирования– Андрей Ю (Москва).

Публикуем подборку докладов с конференции Comaqa Spring 2019, посвященную особенностям тестирования в стартапе.

1. 1. Особенности проведения тестирования в стартапе – Яна Рыжова, Елена Захарова, EPAM (Нижний Новгород)
2. 2. Startup Company. My Experience – Вадим Климец (Кремниевая долина, США)

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

Прошлым летом я прочитала интересную книгу - Extreme Ownership. Она написана двумя морскими офицерами и рассказывает о концепции принятия всесторонней ответственности за свою работу – даже за то, над чем у вас, по ощущениям, нет контроля. Если кто-то из их солдат делал ошибку, офицеры брали ответственность на себя – ведь они могли тренировать солдата получше. Если их командир принимал сомнительное решение, офицеры брали ответственность и за это тоже, потому что они могли бы "управлять снизу" и предоставить информацию, которая привела бы к решению получше. Когда все практикуют "Экстремальную вовлеченность", в результате рождается культура совершенствования и достижений.

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

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

Алекс Бунарджич задал мне вопрос, который вдохновил меня на целую статью:

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

Спасибо за вопрос, Алекс, и вот мой ответ.

Автор: Джоэп Шууркс (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)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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