На Главную

Цели тестирования ПО

March 26th, 2008 by Ira Sribna

Наверно, каждый начинающий тестировщик задается вопросом: «Какие же цели преследует тестирование?» Таких целей две.

  • Первая: выявить случаи, когда приложение не делает, то что от него ожидается,
  • ну и вторая: выявить случаи, когда тестируемое ПО делает то, чего делать не должно – побочные эффекты.

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

Возможно, поэтому тестировщики и программисты являются извечными антагонистами: программисты выступают в роли «создателей», а тестировщики в роли «разрушителей». А кто же любит, когда его «детище» не только критикуют, но и подвергают всевозможным проверкам и испытаниям. Именно поэтому нельзя давать разработчику тестировать свое собственное творение, ведь каждый программист в душе считает, что оно может и не идеально, но весьма близко к совершенству :-) .

Но все же, не смотря на это, и разработчиков и тестировщиков, как одну целую команду, объединяет общая цель – выпустить качественный продукт, соответствующий выдвинутым к нему требованиям и в намеченные сроки.

Автор: Ira Sribna

Похожие статьи:

RSS комментариев | Trackback URI

20 Комментариев

Comment by Shelest
2008-03-26 11:36:54

А что делать если ошибок не удалось обнаружить?

Comment by milax Subscribed to comments via email
2008-03-27 10:42:42

Ошибки есть всегда, как бы идеально на первый взгляд не был написан код и функционал не соответствовал спецификации. Даже после хорошего тестирования они останутся.

Comment by Scratch Subscribed to comments via email
2008-04-11 01:44:46

Ну, насчет “всегда” — это не совсем так.
Программа ведь штука дискретная :) И встроенной бесконечностью не обладает.

Правда, ошибки тогда уже не в программе, а в чем-то другом.

 
 
 
Comment by Ira Sribna Subscribed to comments via email
2008-03-26 11:42:59

Значит плохо искал :-)

 
Comment by Vadim
2008-03-26 14:19:40

Подход к тестированию, описанный вами был популярен лет так 10 назад, и к сожалению продолжает применяться в компаниях, где у менеджмента напрочь отсутствуют знания по процессам, QA и QA-процессам в том числе.

Не должен тестировщик искать ошибки или побочные эфекты - он должен удостовериться что продкт работает так, как описано в документации и/или use-case карточках, а также зафиксировать и задокументировать эти результаты.
Ошибки, побочые эфекты, краши и тд - это все вторично.

Comment by Ira Sribna
2008-03-26 14:38:27

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

Comment by Vadim
2008-03-26 14:56:58

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

задается вопросом: «Какие же цели преследует тестирование?»

Именно на этот вопрос и пытаются ответить при внедрении всяких CMM/CMMI, ISO и тд

 
 
Comment by Yuriy Drozdov Subscribed to comments via email
2008-03-26 16:11:05

Не должен тестировщик искать ошибки или побочные эфекты - он должен удостовериться что продкт работает так, как описано в документации и/или use-case карточках

т.е на sql инъекции сайт можно не проверять, если про них ничего в спецификации нет?

Comment by ad hoc Subscribed to comments via email
2008-03-28 10:28:38

Да, очень интересно, что на это ответит Vadim!

 
Comment by Scratch Subscribed to comments via email
2008-04-11 01:48:07

Само собой.
Есть такая штука — уровень качества.
Если что-то не описано в документации (явно или неявно) — то его может в программе и не быть.

Приведу простую аналогию.
Вы строите дом.
Нужно ли проверять его на сейсмоустойчивость, если он находится под Харьковом? А ведь можно было бы :)

Или — вы устраиваетесь на работу в IT-контору.
Нужно ли вас “на всякий случай” проверить на знание того, что не описано в требованиях по приему на работу? :)

 
 
 
Comment by dstany Subscribed to comments via email
2008-03-27 11:07:53

Должен согласится с Vadim. Концентрация усилий исключительно на поиске ошибок довольно старая и не всегда успешная практика. В конце концов мы ведь хотим выпустить продукт который будет удовлетворять нужды пользователей/заказчиков… И толку от этого продукта если в нем не будет ни одной ошибки, но и полезная функциональность отсутствует или работает не так как надо? ;) На практике стоит совмещать оба подхода, но ЦЕЛЬ тестирования имхо доказать что продукт делает то что должен и не делает того что не должен.

 
Comment by ad hoc Subscribed to comments via email
2008-03-28 10:54:05

Именно поэтому нельзя давать разработчику тестировать свое собственное творение, ведь каждый программист в душе считает, что оно может и не идеально, но весьма близко к совершенству

Может тестировать и нельзя давать, но следить за качеством разработчик обязан. А то некоторые считают, что сейчас нужно написать как-нибудь, а потом тестеры найдут баги…

Не должен тестировщик искать ошибки или побочные эфекты - он должен удостовериться что продкт работает так, как описано в документации и/или use-case карточках, а также зафиксировать и задокументировать эти результаты.
Ошибки, побочые эфекты, краши и тд - это все вторично.

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

 
2008-03-30 20:41:08

Ну да совершено верно )) тоесть быть в идеале друг с другом

 
Comment by redline Subscribed to comments via email
2008-04-02 02:54:02

А в моем коде ошибок нет…

Comment by Ira Sribna Subscribed to comments via email
2008-04-02 12:41:38

все разработчики так думают, пока тестирование не начнется :-)

 
Comment by Yuriy Drozdov Subscribed to comments via email
2008-04-02 12:42:02

Роботы среди нас :)

Comment by redline Subscribed to comments via email
2008-04-02 16:53:13

Йа робот :)

 
 
 
Comment by Vadik Subscribed to comments via email
2008-04-07 16:09:59

1. Выявление ошибок.
2. Проверка соответствия разраб. ПО к ТЗ.
3. Проверка нагрузоустойчивости.

:)

Comment by Scratch Subscribed to comments via email
2008-04-11 01:53:14

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

Иначе потом возникают непреодолимые сложности. Нагрузка ведь может быть любая…

 
 
Comment by Scratch Subscribed to comments via email
2008-04-11 02:02:48

Тестер (точнее, QA) должен обеспечивать качество продукта в первую очередь, а не искать ошибки.

Поэтому ключевым словом тут является качество. Которое должно оговариваться в той же степени, в которой и функциональность.

К вопросу об SQL-инъекциях и прочей радости: если это не написано в требованиях, то тестировать не обязательно.
Потому что если баг найден, то его нужно починить, а на починку бага никто бюджет не выделит. Точнее, этот баг (sql-инъекция) отберет время, за которое можно было найти баг в функциональности, которая явно описана.

Любые комментарии заказчиков на тему “ну так это и без спеки понятно” можно отправлять лесом. Потому что “вы должны нам еще $100 за тестирование, а то что мы это в бюджет не включили — так вы тоже должны понимать, не маленькие”.

Ашманов об этом говорил, кстати — для каждого продукта должен быть критерий, по которому его можно считать завершенным.
Для большинства проектов таким критерием является соответствие заявленной функциональности (описанной в техдокументации) и реализованной.

Другой случай, конечно, Agile-методики. Потому как готовой спецификации нет и быть не может (она такая же гибкая).
И тут критерием окончания проекта является просто достаточность для заказчика.
Правда, там и бюджеты по-другому считаются (т.е. можно сказать, что каждая итерация — это отдельный проект).
Но даже в agile-программировании есть какой-то уровень качества, потому что иначе проект будет только тестироваться и исправляться.

 

Извините, комментарии закрыты.