Home

Автор: Илья Ивасюв, тестировщик компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/localization-testing/

Что вы знаете о локализации продуктов? Имеете ли вы хотя бы приблизительное представление о том, какие проверки проводятся на проекте в рамках локализации? В этой статье я постараюсь помочь разобраться, в чем заключается локализация, какие проблемы и нюансы встречаются на пути разработчиков (а значит, и тестировщиков), и как их можно избежать.

Что такое локализация?

Языковая локализация – это процесс адаптации продукта, который ранее был переведен на несколько языков, для определенной страны или региона.

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

Автор: Баз Дийкстра (Bas Dijkstra)

Оригинал статьи: https://techbeacon.com/how-tech-giants-test-software-theres-no-one-way-qa

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

Команды и организации, стремящиеся наладить (или улучшить) усилия по тестированию своих продуктов, могут извлечь полезные уроки, наблюдая, как тестируют "взрослые" компании. Логично предположить, что такие корпорации, как Google, Microsoft, Amazon не смогли бы добиться успеха, не обращая пристального внимания на качество своих продуктов.

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

Google: в поисках лучших практик

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

Чтобы этого добиться, Google использует четырехступенчатый процесс внедрения изменений в поисковик:

1. Тестирование внутренними силами (сотрудники Google).
2. Тестирование на crowdtesting-платформе.
3. Использование продукта сотрудниками Google в повседневной жизни.
4. Бета-тестирование: выпуск продукта для использования небольшой группой конечных пользователей.

Автор: Нина Агеева, тест-менеджер компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/why-it-is-important-to-start-testing-as-early-as-possible/

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

Эксперты выделяют несколько этапов развития продукта:

• идея;
• стратегия;
• требования;
• дизайн;
• прототип и верстка;
• разработка и тестирование;
• поддержка.

Как правило, процесс тестирования начинается на предпоследнем этапе. Но правильно ли это? И в какой момент тестирование становится актуальной проблемой?

Оригинал статьи: http://katrinatester.blogspot.ru/2017/04/introducing-testers-to-developers.html

Автор: Катрина Клоки (Katrina Clokie)

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

Когда я заканчивала учебу на программиста, я создавала ПО без помощи тестировщиков. Под конец обучения я начала искать позицию разработчика, плохо разбираясь, с какими еще профессионалами мне придется сотрудничать в IT. Я не знала, кто такие тестировщики, чем они занимаются, и чем именно могут мне помочь. Думаю, я не одинока: в том же положении оказываются многие начинающие разработчики.

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

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

Автор: Брэд Томпсон (Brad Thompson)

Оригинал статьи: http://thinktesting.com/articles/role-of-confidence-in-software-testing/

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

Уверенность: "Твёрдая вера в кого-что-н., убеждённость". (http://dic.academic.ru/)

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

Оригинал статьи: https://beaglesays.wordpress.com/2017/07/16/the-illusion-of-quality-assurance/

Автор: Пол Симан (Paul Seaman)

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

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

Не пошла ли мода называть тестировщиков "специалистами по обеспечению качества" из Agile? Я, если честно, понятия не имею. Не думаю, что Agile стоит у истоков переименования тестировщиков в QA-специалистов, но судя по разговорам тестировщиков на конференции LAST, Agile-методология внесла в эту проблему свой вклад. Не будем называть имен, вот краткое содержание диалогов тестировщиков:

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

Оригинальная публикация: 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), то есть недетерминированные тесты ведут себя иначе. Они могут показать как положительный, так и отрицательный результат на одном и том же коде. Другими словами, сбой теста может означать, а может и не означать появление новой проблемы. И попытка воспроизвести ошибку путём перезапуска теста на той же версии кода может привести или не привести к успешному проходу теста. Мы рассматриваем такие тесты как ненадёжные, и в конце концов они теряют свою ценность. Если изначальная проблема — это недетерминизм в рабочем коде, то игнорирование теста означает игнорирование бага в продакшне.