Цели тестирования ПО
March 26th, 2008 by Ira SribnaНаверно, каждый начинающий тестировщик задается вопросом: «Какие же цели преследует тестирование?» Таких целей две.
- Первая: выявить случаи, когда приложение не делает, то что от него ожидается,
- ну и вторая: выявить случаи, когда тестируемое ПО делает то, чего делать не должно – побочные эффекты.
Таким образом, тестировщик ни в коем случае в процессе своей работы не «доказывает», что приложение работает должным образом, подбирая для этого тестовые данные, демонстрирующие правильную работу приложения, а пытается обнаружить ошибки в работе тестируемого приложения, - ведь как известно идеально работающих программ, не содержащих багов не существует.
Возможно, поэтому тестировщики и программисты являются извечными антагонистами: программисты выступают в роли «создателей», а тестировщики в роли «разрушителей». А кто же любит, когда его «детище» не только критикуют, но и подвергают всевозможным проверкам и испытаниям. Именно поэтому нельзя давать разработчику тестировать свое собственное творение, ведь каждый программист в душе считает, что оно может и не идеально, но весьма близко к совершенству 
.
Но все же, не смотря на это, и разработчиков и тестировщиков, как одну целую команду, объединяет общая цель – выпустить качественный продукт, соответствующий выдвинутым к нему требованиям и в намеченные сроки.
А что делать если ошибок не удалось обнаружить?
Ошибки есть всегда, как бы идеально на первый взгляд не был написан код и функционал не соответствовал спецификации. Даже после хорошего тестирования они останутся.
Ну, насчет “всегда” — это не совсем так.
И встроенной бесконечностью не обладает.
Программа ведь штука дискретная
Правда, ошибки тогда уже не в программе, а в чем-то другом.
Значит плохо искал
Подход к тестированию, описанный вами был популярен лет так 10 назад, и к сожалению продолжает применяться в компаниях, где у менеджмента напрочь отсутствуют знания по процессам, QA и QA-процессам в том числе.
Не должен тестировщик искать ошибки или побочные эфекты - он должен удостовериться что продкт работает так, как описано в документации и/или use-case карточках, а также зафиксировать и задокументировать эти результаты.
Ошибки, побочые эфекты, краши и тд - это все вторично.
Т.е по Вашему мнению, человек в процессе удостоверения работы продукта не сталкивается с ошибками и побочными эффектами в работе приложения? К тому же разве не могут присутствовать ошибки в самой документации?
Начнем хотя бы с того, что я подобного не утверждал.
Мой комментарий относился именно к
Именно на этот вопрос и пытаются ответить при внедрении всяких CMM/CMMI, ISO и тд
т.е на sql инъекции сайт можно не проверять, если про них ничего в спецификации нет?
Да, очень интересно, что на это ответит Vadim!
Само собой.
Есть такая штука — уровень качества.
Если что-то не описано в документации (явно или неявно) — то его может в программе и не быть.
Приведу простую аналогию.
Вы строите дом.
Нужно ли проверять его на сейсмоустойчивость, если он находится под Харьковом? А ведь можно было бы
Или — вы устраиваетесь на работу в IT-контору.
Нужно ли вас “на всякий случай” проверить на знание того, что не описано в требованиях по приему на работу?
Должен согласится с Vadim. Концентрация усилий исключительно на поиске ошибок довольно старая и не всегда успешная практика. В конце концов мы ведь хотим выпустить продукт который будет удовлетворять нужды пользователей/заказчиков… И толку от этого продукта если в нем не будет ни одной ошибки, но и полезная функциональность отсутствует или работает не так как надо?
На практике стоит совмещать оба подхода, но ЦЕЛЬ тестирования имхо доказать что продукт делает то что должен и не делает того что не должен.
Может тестировать и нельзя давать, но следить за качеством разработчик обязан. А то некоторые считают, что сейчас нужно написать как-нибудь, а потом тестеры найдут баги…
Я в большей степени согласен с этим: в частности, за такими вещами как sql-injection должен следить программист. И даже не то, что следить, а не допускать этого. Ведь это в конце концов непосредственный показатель его квалификации.
Но все-таки, что тестировщик, что программист работают над достижением одной цели и поэтому должны компенсировать недостатки в работе друг друга.
Ну да совершено верно )) тоесть быть в идеале друг с другом
А в моем коде ошибок нет…
все разработчики так думают, пока тестирование не начнется
Роботы среди нас
Йа робот
1. Выявление ошибок.
2. Проверка соответствия разраб. ПО к ТЗ.
3. Проверка нагрузоустойчивости.
:)
3 - есть частный случай второго.
То есть в техзадании должно быть явно описано, какую нагрузку должен выдерживать продукт.
Иначе потом возникают непреодолимые сложности. Нагрузка ведь может быть любая…
Тестер (точнее, QA) должен обеспечивать качество продукта в первую очередь, а не искать ошибки.
Поэтому ключевым словом тут является качество. Которое должно оговариваться в той же степени, в которой и функциональность.
К вопросу об SQL-инъекциях и прочей радости: если это не написано в требованиях, то тестировать не обязательно.
Потому что если баг найден, то его нужно починить, а на починку бага никто бюджет не выделит. Точнее, этот баг (sql-инъекция) отберет время, за которое можно было найти баг в функциональности, которая явно описана.
Любые комментарии заказчиков на тему “ну так это и без спеки понятно” можно отправлять лесом. Потому что “вы должны нам еще $100 за тестирование, а то что мы это в бюджет не включили — так вы тоже должны понимать, не маленькие”.
Ашманов об этом говорил, кстати — для каждого продукта должен быть критерий, по которому его можно считать завершенным.
Для большинства проектов таким критерием является соответствие заявленной функциональности (описанной в техдокументации) и реализованной.
Другой случай, конечно, Agile-методики. Потому как готовой спецификации нет и быть не может (она такая же гибкая).
И тут критерием окончания проекта является просто достаточность для заказчика.
Правда, там и бюджеты по-другому считаются (т.е. можно сказать, что каждая итерация — это отдельный проект).
Но даже в agile-программировании есть какой-то уровень качества, потому что иначе проект будет только тестироваться и исправляться.