Software Test

Михаил Портнов. Директор Portnov Computer School.

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

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

Перейдем к важным деталям.

Что мы знаем о желаемом поведении продукта? Откуда мы это знаем? Что-то мы прочитали в документации, что-то нам рассказали коллеги, что-то мы на митинге обсуждали, что-то мы видели у конкурирующего продукта. Но это не все. Точнее, есть детали, которые нигде толком не прописаны. Они всегда есть. Но, очень часто у нас нет толком документации, и спросить рядом некого, и похожего продукта нет в руках. Работа в условиях неполной информации - это неотъемлимая часть профессии тестера. Итак, знаний в готовом виде почерпнуть негде. Значит мы должны их добыть самостоятельно, в частности, работая с тестируемым продуктом. В каджый конретный момент времени мы что-то знаем наверняка, что-то знаем с некоторой долей сомнения, что-то не знаем совсем. Наше знание о необходимом поведении продукта постоянно углубляется, начиная с первого дня работы на проекте, и кончая днем его сдачи "в тираж". Если я потратил год жизни и ушел на другую работу, то другой человек с равноценным ителлектом, образованием и опытом работы тоже потратит год, чтобы заново разобраться в том же самом. За чей счет? Что будет с качеством продукта в течение этого года? Ответ ясен без особых комментариев. Итак, первая жизненно важная функция тест кейсов - документирование нашего знания о желаемом поведении продукта. Тест кейс - это ведь не только что мы хотим сделать руками. Это и что мы ожидаем, и как мы конкретно удостоверимся в получении правильного результата.

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

Тест кейсы совершенно незаменимы там, где пишутся автоматизированные тесты. Как бы хорошо Вы ни знали Силк или ВинРаннер, надо знать что с этим тулом делать в конкретной ситуации. Автоматизация тестирования без наличия добротных тест кейсов превращается в профанацию и только дискредитирует идею автоматического тестирования как таковую. Время ушло, деньги потрачены, а результата автоматизации нет. А откуда же им взяться, если никто не знал что автоматизировать и зачем? Помните анекдот о поручике Ржевском, игравшем на рояле? Ему говорят - это Вы так прекрасно сейчас играли Баха? А он отвечает - Да что Вы, это я так, фигачу по клавишам что на ум взбредет. Автоматизируя тестирование без тест кейсов, человек уподобляется нашему героическому поручику. А кому уподобляется менеджер, позволяющий ему это делать?

Но самое главное я припас напоследок. Хочет ли тестер найти как можно больше ошибок в продукте? Странный вопрос - он спит и видит это. Какой есть самый эффективный способ найти много багов? Оказывается, надо всего-то навсего писать и выполнять формальные тест кейсы. Слово ФОРМАЛЬНЫЕ здесь является ключевым. Не по здравому смыслу, а по науке. Вот, для примера возьмем Notepad. Есть ли на свете софтверный продукт, которым бы пользовалось больше людей? Очень сомнительно. Во всяком случае миллионы, десятки миллионов людей с ним сталкиваются ежедневно. А, вот, он-то как раз и не тестировался по науке. Почему? Вопрос не ко мне. Но подтверждений этому масса. Давайте откроем новое окошко и набьем туда 33 килобайта текста. Напечатайте символов полста, select, copy, а потом нажмите и держите CTRL+V пока строчку не заполните. Когда будет полная строка сделайте с ней то же самое и все окошко забьеься тектсом до упора за пару секунд. Выскакивает окошечко с таким текстом "Not enough memory available to complete this operation …..". Думаете памяти не хватило? Нет, просто подают нам неадекватное сообщение. Почему такое произошло? А потому, что всякий Edit Box надо тестировать на граничные условия (boundary conditions). А этот не тестировали. И не только этот. Такого рода багов в ноутпэде десятки. А там ведь и функциональности-то с гулькин нос - ввод текста и поиск.

Так что, господа, пишите тест кейсы, выполняйте их и все баги - ваши.