Как-то так, ребятки!
Добавил чуток ссылок, может кому-то будет полезно, если вы новичок в нашем деле:)
http://telegra.ph/QA-Helpful-links-02-07
Добавил чуток ссылок, может кому-то будет полезно, если вы новичок в нашем деле:)
http://telegra.ph/QA-Helpful-links-02-07
Telegraph
QA Helpful links
Здесь будут собраны ссылки на полезный материал, который помог мне в самом начале на пути становления true-тестировщика. Пока без особого форматирования и разбиения по категориям - просто скопом. Позже буду дополнять и форматировать:) RSpec: gems documentation:…
Возникла ситуация - нужно было протестировать задачу с фиксацией времени в линуксе, а так как стандартное изменение времени не работает в докере, и при этом изменение часового пояса мне не подходит т.к всё равно время в формате UTC используется, то нашёл следующее решение.
Эта апликуха подставляет фейковое время при выполнении команд.
Установка:
Использование:
Задаётся начальное время отсчета
либо без знака
В этом случае время зафиксируется и не будет меняться.
Например:
Эта апликуха подставляет фейковое время при выполнении команд.
Установка:
git clone https://github.com/wolfcw/libfaketime.git && cd libfaketime && make install
Использование:
faketime -f '@2018-02-21 20:01:00' <команда>
Задаётся начальное время отсчета
либо без знака
@
faketime -f '2018-02-21 20:01:00' <команда>
В этом случае время зафиксируется и не будет меняться.
Например:
> faketime -f '@2018-02-21 20:01:00' date
Wed Feb 21 20:01:00 +05 2018
Мне тут стало интересно узнать немного об аудитории.
anonymous poll
Прохожу(-шёл) курсы по тестированию – 17
👍👍👍👍👍👍👍 33%
Не работаю в тестировании, но планирую – 8
👍👍👍 16%
Работаю меньше 1 года – 8
👍👍👍 16%
Ищу работу – 6
👍👍 12%
Работаю от 2 до 3 лет – 6
👍👍 12%
Работаю от 3 до 5 лет – 3
👍 6%
Работаю от 1 года до 2 лет – 2
👍 4%
Работаю от 5 до 10 лет – 1
▫️ 2%
Работаю более 10 лет
▫️ 0%
👥 51 people voted so far.
anonymous poll
Прохожу(-шёл) курсы по тестированию – 17
👍👍👍👍👍👍👍 33%
Не работаю в тестировании, но планирую – 8
👍👍👍 16%
Работаю меньше 1 года – 8
👍👍👍 16%
Ищу работу – 6
👍👍 12%
Работаю от 2 до 3 лет – 6
👍👍 12%
Работаю от 3 до 5 лет – 3
👍 6%
Работаю от 1 года до 2 лет – 2
👍 4%
Работаю от 5 до 10 лет – 1
▫️ 2%
Работаю более 10 лет
▫️ 0%
👥 51 people voted so far.
Существует 7 принципов тестирования
1. Тестирование демонстрирует наличие дефектов, а не их отсутствие
2. Исчерпывающее тестирование недостижимо
3. Раннее тестирование сохраняет время и деньги
4. Кластеризация дефектов
5. Парадокс пестицида
6. Тестирование зависит от контекста
7. Заблуждение об отсутствии ошибок
Именно принципы тестирования являются основой всех стандартов, книг, методов и техник тестирования.
Их понимание является фундаментом знаний тестировщика и позволяет работать быстрее, качественнее и эффективнее.
1. Тестирование демонстрирует наличие дефектов, а не их отсутствие
2. Исчерпывающее тестирование недостижимо
3. Раннее тестирование сохраняет время и деньги
4. Кластеризация дефектов
5. Парадокс пестицида
6. Тестирование зависит от контекста
7. Заблуждение об отсутствии ошибок
Именно принципы тестирования являются основой всех стандартов, книг, методов и техник тестирования.
Их понимание является фундаментом знаний тестировщика и позволяет работать быстрее, качественнее и эффективнее.
Как правильно составить резюме, если ты никогда не работал в IT?
Думай как работодатель. Разберем по пунктам:
🌕 1. Оформление. Резюме должно быть оформлено на конкретную специальность. Не нужно указывать желаемую должность "Junior QA Engineer", (просто QA Engineer), а последнее место работы - «Бариста». Если нет релевантного опыта, не пишите. Занимались смежной деятельность? Укажите, если хотите показать, что навыки будут полезны на текущем месте. 1 резюме = 1 специализация.
🌕 2. Место работы. Если мы рассматриваем удаленную работу, указать город - Москва. Зачем? Работодатели из Москвы будут рассматривать вас в первую очередь и ставка по оплате будет выше. На удаленной работе в офис ехать не нужно, а зарплату больше получить реально.
🌕 3. Личные качества. Вы должны показать себя не только как специалист, но и как человек, с которым комфортно работать. Приветствуется: открытость, энтузиазм в работе, желание расти и развиваться в своей специальности, покорять вершины. Если что-то нашли в себе, укажите это в резюме обязательно.
🌕 5. Сопроводительно письмо. Если понравилась вакансия, всегда пишите сопроводительное письмо. Это будет означать вашу заинтересованность, что заставит работодателя открыть ваше резюме среди сотен других и ознакомиться.
🌕 6. Опыт. Что делать, если нет опыта? Учитесь. Постройте план развития и учитесь. С планом развития могут помочь менторы, если не найдете обучающих программ, которые вам понравятся. И повторюсь - всё, что вы узнали, чему научились, — указывайте в резюме. Работодатель увидит ваш энтузиазм и с большим шансом обратит на это внимание.
Думай как работодатель. Разберем по пунктам:
🌕 1. Оформление. Резюме должно быть оформлено на конкретную специальность. Не нужно указывать желаемую должность "Junior QA Engineer", (просто QA Engineer), а последнее место работы - «Бариста». Если нет релевантного опыта, не пишите. Занимались смежной деятельность? Укажите, если хотите показать, что навыки будут полезны на текущем месте. 1 резюме = 1 специализация.
🌕 2. Место работы. Если мы рассматриваем удаленную работу, указать город - Москва. Зачем? Работодатели из Москвы будут рассматривать вас в первую очередь и ставка по оплате будет выше. На удаленной работе в офис ехать не нужно, а зарплату больше получить реально.
🌕 3. Личные качества. Вы должны показать себя не только как специалист, но и как человек, с которым комфортно работать. Приветствуется: открытость, энтузиазм в работе, желание расти и развиваться в своей специальности, покорять вершины. Если что-то нашли в себе, укажите это в резюме обязательно.
🌕 5. Сопроводительно письмо. Если понравилась вакансия, всегда пишите сопроводительное письмо. Это будет означать вашу заинтересованность, что заставит работодателя открыть ваше резюме среди сотен других и ознакомиться.
🌕 6. Опыт. Что делать, если нет опыта? Учитесь. Постройте план развития и учитесь. С планом развития могут помочь менторы, если не найдете обучающих программ, которые вам понравятся. И повторюсь - всё, что вы узнали, чему научились, — указывайте в резюме. Работодатель увидит ваш энтузиазм и с большим шансом обратит на это внимание.
100+ ВОПРОСОВ…⁉️
📝В этой статье представлен расширенный список вопросов (и ответов), которые потенциальный работодатель может задавать тестировщикам программного обеспечения.
http://getbug.ru/101-voprosov-po-avtomatizatsii-i-testirovaniyu-vruchnuyu/
📝В этой статье представлен расширенный список вопросов (и ответов), которые потенциальный работодатель может задавать тестировщикам программного обеспечения.
http://getbug.ru/101-voprosov-po-avtomatizatsii-i-testirovaniyu-vruchnuyu/
Как мы поднимаем dev-стэнд(ы) и гоняем полноценные тесты api на каждый коммит
https://habr.com/ru/articles/753444/
https://habr.com/ru/articles/753444/
Хабр
Как мы поднимаем dev-стэнд(ы) и гоняем полноценные тесты api на каждый коммит
Мы в API отказались от большого количества unit -тестов в пользу большого количества интеграционных/системных тестов, чтобы: не писать тесты на каждую небольшую функцию системы (которые могут...
Жизненный цикл разработки ПО (SDLC - Software Development Lifecycle)
Жизненный цикл программного обеспечения (software lifecycle): Период времени, начинающийся с момента появления концепции программного обеспечения и заканчивающийся тогда, когда дальнейшее использование программного обеспечения невозможно. Жизненный цикл программного обеспечения обычно включает в себя следующие этапы: концепт, описание требований, дизайн, реализация, тестирование, инсталляция и наладка, эксплуатация и поддержка и, иногда, этап вывода из эксплуатации. Данные фазы могут накладываться друг на друга или проводиться итерационно. (ISTQB)
Период времени от концепции до первоначальной версии известен как жизненный цикл разработки, который является частью жизненного цикла программного обеспечения. С момента первого запуска система переходит в эксплуатацию (функционирование). Система остается в эксплуатации до момента прекращения использования. (ГОСТ 56920)
SDLC - это систематизированный процесс, этапы которого охватывают полный жизненный цикл программного обеспечения (Software Lifecycle) и который определяет различные этапы разработки программного обеспечения для создания высококачественного программного обеспечения, отвечающего ожиданиям клиентов и для улучшения эффективности разработки. Разработка системы должна быть завершена в заранее определенные сроки и стоимость. Каждая фаза жизненного цикла SDLC имеет свой собственный процесс и результаты, которые используются в следующей фазе.
Обычно он делится на шесть-восемь шагов, но менеджеры проектов могут объединять, декомпозировать или пропускать шаги, в зависимости от скоупа проекта.
В разных источниках фазы немного отличаются, но глобально суть везде одинакова.
Фазы SDLC:
Сбор и анализ требований (Requirement Gathering and Analysis):
— На этом этапе от клиента собирается вся необходимая информация для разработки продукта в соответствии с их ожиданиями. Любые неясности должны быть разрешены сразу на этом этапе. Бизнес-аналитик и менеджер проекта назначили встречу с заказчиком, чтобы собрать всю информацию, например, что заказчик хочет построить, кто будет конечным пользователем, какова цель продукта. Перед созданием продукта очень важно понимание или знание продукта. Например, клиент хочет иметь приложение, которое включает денежные транзакции. В этом случае требование должно быть четким, например, какие транзакции будут выполняться, как они будут проводиться, в какой валюте они будут проводиться и т. д. После того, как сбор требований завершен, проводится анализ для проверки возможности разработки продукта. После четкого понимания требования создается документ SRS (Спецификация требований к программному обеспечению). Этот документ должен быть полностью понят разработчикам, а также должен быть рассмотрен заказчиком для использования в будущем;
Дизайн (Design):
— На этом этапе требования, собранные в документе SRS, используются в качестве входных данных, и создается архитектура программного обеспечения, которая используется для реализации разработки системы. Создаются два вида дизайн-документов:
Высокоуровневый дизайн (HLD - High-Level Design):
— Краткое описание и название каждого модуля;
— Краткое описание функциональности каждого модуля;
— Отношения интерфейсов и зависимости между модулями;
— Таблицы базы данных, идентифицированные вместе с их ключевыми элементами;
— Полные архитектурные схемы с подробными сведениями о технологиях.
Низкоуровневый дизайн (LLD - Low-Level Design):
— Функциональная логика модулей;
— Таблицы базы данных, которые включают тип и размер;
— Полная детализация интерфейсов;
— Решение всех типов проблем с зависимостями;
— Список сообщений об ошибках;
— Полные входные и выходные значения для каждого модуля.
Жизненный цикл программного обеспечения (software lifecycle): Период времени, начинающийся с момента появления концепции программного обеспечения и заканчивающийся тогда, когда дальнейшее использование программного обеспечения невозможно. Жизненный цикл программного обеспечения обычно включает в себя следующие этапы: концепт, описание требований, дизайн, реализация, тестирование, инсталляция и наладка, эксплуатация и поддержка и, иногда, этап вывода из эксплуатации. Данные фазы могут накладываться друг на друга или проводиться итерационно. (ISTQB)
Период времени от концепции до первоначальной версии известен как жизненный цикл разработки, который является частью жизненного цикла программного обеспечения. С момента первого запуска система переходит в эксплуатацию (функционирование). Система остается в эксплуатации до момента прекращения использования. (ГОСТ 56920)
SDLC - это систематизированный процесс, этапы которого охватывают полный жизненный цикл программного обеспечения (Software Lifecycle) и который определяет различные этапы разработки программного обеспечения для создания высококачественного программного обеспечения, отвечающего ожиданиям клиентов и для улучшения эффективности разработки. Разработка системы должна быть завершена в заранее определенные сроки и стоимость. Каждая фаза жизненного цикла SDLC имеет свой собственный процесс и результаты, которые используются в следующей фазе.
Обычно он делится на шесть-восемь шагов, но менеджеры проектов могут объединять, декомпозировать или пропускать шаги, в зависимости от скоупа проекта.
В разных источниках фазы немного отличаются, но глобально суть везде одинакова.
Фазы SDLC:
Сбор и анализ требований (Requirement Gathering and Analysis):
— На этом этапе от клиента собирается вся необходимая информация для разработки продукта в соответствии с их ожиданиями. Любые неясности должны быть разрешены сразу на этом этапе. Бизнес-аналитик и менеджер проекта назначили встречу с заказчиком, чтобы собрать всю информацию, например, что заказчик хочет построить, кто будет конечным пользователем, какова цель продукта. Перед созданием продукта очень важно понимание или знание продукта. Например, клиент хочет иметь приложение, которое включает денежные транзакции. В этом случае требование должно быть четким, например, какие транзакции будут выполняться, как они будут проводиться, в какой валюте они будут проводиться и т. д. После того, как сбор требований завершен, проводится анализ для проверки возможности разработки продукта. После четкого понимания требования создается документ SRS (Спецификация требований к программному обеспечению). Этот документ должен быть полностью понят разработчикам, а также должен быть рассмотрен заказчиком для использования в будущем;
Дизайн (Design):
— На этом этапе требования, собранные в документе SRS, используются в качестве входных данных, и создается архитектура программного обеспечения, которая используется для реализации разработки системы. Создаются два вида дизайн-документов:
Высокоуровневый дизайн (HLD - High-Level Design):
— Краткое описание и название каждого модуля;
— Краткое описание функциональности каждого модуля;
— Отношения интерфейсов и зависимости между модулями;
— Таблицы базы данных, идентифицированные вместе с их ключевыми элементами;
— Полные архитектурные схемы с подробными сведениями о технологиях.
Низкоуровневый дизайн (LLD - Low-Level Design):
— Функциональная логика модулей;
— Таблицы базы данных, которые включают тип и размер;
— Полная детализация интерфейсов;
— Решение всех типов проблем с зависимостями;
— Список сообщений об ошибках;
— Полные входные и выходные значения для каждого модуля.
Разработка (Implementation or Coding):
— Реализация / кодирование начинается, как только разработчик получает Design document. Дизайн программного обеспечения переведен в исходный код. На этом этапе реализуются все компоненты программного обеспечения;
Тестирование (Testing): Тестирование начинается после завершения кодирования и выпуска модулей для тестирования. На этом этапе разработанное программное обеспечение тщательно тестируется, и все обнаруженные дефекты передаются разработчикам для их исправления. Повторное тестирование, регрессионное тестирование проводится до тех пор, пока программное обеспечение не будет соответствовать ожиданиям клиента. Тестировщики обращаются к документу SRS, чтобы убедиться, что программное обеспечение соответствует стандарту заказчика;
Развертывание (Deployment):
— После тестирования продукта он развертывается в производственной среде или выполняется первое UAT (пользовательское приемочное тестирование), в зависимости от ожиданий клиента. В случае UAT создается копия производственной среды, и заказчик вместе с разработчиками выполняет тестирование. Если клиент остается доволен, то предоставляет согласие на релиз;
Поддержка (Maintenance):
— Основное внимание на этом этапе SDLC уделяется обеспечению того, чтобы потребности продолжали удовлетворяться и чтобы система продолжала работать в соответствии со спецификацией, упомянутой в первом этапе. После того, как система развернута и клиенты начинают использовать разработанную систему следует 3 вида активностей:
— Исправление ошибок;
— Обновление;
— Улучшение.
— Реализация / кодирование начинается, как только разработчик получает Design document. Дизайн программного обеспечения переведен в исходный код. На этом этапе реализуются все компоненты программного обеспечения;
Тестирование (Testing): Тестирование начинается после завершения кодирования и выпуска модулей для тестирования. На этом этапе разработанное программное обеспечение тщательно тестируется, и все обнаруженные дефекты передаются разработчикам для их исправления. Повторное тестирование, регрессионное тестирование проводится до тех пор, пока программное обеспечение не будет соответствовать ожиданиям клиента. Тестировщики обращаются к документу SRS, чтобы убедиться, что программное обеспечение соответствует стандарту заказчика;
Развертывание (Deployment):
— После тестирования продукта он развертывается в производственной среде или выполняется первое UAT (пользовательское приемочное тестирование), в зависимости от ожиданий клиента. В случае UAT создается копия производственной среды, и заказчик вместе с разработчиками выполняет тестирование. Если клиент остается доволен, то предоставляет согласие на релиз;
Поддержка (Maintenance):
— Основное внимание на этом этапе SDLC уделяется обеспечению того, чтобы потребности продолжали удовлетворяться и чтобы система продолжала работать в соответствии со спецификацией, упомянутой в первом этапе. После того, как система развернута и клиенты начинают использовать разработанную систему следует 3 вида активностей:
— Исправление ошибок;
— Обновление;
— Улучшение.
Тестирование базы данных состоит из тестирования по стратегии чёрного ящика, тестирования белого ящика и ACID (атомарность, согласованность, изолированность и надежность).
Тестирование базы данных проверяет схему базы данных, таблицы и триггеры. Это создает нагрузку на БД и может включать в себя выполнение сложных запросов для тщательной проверки ее возможностей и быстродействия.
Тестирование базы данных важно, потому что:
🔹 Некоторые ошибки можно обнаружить только при тестировании БД
🔹 Определенные условия использования могут быть протестированы только в БД
🔹 Повышает стабильность и безопасность
🔹 Обеспечивает согласованность
Подробный гайд
Тестирование базы данных проверяет схему базы данных, таблицы и триггеры. Это создает нагрузку на БД и может включать в себя выполнение сложных запросов для тщательной проверки ее возможностей и быстродействия.
Тестирование базы данных важно, потому что:
🔹 Некоторые ошибки можно обнаружить только при тестировании БД
🔹 Определенные условия использования могут быть протестированы только в БД
🔹 Повышает стабильность и безопасность
🔹 Обеспечивает согласованность
Подробный гайд
The CTO Club
A QA's Guide To Database Testing In 2024
Maximize your database testing with this guide from a QA expert. Learn how to ensure database reliability and prevent costly downtime
Большой учебник по тестированию — читать
🔹Основы тестирования
🔹Типы тестирования
🔹Тестирование производительности
🔹Тестовая документация
🔹Тест-кейсы
🔹Техники тест-дизайна
🔹Все о багах
🔹Автоматизация
🔹Тестирование мобильных приложений
🔹Инструменты тестировщика
🔹Собеседование
🔹Дополнительные материалы
🔹Тесты для самопроверки
🔹Книги
🔹Основы тестирования
🔹Типы тестирования
🔹Тестирование производительности
🔹Тестовая документация
🔹Тест-кейсы
🔹Техники тест-дизайна
🔹Все о багах
🔹Автоматизация
🔹Тестирование мобильных приложений
🔹Инструменты тестировщика
🔹Собеседование
🔹Дополнительные материалы
🔹Тесты для самопроверки
🔹Книги
📗 Ошибка, дефект, сбой, отказы - различия
Ошибка (error , mistake) — действие человека, приводящее к некорректным результатам.
Дефект (defect, bug, problem, fault) — недостаток в компоненте или системе, способный привести к ситуации сбоя или отказа.
Дефекты могут быть в документации, настройках, входных данных и т.д.
Сбой — самоустраняющийся отказ или однократный отказ, устраняемый незначительным вмешательством оператора.
Отказ — событие, заключающееся в нарушении работоспособного состояния объекта.
Сбои и отказы являются тем, что тестировщик замечает в процессе тестирования и отталкиваясь от чего, проводит исследование с целью выявить дефект и его причины.
📗Верификация и валидация - различия
Верификация — проверка соответствия приложения прописанным требованиям.
Валидация — проверка соответствия приложения всем остальным (подразумеваемым) требованиям.
При валидации тестируется полная работоспособность отмеченной функциональности.
При верификации проверяется наличие в продукте этой логики (параметров взаимодействия компонентов).
Простой способ запомнить разницу между валидацией и верификацией заключается в том, что валидация подтверждает, что «вы создали правильный продукт», а верификация подтверждает, что «вы создали продукт таким, каким и намеревались его сделать».
📗Жизненный цикл тестирования (STLC)
Жизненный цикл тестирования — это последовательность действий, проводимых в процессе тестирования, с помощью которых гарантируется качество программного обеспечения и его соответствие требованиям. STLC включает действия по верификации и валидации.
ЭТАПЫ ЖИЗНЕННОГО ЦИКЛА ТЕСТИРОВАНИЯ:
🟢 Планирование и анализ требований. Важно хотя бы найти ответы на такие вопросы, как: что нужно тестировать, какой объем работы ожидается, какие трудности возникнут во время работы и т.д.
🟢 Критерии ввода. Вы формулируете или указываете критерии ввода (чтобы определить, когда можно или необходимо начинать процесс тестирования ПО), критерий приостановки, и критерий прекращения тестирования.
🟢 Стратегия тестирования. Старший QA-менеджер определяет затраты и усилия на работу над проектом и готовит тест-план для всех видов тестирования.
🟢 Разработка тест-кейсов. Тест-кейсы создаются, разрабатываются, проверяются и перерабатываются. Также, этот этап включает в себя создание, пересмотр и переработку тестовых данных.
🟢 Установка среды. Выполняется одновременно с этапом разработки тест-кейсов. Она определяет аппаратные и программные условия, при которых тестируется продукт.
🟢 Выполнение тестов.
🟢 Завершение цикла тестирования.
Ошибка (error , mistake) — действие человека, приводящее к некорректным результатам.
Дефект (defect, bug, problem, fault) — недостаток в компоненте или системе, способный привести к ситуации сбоя или отказа.
Дефекты могут быть в документации, настройках, входных данных и т.д.
Сбой — самоустраняющийся отказ или однократный отказ, устраняемый незначительным вмешательством оператора.
Отказ — событие, заключающееся в нарушении работоспособного состояния объекта.
Сбои и отказы являются тем, что тестировщик замечает в процессе тестирования и отталкиваясь от чего, проводит исследование с целью выявить дефект и его причины.
📗Верификация и валидация - различия
Верификация — проверка соответствия приложения прописанным требованиям.
Валидация — проверка соответствия приложения всем остальным (подразумеваемым) требованиям.
При валидации тестируется полная работоспособность отмеченной функциональности.
При верификации проверяется наличие в продукте этой логики (параметров взаимодействия компонентов).
Простой способ запомнить разницу между валидацией и верификацией заключается в том, что валидация подтверждает, что «вы создали правильный продукт», а верификация подтверждает, что «вы создали продукт таким, каким и намеревались его сделать».
📗Жизненный цикл тестирования (STLC)
Жизненный цикл тестирования — это последовательность действий, проводимых в процессе тестирования, с помощью которых гарантируется качество программного обеспечения и его соответствие требованиям. STLC включает действия по верификации и валидации.
ЭТАПЫ ЖИЗНЕННОГО ЦИКЛА ТЕСТИРОВАНИЯ:
🟢 Планирование и анализ требований. Важно хотя бы найти ответы на такие вопросы, как: что нужно тестировать, какой объем работы ожидается, какие трудности возникнут во время работы и т.д.
🟢 Критерии ввода. Вы формулируете или указываете критерии ввода (чтобы определить, когда можно или необходимо начинать процесс тестирования ПО), критерий приостановки, и критерий прекращения тестирования.
🟢 Стратегия тестирования. Старший QA-менеджер определяет затраты и усилия на работу над проектом и готовит тест-план для всех видов тестирования.
🟢 Разработка тест-кейсов. Тест-кейсы создаются, разрабатываются, проверяются и перерабатываются. Также, этот этап включает в себя создание, пересмотр и переработку тестовых данных.
🟢 Установка среды. Выполняется одновременно с этапом разработки тест-кейсов. Она определяет аппаратные и программные условия, при которых тестируется продукт.
🟢 Выполнение тестов.
🟢 Завершение цикла тестирования.
Тут 8 айтишников с суммарным опытом в 130 лет выложили учебник по тестированию. Он огромный и самое главное — бесплатный.
Там больше 700 страниц, есть тесты, а сам учебник на русском.
Там больше 700 страниц, есть тесты, а сам учебник на русском.
Хабр
Полный релиз бесплатного интерактивного 700-страничного учебника по тестированию
Гуд ньюз эвриван! Спустя полтора года работы восьми айтишников с суммарным опытом в IT 130 лет достигнут результат в виде учебника по тестированию, которого еще никто и никогда не делал. 700+ страниц...