Ron Patton дает следующее опеределение загадочному слову software bug:
Не зная, куда податься, они пытаются по крайней мере убедиться в том, что конечный продукт соответствует спецификации.
Что не плохо, но!
Очень важным является именно 4 пункт. Фактически этот пункт означает ошибку в ТЗ. А, как все мы знаем, ТЗ тоже надо тестировать. На полноту, корректность, осуществимость, необходимость, проверяемость и недвусмысленность.
Что будет, если мы этого не сделаем? А будет то, что пользователь, пройдя по своему сценарию использования, будет возмущаться поведением продукта. Потому что оно "само собой подразумевалось". Ну, это хороший вариант развития событий. Бывают еще и другие, когда, например, из-за тяжелой реализуемости съезжают сроки. Или из-за сложной же проверяемости...
Но пользователю то важна двусмысленность! А точнее, ее отсутствие. И еще желательно, чтобы его мысли прочитали и реализовали даже то, чего не было в ТЗ :) Но должно было быть!
Поэтому - не забываем о том, что мы здесь собрались не только для того, чтобы сверить то, что есть, с тем, как это описали. Не забываем про 4 и 5 (!) пункты.
В пятом пункте говорится о том, что после нас - все. Обратного пути нет. Дальше с приложением будут работать уже реальные пользователи. И мы - та последняя инстанция, которая должна взглянуть на продукт не только с точки зрения "оно работает, как написано", но и с точки зрения того, кто в итоге будет с ним работать.
Может быть, приложение работает слишком медленно? Или тяжело понять, что есть что? Например, где кнопка входа в личный кабинет, где отменить эту надоевшую спам-расслыку итд итп. Посмотрите на продукт глазами того, кто будет использовать его по назначению, не сверяясь с ТЗ, а просто выполняя какую-то свою задачу, которую данное приложение должно, по идее, облегчить.
Просто помните о том, что тестирование - не поиск ошибок! :)
- The software doesn`t do something that the product specification says it should do.
- The software does something that the product specification says it shouldn`t do.
- The software does something that the product specification doesn`t mention.
- The software doesn`t do something that the product specification doesn`t mention but should.
- The software is difficult to understand, hard to use, slow, or - in the software tester`s eyes - will be viewed by the end user as just plain not right.
- Продукт не делает что-то, что, согласно спецификации (далее - ТЗ), должен делать.
- Продукт делает что-то, что, согласно ТЗ, делать не должен.
- Продукт делает что-то, что в ТЗ не указано.
- Продукт не делает что-то, что в ТЗ не указано, хотя должно.
- Продукт очень сложный для понимания, трудный в использовании, медленный, или - глазами тестировщика, который смотрит на продукт как конечный пользователь, делает что-то... просто не правильно!
Не зная, куда податься, они пытаются по крайней мере убедиться в том, что конечный продукт соответствует спецификации.
Что не плохо, но!
Очень важным является именно 4 пункт. Фактически этот пункт означает ошибку в ТЗ. А, как все мы знаем, ТЗ тоже надо тестировать. На полноту, корректность, осуществимость, необходимость, проверяемость и недвусмысленность.
Что будет, если мы этого не сделаем? А будет то, что пользователь, пройдя по своему сценарию использования, будет возмущаться поведением продукта. Потому что оно "само собой подразумевалось". Ну, это хороший вариант развития событий. Бывают еще и другие, когда, например, из-за тяжелой реализуемости съезжают сроки. Или из-за сложной же проверяемости...
Но пользователю то важна двусмысленность! А точнее, ее отсутствие. И еще желательно, чтобы его мысли прочитали и реализовали даже то, чего не было в ТЗ :) Но должно было быть!
Поэтому - не забываем о том, что мы здесь собрались не только для того, чтобы сверить то, что есть, с тем, как это описали. Не забываем про 4 и 5 (!) пункты.
В пятом пункте говорится о том, что после нас - все. Обратного пути нет. Дальше с приложением будут работать уже реальные пользователи. И мы - та последняя инстанция, которая должна взглянуть на продукт не только с точки зрения "оно работает, как написано", но и с точки зрения того, кто в итоге будет с ним работать.
Может быть, приложение работает слишком медленно? Или тяжело понять, что есть что? Например, где кнопка входа в личный кабинет, где отменить эту надоевшую спам-расслыку итд итп. Посмотрите на продукт глазами того, кто будет использовать его по назначению, не сверяясь с ТЗ, а просто выполняя какую-то свою задачу, которую данное приложение должно, по идее, облегчить.
Просто помните о том, что тестирование - не поиск ошибок! :)





