Home

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

В мире разработки программного обеспечения популярна идея, что за тестирование отвечает вся команда.

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

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

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

Глупо утверждать, что разработчики не умеют тестировать. В процессе написания продукта они постоянно что-то тестируют: пишут код, проверяют, работает ли он; если нет — чинят; если да — двигаются дальше. Разработчик не может стабильно писать полезный код, не проверяя хоть что-нибудь хотя бы время от времени. И всё же было бы опрометчиво полагаться на то, что у разработчиков всегда есть время, мотивация, стимул и нужный взгляд на вещи, чтобы полностью взять на себя весь объём тестирования.

Автор: Михаил Кургузов

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

Возможные проблемы

1. Плохое знание продукта и некорректное тестирование

   Тут многое зависит от того, кто именно будет проводить тестирование локализации. Представьте пример — у вас есть баг, при котором текст не появляется в нужном окошке. Но исполнитель не очень знаком с продуктом и вообще не знает, что в этом окошке должен быть текст. 

2. Отсутствие консистентности на разных версиях оборудования

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

Если вы выдаете чужую работу за свою — вас не будут уважать ни окружающие, ни вы сами. Если вам платят за умственный труд, а заказчик начинает подозревать, что умственным трудом у вас и не пахнет — у него пропадёт желание платить. Если вы шлете кому-то ворох идей и данных, а потом выясняется, что вы просто ввели короткий промпт, а потом вставили сгенерированный текст в файл — произойдёт как минимум одно из двух: либо результат понравится, и человек поймёт, что вас можно заменить ИИ, либо адресат не поверит содержанию и решит, что вы его просто заспамили.

В современном мире у меня выработался новый рефлекс. Когда кто-то, кого я не знаю близко, делится со мной отчётом, анализом или просто на первый взгляд вдумчивым текстом — первой реакцией у меня стало не верить, что он сам это сделал. Я автоматически обесцениваю работу людей, у которых нет репутации оригинальных мыслителей.

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

Привет! Мы команда из отдела разработки ПО для банкоматов Т-Банка: Александр, Владислав, Иван и Денис.

Расскажем о необычном, но интересном опыте автоматизации и роботизации тестирования банкоматного ПО в Т-Банке, для которого мы использовали коллаборативного робота.

Ручное тестирование нового ПО АТМ (automated teller machine или по-нашему: банкомат)трудозатратно, требует много времени и ресурсов. Зачастую действия повторяются и QA выполняет одни и те же тест-кейсы. Нашей целью было высвободить ресурс QA, уйдя от рутинного ручного тестирования к более творческим задачам путем роботизации ручного тестирования.

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

Я всегда интересовалась здоровьем и фитнесом, потому что хочу жить долго и полноценно. Но с возрастом я поняла, что методы, которые раньше помогали мне оставаться в форме, перестали работать: я постепенно набрала 30 фунтов (~13,5 кг) и поняла, что нужно что-то менять. Изменения были внедрены, и я вернулась к своему прежнему весу.

В последнее время я много говорила о качестве программного обеспечения и о том, почему командам сложно внедрять хорошие практики. И сегодня меня осенило: между поддержанием здоровья по мере взросления и поддержанием «здоровья» программного обеспечения много параллелей. Давайте рассмотрим распространённые оправдания, которые мешают оставаться «в форме».

Привет! Меня зовут Михаил Кургузов, я из отдела локализации и переводов SM Lab. В этом цикле постов я расскажу о локализации и ее интеграции в процесс тестирования ПО. 

• Пост #1 (вы находитесь здесь) — общая вводная про локализация и интернационализацию, важные примеры, лингвистические ошибки и функциональные баги, особенности разных языков.

• Пост #2 — особенности тестирования локализации, кто чем занимается, как проходит процесс.

• Пост #3 — чеклист, лучшие практики, дополнительные материалы и много полезных примеров.

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

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

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

Оригинальная публикация
Автор: Сергей Терентьев

Зачем нам управлять временем?

В начале немного о себе, мое основное занятие — обеспечение качества на вверенных проектах, я Senior QA в компании Umbrella IT. Периодически при тестировании микросервисов приходится сталкиваться с необходимостью изменения времени для проверки работы того или иного функционала. Это может быть функционал, который срабатывает по «тику» cron, или связанный с применением системного времени как одного из условий обработки/хранения/передачи данных тестируемым микросервисом.

Если микросервис разворачивается в Docker, то время контейнера берется из системного времени хост машины и без дополнительных инструментов максимум, что мы можем поменять — это часовой пояс контейнера, но не само системное время. Проблема в том, что часто для целей тестирования просто изменения часового пояса, ровно как и изменения времени в пределах 24х часов, оказывается недостаточно. Что делать если нам нужно протестировать работу микросервиса в граничных значениях даты‑времени, например начало и конец месяца/года, или использовать замечательные даты, такие как 29 февраля, последние даты месяцев со сменой количества дней, и так далее?