Sribna

На протяжении долгого и тяжелого пути тестирования, были замечены особенности, присущие данному виду деятельности. Прошу знакомиться:

• Тестирование демонстрирует присутствие дефектов, а не их отсутствие : Тестирование демонстрирует, что у продукта есть недостатки, т.е. в продукте есть дефекты. Тестирование не может доказать, что программа не содержит дефектов. Должное тестирование сокращает вероятность присутствия скрытых дефектов в тестируемом объекте. Даже если проблемы найдены в процессе тестирование, это не доказывает, что дефектов в продукте нет.
• Исчерпывающее тестирование невозможно: Исчерпывающий тест, в котором все возможные входные данные и их комбинации предусмотрены, включая различные предусловия, невозможен. Программное обеспечение, разрабатываемое на практике, требовало бы астрономического числа тест кейсов. Поэтому каждый тест кейс – это всегда лишь образец. Вследствие этого, выполнение тестов  должно быть контролируемо с учетом рисков и приоритетов.
• Работы, связанные с тестированием, должны начинаться как можно раньше: Тестирование должно начинаться на ранних стадиях жизненном цикла программного обеспечения и должно фокусироваться на заданных целях. Это поспособствует более раннему нахождению дефектов.
• Дефекты имеют тенденцию скапливаться группами: Дефекты не распределены равномерно, они имеют свойство «собираться группами». Поэтому, если много дефектов было найдено в одном месте,  обычно еще больше дефектов могут быть обнаружены неподалеку.  Не нужно критично относиться к данному правилу
• “Пестицидный парадокс”: Если те же самые тесты выполняются снова и снова, они теряют свою эффективность. Новые, неизвестные до сих пор дефекты не будут найдены. Поэтому, чтобы сохранить эффективность тестов и победить «пестицидный парадокс»,  должны быть созданы новые тест кейсы, а старые изменены.
• Тест ситуационно зависим: Две различные системы не должны быть протестированы одинаковым способом. Для каждой системы критерии завершения тестирования и т.д. должны быть выбраны индивидуально.
• Ошибочность предположения, что отсутствие сбоев означает пригодность системы: Поиск сбоев и корректировка дефектов не гарантирует, что система в целом соответствует ожиданиям и потребностям пользователя. Вовлечение пользователей в процесс разработки на ранних стадиях и использование прототипов поспособствует избежанию проблем.

Перевод из книги “Software Testing Foundations” (авторы: Andreas Spillner, Tilo Linz, Hans Schaefer)

Интересное в интернете:

• Быстрое создание саттелита с помощью XAP
• Даже когда денег нет, они все равно есть - так утверждает Макс Крайнов

Недавно один человек спросил меня: “Что для тебя является рутиной на работе?”. Я сходу не смогла ответить. Сейчас я сижу и понимаю, что для меня есть рутиной в моей профессии тестировщика. Это бесконечный апдейт (обновление) тест-кейсов. Для тех, кто не знает что такое тест кейс, объясню вкратце.

Тест кейс (test case) - это последовательность действий, выполнение которых дает возможность проверить соответствует ли тестируемая функция (элемент функционала) предъявленным требованиям.

Тестировщик, создающий тест кейс, в каждом шаге этой последовательности шагов описывает действие и ожидаемый результат (expected result). Тестировщик, выполняющий этот тест-кейс, может сопоставить соответствует ли ожидаемый результат полученному результату (actual result).

Хороший тест кейс включает в себя:

• предусловия (preconditions) - описание действий, которые приводят систему в состояние пригодное для проведения основного тестирования;
• описание проверки (description);
• постусловия (postconditions), которые переводят систему в исходное состояние.

Надеюсь кто-то, что-то понял из моих объяснений

Так вот, к чему я это всё Конечно же, чтобы проверить работу системы, нужно написать не один тест кейс, а целую тучу. В условиях наращивания и изменения функционала системы эти самые тест кейсы приходится переделывать по сто раз: дописывать, переписывать, удалять непригодные и досоздавать новые. Даже одно незначительное переименование какой-нибудь кнопочки может повлечь за собой лавину изменений в тест-кейсах, которые “упоминают” эту злосчастную кнопку. Ну и можно себе представить, если весь или часть интрефейса или функционала взяли и поменяли

Эта работа очень утомительна, требует внимания и концентрации. Порой это очень-очень-очень скучно, ведь проверить “налету” проще, чем сидеть и всё дотошненько описывать. Особенно повергает меня в тихий ужас апдейт тест-кейсов, которые писал кто-то другой, мне часто кажется, что все написано не в том стиле, в котором я бы это всё написала И тяжко апдейтить то, что впервые в глаза видишь Вот такая она - нелегкая судьба тестировщика.

Конечно, люди разных профессий сталкиваются с рутиной, и у каждого она своя. Интересно, а что рутина для вас?

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

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

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

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

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