Home

Автор оригинала: Dan Ashby

Автор: Грегори Пачига (Gregory Paciga)
Оригинал статьи
Перевод: Ольга Алифанова

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

Что же с этим делать?

Недавно я задал этот вопрос в Slack-группе тестировщиков и на форуме Министерства Тестирования. Вот основные идеи, рожденные в этих обсуждениях. Я расположил их по степени полезности, от наименее полезных к наиболее. Спускаясь ниже, мы подберемся ближе к тому, что я считаю первопричиной. Буду рад услышать другие мысли на этот счет.

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

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

Это верно: "тест" – перегруженное слово. В некоторых контекстах оно относится к эвристическому процессу: к оценке продукта путем его изучения через опыт, исследования и эксперименты; это имеют в виду тестировщики, говоря о тестировании, и именно так мы описываем тестирование в Rapid Software Testing. В других контекстах "тест" означает алгоритмический процесс: применение правил принятия решений к результату работы некой функции или механизма.

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

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

Автор: Маарет Пюхяярве(Maaret Pyhäjärvi)
Оригинал статьи
Перевод: Ольга Алифанова

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

Автор: Ли Хокинс (Lee Hawkins)
Оригинал статьи
Перевод: Ольга Алифанова

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

В этой финальной статье я размышляю над вопросом, как будет выглядеть тестирование в 2021 году (примечание: я исправил год с 2020 на 2021).

Для большинства людей, занятых в тестировании, в 2021 оно будет в целом таким же, как и в 2020 – и таким же, как оно выглядело много лет до этого. Инкрементные улучшения занимают у организаций время, а масштаб и влияние этих изменений сильно варьирует у разных организаций и даже у разных частей одной и той же организации.

Автор: Ли Хокинс (Lee Hawkins)
Оригинал статьи
Перевод: Ольга Алифанова

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

В этой статье я отвечу на вопрос "Легко ли тестировать?" (и связанный с ним вопрос "Почему тестировать так трудно?").

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

Автор: Алан Ричардсон (Alan Richardson)
Оригинал статьи
Перевод: Ольга Алифанова

Краткое содержание: пессимизм ставит под сомнение статус кво. Отрицательная обратная связь заставляет систему меняться. Путем изменений мы становимся лучше.

Вам не нужно быть пессимистом…

… вы предоставляете информацию. Иногда информация играет роль негативной обратной связи.

Нужно ли тестировщику быть пессимистом?

Нет.

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

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

Автор: Ли Хокинс (Lee Hawkins)
Оригинал статьи
Перевод: Ольга Алифанова

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

Добравшись до середины серии, я столкнулся с вопросом "Можно ли автоматизировать тестирование?" (и связанным с ним вопросом, "Как автоматизировать тестирование?").

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