Дмитрий

Есть поговорка "Встречают по одежке, а провожают по уму".

На собеседовании вам по-любому надо будет показать свои знания. Но ведь надо еще сделать так, чтоб вас на него позвали! Любой сертификат это способ выделиться из массы других подобных специалистов. Не более. Более того качественная сертификация структурирует ваши знания. Возможно поможет посмотреть на себя со стороны. Повысит вашу уверенность в себе, а разве это плохо? Уверенный в себе и своих силах как правило большего добивается

Тесты для кого? Для человека или для машины?
Я к тому, что тесты бывают разными: ручные и автоматические. Про это ничего не сказано в вашем вопросе!

Какие именно тесты нужны? Модульные? Интеграционные? Инсталяции? Нагрузочные? Про это тоже ни слова в вашем вопросе!

Тесты пишут так:
1. Выявляют сначала рабочие сценарии, т.е. когда все хорошо и появляется результат. Есть огромное кол-во ситуаций, когда пользователь готов заплатить забажный продукт, если он хотя 1 раз и 50 запусков сделает ему то, чтобы он делал 3 дня! Сценарии сортируются по:
1.1. компонентам
1.2. приоритету и важности.

После сортировки создают наборы тестов

2. Далее выясняют сценарии, когда что-то не хватает "насяльника сеть упала, что делать?". Другими словами проверить работу позитивных сценариях при возможных негативных случаях, которые быть, но не повине пользователя. Примеры: сеть упала, флешка перстала видеться, в БД вдруг доступ не пускают и др. Особенно смотрят на возможную порчу исходных данных. Был у моего знакомого случая, когда они подбирали пароль к базе данных и случайно затерли пару байтов. ;)

3. Только после этого проверяют "ошибку на дурака". Примеры: вместо текстового файла дали exe-файл. Или вместо числа ввели строку.

Предположу, что вы хотите писать модульные тесты. Скажу следующее что эти типы тестов не должны делать:
1. Проверять работу с БД, диском, сетью
2. Код зависящий от времени

Основной показатель модульного теста это скорость работы. Если тест такого типа работает пол-секунды, то значит вы написали что угодно, но это не модульный тест ;)

Выбирайте любимую OpenSource-программу и тестируйте! Программ в OpenSource оооочень много! Примеры:
* GnuCash, KeePass, etc;
* FreeBSD, Linux, OpenBSD, etc;

Берете и начинаете проверять!

Работая несколько лет тестировщиком вывел для себя правило :

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

Все очень похоже на программирование: пишешь код, даешь названия переменным, методам, классам. Думаешь логично и понятно, а спустя года : Кто все это написал? Что я в тот момент курил? Да, такое бывает! ;) Мы развиваемся, у нас появляется новый опыт. Новые идеи. Видя старые мысли мы можем ужасаться )))

В тестировании мы тоже не сидим на месте. Мы учимся и наши навыки развиваются. Написав только лишь заголовок вы можете оказаться в ситуации, что не сможете понять : А что нужно-то перепроверить то? Замечу, что задачи разнятся по приоритетам и может получиться так, что созданную сейчас задачу вы увидете только лишь через пол-года или год.

Сравните два заголовка:
1. Ошибка в логе при скачивании бэкапа

понятно? Вроде бы да и все логично на первый взгляд. Заголовок принуждает лезть в конкретное место в коде: класс по скачиванию бэкапа.

Но вот возникают вопросы:
1. Какой битности программа?
2. После чего появилась ошибка? Сразу же после начала скачивания или комп ложился спать и после пробуждения?
3. Это только на Windows 10 или еще на Windows 8.1? А как себя ведет на Windows server 2012 ?
4. Эти ошибки в логе? А что если сетевой шнур выдернуть?

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

Есть книга от Мигеля Гринберга про Web-разработку с помощью Flask. Рекомендую прочитать разделы про тестирование. Я сознательно не буду приводить как, т.к. лучше Гринберга врядли кому-либо получится пояснить лучше. Но. Я бы хотел обратить ваше внимание на то, что лучше использовать не Nose, а py.test + pyhamcrest , тогда Ваши тесты будут более выразительными и вы будете лучше видеть "Что б.. сломалось то?"

zephyr?

1. В тестах развилок не может быть! Другими словами Вы всегда должны разбивать тестируемый код на участки. До условия это один участок кода. Ветка кода с if-true(т.е. когда условие true). И ветка кода с if-false(т.е. когда условие ложно). Это три разных тестовых сценария. Вам будет проще для сопровождения.

Тесты должны быть как можно проще!!! Было А, нажали что-то, Должно быть Б. Если не так, то заводим багу!

2. Прежде чем писать тест надо задаться вопросом "А если здесь будет бага, то что это будет значить для бизнеса?" ответ "Клиенты массово будут просить денег обратно" - значит надо писать тест "Клиент купит, но будет недоволен" - нужно думать стоит ли писать тест? Вдруг есть более важные участки кода

Почитайте книгу про жесткое обращение с багами

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

Один тест - одна проблема. Тест должен выявлять СТРОГО одну проблему! Как вывод: не следует делать так, чтобы один тест зависил от другого.

Мне кажется ВЫ не совсем верно понимаете что такое модульный тест. Вот его достаточно верное определение: Unit Test - Definition

Ну вот Вы сами и сформулировали ответ на свой вопрос. Попробую пояснить. Модульный тест, хороший тест, обладает качеством: его просто написать! Даже вопроса не возникнет, о том, а как написать-то? Если же написать сложно, то Вы, возможно, пытаетесь написать тест на код в котором выполняется более чем одна задача!

Сейчас вижу, что у Вас в методе выполнется минимум два не связанных между собою действия:
1. Создание дескриптора
2. Выполнение какого-то действия с применением этого дескриптора

Их надо тестировать по отдельности! Для действия №1 Вы можете написать тесты:
1. Позитивный: это когда 0, 1, 2
2. Негативный: когда меньше нул или больше 2

Для действия №2: Вы тоже можете написать минимум два теста с правильным и не правильным дескриптором

Рекомендую сперва посмотреть Software QA Course от Михаила Портнова. Затем почитать про "жесткое обращение с багами", так и писать в гугле.

Работал и программистом и тестировщиком. Вторая интереснее. И для бизнеса важнее.

Приведу пример:
* Вендор затратил усилия, разработал прошивку, программы, дизайнеры все хорошо придумали и вот Вы находясь в магазине и держите в руках мобильный телефон, который давно ждали и хотели купить. Вдруг Вы понимаете, что хочете поделиться радостью со своей женой\девушкой\другом , пытаетесь сделать звонок а телефон не звонит!

Вопрос: Будет ли для Вас как пользователя хоть что-то значить в плане разработки? Будете ли Вы его покупать зная что он не звонит?

Другими словами: Тестировщик обладает правом наложить веское слово "Продукт в релиз я бы не выдавал". В случае веских аргументов, читай задач с описанием серьезных ошибок Product-Owner его слова примет к сведению.

История ИТ знает как компания Intel меняла процессоры из-за ошибки в расчете вещественных чисел. Это колоссальные убытки для компаний!

Да. Как разработчик я отлично понимаю мысль "чтобы что-то продать надо что-то это сделать", но куда важнее чтобы это "что-то" было надлежащего качества, иначе все усилия в никуда!

Нет, ну правда, какая Вам разница сколько паттернов проектирования, алгоритмов или идиом было применено при разработке, если продукт не работает? Лично я беря мобильный, проверяю его работу по основным функциям и в случае чего беру другую модель, возможно другого вендора!

Так, что тестирование это оочень важно! Да и программирования там тоже не мало, т.к. в ручную все проверять это утопия

1.
Приходят данные, как мне протестить их, может пришло не то!
Для этого надо задать себе вопрос "А какие именно данные будут не теми?" и переписать их на листочке или же запомнить и держать в голове.

2.
>>Создавать доп базу?
Нет! Для класса работающего с базой написать рефакторинг. Сутью рефакторинга перепроектировать на наследование этого класса работающего с БД от некоего интерфейса. Дальше от интерфейса породить несколько классов потомков на каждую ситуацию описанную в п.1. это будут моки, а вернее State-классы.

Этот вид тестирования называется "State-based testing". Основан на том что заранее пишутся классы имеющее вполне заранее определенное и конкретное состояние, как правило захардкоженное(В data driven testing пока не вдавайтесь, ибо увязнете в деталях). Такие классы нужно писать как можно проще !!! Чтобы в будущем удалять код не было так жалко )))

3)
В тест-методах , т.е. в юнит-тестах вызываете production-код,но подставляете не реальную БД, а классы написанные п.2. и проверяете состояние.

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

interface StudentDataBase:
  getName()
  getAge()

// production code
class OracleDataBase implements StudentDataBase
  getName()
  getAge()

// For Testing goal
class BadNameCorectAge implements StudentDataBase
  getName() {
    return 'Wrong-name'
  }
  getAge() {
    return 19;
  }

TEST(WithBadNameForStudent) {
   // [1] Подготовительная часть. Т.е. 'Arrange' из паттерна Arrange-Act-Assert
    BadNameCorectAge database;
    // Здесь с псевдо-базой используется код из production-части, который вы хотите проверить
    TestObject testObj;
    testObj->setDataBase(database);

   // Выполняем действие в production-части и тут же проверяем 
  // [2] Другими словами это совмещенная Act-Assert из паттерна ArrangeAct-Assert
    EXPECT_EXCEPTION(testObj->process(), WrongNameException);
}

Спасибо за Ваш ответ!
п.1 По поводу OnTestPad , я его смотрел в свое время, но увидев в примерах что нету Pass/Fail и отмел сразу же ) К примеру testpad-outline-editor. Имею ввиду зеленый/красный прямо в списке, чтобы можно было сразу же понять какой не пройден без просмотра детализации кейса
п.2 Про Zephyr. У меня нету четкого понимания как им пользоваться! Действительно ли там можно отметить Pass/Fail? Я не увидел важной для меня строчки: Версия плана и возможности ссылки на него.

А чем пользуетесь Вы?

Прошло уже довольно много времени моих поисков. В общем для решения своей задачи стартовал опен-сурс проект code.google.com/p/non-smoker/. Вероятно все же где-то есть подходящее моим требованиям проект, но в виду того что не нашел до сего дня, то не имеет смысла ждать и оставлять на потом те задачи тестирования которые хочу решить уже давно. Обрадуюсь любой критике, предложениям