Оригинальная публикация: https://habrahabr.ru/company/pvs-studio/blog/330762/

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

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

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

Поговорим о деньгах, потерянных из-за ошибок в программном обеспечении, и росте нашей зависимости от программного кода. Тема неоднократно обсуждаемая (в том числе моим коллегой — Андреем Карповым — "Большой Калькулятор выходит из-под контроля"), и каждый новый пример доказывает: качество кода — не то, чем можно пренебрегать.

Смирнов Николай. Личный перевод из книги «Искусство тестирования» Г. Майерса

Оригинальная публикация: https://habrahabr.ru/post/330746/

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

1. Обязательная часть тестирования – определение ожидаемого результата;
2. Программистам следует избегать тестирования их собственных программ (и участков кода);
3. Организациям, создающие программы, следует избегать тестирования их собственных программ;
4. Процесс тестирования должен включать в себя тщательную проверку результатов каждого теста;
5. Тест-кейсы должны быть составлены как для корректных и ожидаемых входных условий, так и для некорректных и неожидаемых;
6. Исследование Системы на предмет того, что она не делает того, что должна, — лишь пол дела. Вторая часть – разобраться в том, чего недолжного она делает;
7. Избегайте одноразовых тест-кейсов, только если сама программа не является одноразовой. Одноразовые тест-кейсы для одноразовых программ. В остальных случаях следует избегать таковых;
8. Не занимайтесь процессом тестирования с предустановкой, что вы не найдете ошибок;
9. Вероятность наличия ошибок в определенной части Системы пропорционально количеству уже найденных здесь ошибок;
10. Тестирование – это вызов вашим творческим и интеллектуальным способностям. Тестирование – это невероятно творческое и интеллектуальное занятие.

Оригинальная публикация: https://habrahabr.ru/company/ascon/blog/327582/

Недавно вышла новая версия САПР КОМПАС-3D v17, но вплоть до самого финального релиза в систему еще вносились изменения, тестирование продолжалось. О том, какие испытания проходил новый КОМПАС-3D, прежде чем попасть к пользователям, рассказывает команда КОМПАС-3D из Центра разработки АСКОН в Коломне.

Каждой новой версии предстоит преодолеть множество этапов тестирования, в котором принимает участие практически все: программисты создают юнит-тесты, аналитики проводят юзабилити-тестирование, группа автоматизированного тестирования разрабатывает сценарии с применением пользовательского интерфейса, API и специальных тестовых функций. Эта же команда отвечает за тестирование производительности, конверторов и обширной базы пользовательских документов.

«Долина Дали» автор Дмитрий Верба

При проверке такой сложной системы, как КОМПАС-3D, без ручного тестирования обойтись нельзя. Все тестировщики, выполняющие ручное тестирование, имеют опыт конструкторской работы на производстве и не понаслышке знают, как и зачем пользователи применяют ту или иную функциональность КОМПАС-3D.

Автор оригинальной статьи: Джефф Листфилд, testing.googleblog.com/2017/04/where-do-our-flaky-tests-come-from.html

Перевод: Анатолий Ализар, Habrahabr.ru (https://habrahabr.ru/post/327394/)

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

Ненадёжные (flaky), то есть недетерминированные тесты ведут себя иначе. Они могут показать как положительный, так и отрицательный результат на одном и том же коде. Другими словами, сбой теста может означать, а может и не означать появление новой проблемы. И попытка воспроизвести ошибку путём перезапуска теста на той же версии кода может привести или не привести к успешному проходу теста. Мы рассматриваем такие тесты как ненадёжные, и в конце концов они теряют свою ценность. Если изначальная проблема — это недетерминизм в рабочем коде, то игнорирование теста означает игнорирование бага в продакшне.

Автор: Андерс Динсен (Anders Dinsen)

Оригинал статьи: https://asym.dk/2016/12/10/playful-software-testing/

Перевод: Ольга Алифанова

Я отлично пообщался с Джессикой Инграсселино в Нью-Йорке в сентябре. Джессика руководила воркшопом по игривому тестированию в течение недели преобразований в тестировании (я читал доклад на конференции про "Тестирование – это область черных лебедей", но, к сожалению, все никак не найду времени об этом написать.

В основном мы говорили о философии.

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

У нее есть взгляд на то, как сделать тестирование игривым и увлекательным.

Автор: Клэр Рэклесс (Claire Reckless)

Оригинал статьи: https://dojo.ministryoftesting.com/lessons/so-what-is-software-testing

Перевод: Ольга Алифанова

Если бы вам пришлось ответить на вопрос "Что такое тестирование?", что бы вы сказали? Это понятие довольно трудно впихнуть в пару-тройку коротких предложений.

Плюс к тому многие недопонимают, что же такое тестирование, чем занимаются тестировщики – даже среди самих тестировщиков. Тестирование как навык и как профессия постоянно развивается. В этой статье мы рассматриваем, чем тестирование является, и чем нет.

Из чего состоит тестирование

Расследование

Расследование определяется как "наблюдение или изучение путем близкого наблюдения и систематического изучения" [1].

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

Автор: Сергей Бронников

Оригинальная публикация: https://bronevichok.ru/

Каждый раз, когда я встречаюсь с проектом, в котором без причины изобрели свой новый формат отчётов мне хочется сделать что-то ещё для популяризации существующих форматов. За последнее время таких случаев было несколько. В первый раз я добавил поддержку подсветки синтаксиса TAP в библиотеку highlight.js, потом добавил поддержку синтаксиса формата SubUnit. Ну и в последний раз после встречи с одним из таких проектов я собрал воедино всю информацию по этим форматам в одном месте и получилась небольшая книжка. Таким образом этот текст -- мой крестовый поход против разножопицы с тестовыми результатами в разработке ПО :)

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

Оригинал статьи: http://www.developsense.com/blog/2011/09/testing-problems-are-test-results/

Автор: Майкл Болтон (Michael Bolton)

Перевод: Ольга Алифанова

В курсе Rapid Software Testing я даю студентам такое упражнение: я прошу их перечислить все, что, с их точки зрения, усложняет или замедляет тестирование. Их ответы, как правило, однотипны – я регулярно слышу одни и те же вариации (пример таких ответов можно посмотреть, к примеру, в обсуждении на Stack Exchange). Обычно это примерно следующий перечень:

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

Оригинальная публикация: http://bytextest.ru/2017/02/15/bug-report-kak-pisat/#more-4457

Вы когда-нибудь видели под вашим багом комментарий “it is not reproducible”? Чувствовали, как екает сердце от статуса “waive requested”? Иногда команда разработчиков «разворачивает» баг, который вы так трепетно лелеяли и выхаживали. Ну, может не так уж и трепетно, раз его все таки не смогли воспроизвести.

Нажмите на картинку, чтобы увеличить изображение

Представьте ситуацию, когда, например, баг был заведен в Mozilla Firefox. Допустим, на сайте не работает кнопка «login». Так и запишем, попутно забыв указать в STR (шагах воспроизведения) — какой именно браузер и какую его версию мы использовали. А вот разработчик использует, допустим, Edge. И в их среде кнопка работает нормально. Соответственно, баг отклоняют за невозможностью воспроизведения и комментарием: «Может быть, проблема в вас?» Вы, как порядочный тестировщик, перепроверяете ошибку, находите ее и переоткрываете баг. Чем все закончится — непонятно.

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

Автор: Барт Ванхерк (Bart Vanherck).

Оригинал статьи: http://www.bartvanherck.be/2017/01/12/testers-can-learn-from-the-hunger-games/

Перевод: Ольга Алифанова

Недавно я прочитал первую часть трилогии "Голодных игр" Сьюзан Коллинз. Книга, если задуматься, крайне интересная. Что можем мы, как тестировщики, вынести из Голодных игр?

1. Исследуй свое окружение

Когда Китнисс, главная героиня книги, входит в виртуальный мир, она понятия не имеет, что он из себя представляет. Каждый год игры проводятся в новом виртуальном пространстве. Что это значит для нее? Ей нужно познакомиться с этим пространством. Где находится вода, где можно найти еду, и так далее. Как она это делает? Исследуя мир вокруг себя.

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

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