СоХабр закрыт.

С 13.05.2019 изменения постов больше не отслеживаются, и новые посты не сохраняются.

| сохранено

H Тестировщик ПО. Минимальный пакет знаний для трудоустройства в черновиках Из песочницы

image

Всем привет. Что нужно знать для того, чтобы устроиться на работу тестировщиком?

I) Прочитать и понять эту книгу Роман Савин. Тестирование Дот Ком;
II) Разобраться с SQL — запросами;
III) Разослать резюме;
IV) Показать свои знания и адекватность на собеседовании.

Теперь подробнее.

I) Прочитать и понять книгу


В книге около 300 страниц. За 1-2 дня прочитать несложно. Для тех, у кого нет времени на чтение, попробую изложить коротко основные моменты. Но рекомендую прочитать её полностью.

Участники разработки ПО:
1. Менеджер проекта — специалист, занимающийся вопросами поиска заказчиков проектов и исполнителей
2. QA-инженер — специалист, задача которого организовать процесс разработки таким образом, чтобы работа была выполнена в срок и на надлежащем уровне качества.
3. Продюсер — специалист, задача которого составить спецификацию (spec)
4. Программист — специалист, занимающийся написанием или корректировкой кода программы
5. Тестировщик — специалист, занимающийся поиском багов

Цикл разработки ПО состоит из:
1. Идея.
2. Разработка дизайна продукта и создание документации.
3. Кодирование или создание кода.
4. Исполнение тестирования и ремонт багов.
5. Релиз.

Цикл тестирования ПО состоит из трех этапов:
1. Изучение и анализ предмета тестирования.
2. Планирование тестирования.
3. Исполнение тестирования.

Основные понятия:

1. Тестирование — это сравнение фактического результата с ожидаемым.
2. Цели тестирования — нахождение багов до того, как их найдут пользователи.
3. Баг (bug) — это отклонение фактического результата от ожидаемого.
4. Спецификация (spec) — это детальное описание того, как должно работать ПО. Так же, это детальное описание ожидаемого результата. (В спецификации тоже могут быть баги, например, двусмысленные предложения).
5. Тест-кейс — это инструмент тестировщика, предназначенный для документирования и проверки одного или более ожидаемых результатов.
6. Тест-комплект — совокупность тест-кейсов находящихся, как правило, в одном документе, которые проверяют какую-то определенную часть нашего проекта.
7. Шаги тест-кейса (procedure) — это часть тест-кейса, ведущая исполнителя тест-кейса к фактическому результату. (Излишняя детализация может осложнить поддержку, а излишнее абстрагирование привести к непониманию того, как исполнить тест-кейс).
8. Front end — это непосредственный интерфейс пользователя (текст, картинки, кнопки, линки и прочие вещи, которые видно в окне приложения)
9. Back end — это то что на заднем фоне приложения (веб-сервер, код приложения, база данных и т.д.).
10. New feature testing — тестирование новых компонентов.
11. Regression testing — исполнение старых тест-кейсов для проверки того, что старые компоненты ПО еще работают.
12. СТБ (Bug Tracking System) — Система в которую заносятся баги.
13. Git — распределённая система управления версиями файлов (для управления коллекцией исправлений, патчей).

Виды тестирования:

1. По знанию внутренностей системы:
• черный ящик (black box testing) — тестирование программы без доступа к коду;
• белый ящик (white box testing) — тестирование программы только по коду;
• серый ящик (grey box testing) — тестирование без кода+тестирование по коду.

2. По объекту тестирования:
• функциональное тестирование (functional testing) — например, проверка выводимого результата;
• тестирование интерфейса пользователя (UI testing) — из названия понятно;
• тестирование локализации (localization testing) — например, проверка шрифтов и другая адаптация приложения для пользователей;
• тестирование скорости и надежности (load/stress/performance testing) — например, проверка скорости загрузки сайта при определенном количестве пользователей;
• тестирование безопасности (security testing) — суть в том, чтобы усложнить условия для кражи данных (например телефонов и др. личной информации);
• тестирование опыта пользователя (usability testing) — суть в том, чтобы интерфейс был интуитивно понятен даже непродвинутым пользователям;
• тестирование совместимости (compatibility testing) — запуск на разных операционках и браузерах.

3. По субъекту тестирования:
• альфа-тестировщик (alpha tester) — тестирование сотрудниками фирмы;
• бета-тестировщик (beta tester) — тестирование пользователями.

4. По важности тестирования:
• сначала тестирование новых функциональностей (new feature testing) — тестирование новых функциональностей;
• потом регрессивное тестирование (regression testing) — повторное тестирование старых функций.

5. По критерию «позитивности»сценариев:
• позитивное тестирование (positive testing) — тестируем ожидаемыми методами;
• негативное тестирование (negative testing) — тестируем нестандартными методами(например вводим вместо 9 цифр — 11 букв).

6. По степени изолированности тестируемых компонентов:
• компонентное тестирование (component testing) — это тестирование одного логического компонента;
• интеграционное тестирование (integration testing) — это тестирование на уровне двух или больше логических компонентов;
• системное тестирование (system or end- to-end testing) — это проверка всей системы от начала до конца.

7. По степени автоматизированности тестирования:
• ручное тестирование (manual testing) — это исполнение тест-кейсов без помощи каких-либо программ, автоматизирующих вашу работу (например, создаем аккаунт вручную);
• автоматизированное тестирование (automated testing)- акаунт создается программой автоматически;
• смешанное/полуавтоматизированное тестирование (semi automated testing) — создаем акаунт вручную, но закупки сделаются автоматически.

8. По степени подготовки к тестированию:
• тестирование по документации (formal/documented testing) — тестирование по тест-кейсам;
• эд хок-тестирование (ad hoc testing) — интуитивное тестирование без документации (например, когда что-то нужно быстро проверить).

Пример тест-кейса:

image

Также по документам существует:
• Тест-смета (Test Estimation) — документ, включающий в себя предварительную оценку времени, необходимого на подготовку к тестированию и на тестирование новых фича (new feature testing);
• Тест-план (test-plan) — документ, обобщающий и координирующий тестирование (подробнее об этом документе можно узнать в книге Савина).

II) Разобраться с SQL запросами


SQL (structured query language) — структурированный язык запросов.
С помощью SQL- запросов можно создавать и работать с реляционными базами данных.
Реляционная база данных — это таблица, в которой в качестве столбцов выступают поля данных, а каждая строка хранит данные.

SQL определяется Американским Национальным Институтом Стандартов и Международной Организацией по стандартизации (ISO)
Несмотря на это, некоторые производители баз данных вносят изменения и дополнения в этот язык. Эти изменения незначительны и основа остаётся совместимой со стандартом. (например ms sql, my sql, postgreSQL).

В каждой таблице должно быть одно уникальное поле, которое однозначно будет идентифицировать строку. Это поле назовем ключевым (Key1, Key2..).
В качестве ключа обычно используют численный тип и если позволяет база данных, то он будет типа «autoincrement» (автоматически увеличивающееся).

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

SQL может быть двух типов: интерактивный и вложенный. Интерактивный — это отдельный язык, он сам выполняет запросы и сразу показывает результат работы. Второй — это когда SQL язык вложен в другой, например в С++ или Delphi.

Так как мы формируем минимальный список знаний трудоустройства, мы рассмотрим интерактивный SQL.

Представим, что у нас есть две таблицы:

Prog.db
Key1 / ProgName / Cost
1 / Windows 95 / 100
2 / Windows 98 / 120

и

User.db
Key1 / Key2 / LastName
1 / 1 / Иванов
2 / 1 / Петров
3 / 2 / Сидоров

Рассмотрим первый запрос:

SELECT *
FROM Prog, User
WHERE Prog.Key1= Key2
AND ProgName LIKE 'Windows 95'

Выбрать (SELECT) все поля (*) из (FROM) баз данных Prog и User, где (WHERE) есть связь(Prog.Key1 и Key2) Prog.Key1= Key2 и ProgName LIKE 'Windows 95'.
LIKE это тоже самое что равно(=) только для строк

Результатом этого запроса будет:

Prog.db User.db
Key1 / ProgName / Cost / Key1 / Key2 / LastName
1 / Windows 95 / 100 / 1 / 1 / Иванов
1 / Windows 95 / 100 / 2 / 1 / Петров

Отредактируем немного запрос:
SELECT Prog.Key1, Prog.ProgName, Prog.Cost*2 'руб',
Cost.Key1, Cost.Key2, Cost.LastName
FROM Prog, User
WHERE Prog.Key1= Key2

Prog.Cost*2 'руб' — эта запись говорит, что к каждое значение надо умножить на 2 и прибавить строку 'руб'.

Результат:
Prog.db User.db
Key1 / ProgName / Cost / Key1 / Key2 / LastName
1 / Windows 95 / 200 руб / 1 / 1 / Иванов
1 / Windows 95 / 200 руб / 2 / 1 / Петров

Для сортировки используется команда ORDER BY. После этого пишутся поля, по которым надо отсортировать. В самом конце нужно поставить АSC (сортировать в порядке возрастания) или DESC (в порядке убывания). Если ты не ставишь АSC или DESC, то таблица сортируется по возрастанию и подразумевается параметр АSC.

Например:
SELECT *
FROM Prog
ORDER BY ProgName DESC

Результатом будет таблица Prog, отсортированная по полю ProgNamе в порядке убывания.

SQL калькулятор:
Вот несколько функций:
• COUNT — подсчёт количества строк;
• SUM — подсчёт суммы;
• AVG — подсчёт среднего значения;
• MAX — поиск максимального значения;
• MIN — поиск минимального значения.

Этот запрос просто подсчитывает количество строк в базе:
SELECT COUNT(LecNumber)
FROM User

Этот запрос опять подсчитывает количество строк, но теперь результатом будет количество народу, у которых поле LecNumber = 1:
SELECT COUNT(LecNumber)
FROM User
WHERE LecNumber=1

Этот запрос выводит количество лицензий и единицу измерения в одном столбце. Здесь к числу прибавляется текст:
SELECT LecNumber+'шт.'
FROM User

Работа с полями:
NSERT (вставить), UPDATE (модифицировать), DELETE (удалить).
После оператора VALUES идёт перечисление всех полей строки. Теперь рассмотрим пример:
INSERT INTO User1
VALUES ('Иванов', 'Сергей', 34);

Этой командой мы вставили строку и присвоили значения полям. В таблице три поля: первые два поля строковые (Фамилия и Имя), последнее поле — целое число (возраст). Типы данных обязаны совпадать с теми, что установлены в таблице.

Если не надо задавать все поля, тогда можно оставить их пустыми с помощью NULL:
INSERT INTO User1
VALUES ('Иванов', NULL, 34);

Если таблица с большим количеством полей и нужно заполнить только два из них?
Решение:

INSERT INTO User1 (Family, Age)
VALUES ('Иванов', 35);

После конструкции INSERT INTO и имени базы стоят скобки, где перечислены поля, которые необходимо заполнить (Фамилия и Возраст). В скобках после слова VALUES перечисляем эти поля в той же последовательности, в которой перечислил перед этим (сначала фамилия, а потом возраст).

Теперь представь, что мы хотим сохранить результат запроса SELECT в отдельной таблице. Для этого в SQL всё уже предусмотрено. Нужно только написать:

INSERT INTO User1
SELECT *
FROM User2
WHERE Age=10

В этом примере сначала выполнится запрос SELECT:

SELECT *
FROM User2
WHERE Age=10

После его выполнения результат будет занесён в таблицу User1. Важно, что количество столбцов в запросе и результирующей таблицы должно быть одинаково. А самое главное — это чтобы тип данных совпадал

Теперь рассмотрим такой запрос:

INSERT INTO User1(Name,Age)
SELECT Name,Age
FROM User2
WHERE Age=10

Теперь в таблицу User1 будут перенесены только два столбца (имя и возраст). Поля должны быть перечислены в таком порядке, чтобы типы и длина полей совпадали.

Мы смогли добавить строки, но надо и научиться изменять данные. Для этого нам доступна команда UPDATE. Сразу же попробуем взглянуть на пример:

UPDATE User1
SET age=65

Первая строка говорит о том, что нам надо обновить базу User1. Вторая строка начинается с оператора SET (установить). После этого мы пишем поле, которое хотим обновить, и присваиваем ему значение.

Если нужно обновить только определённые строки, то ты должен написать так:
UPDATE User1
SET age=65
WHERE Name LIKE 'Вася'

или

UPDATE User1
SET age=age+1

или

UPDATE User1
SET age=age+1, Name='Иван'
WHERE Family LIKE 'Сидоров'

Этот запрос увеличит поле Age на единицу и установит поле Name в «Иван» во всех строках, где поле Family равно «Сидоров».

Теперь команда DELETE:

DELETE FROM User1

Эта конструкция удаляет абсолютно все строки из таблицы User1. Можно сказать, что этим мы очищаем таблицу.

Теперь рассмотрим другой пример:

DELETE FROM User1
WHERE Age=10

Этот пример удаляет только те строки, в которых поле Age равно 10.

Понимания этих запросов будет достаточно.

III) Разослать резюме


Самая короткая глава, это все умеют, hh.ru вам в помощь. Там же можно составить резюме. Перед составлением не забывайте смотреть резюме своих конкурентов.

image

IV) Показать свои знания и адекватность на собеседовании


Обычно собеседование делятся на 3 этапа:
1) Встреча с девушкой из отдела кадров. На этом этапе будет несколько вопросов по вашим знаниям, чтобы было понятно, что вы в «теме» и много общих вопросов, чтобы определить вашу адекватность.
2) Тестовое задание — обычно дается на дом
3) Встреча с руководителем где будут вопросы, касающиеся ваших навыков тестирования.

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

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

Рассмотрим основные вопросы и и примеры самых обычных ответов на них:

1) Почему вы решили стать тестировщиком?
Меня всегда тянуло в IT сферу, эта профессия больше всего подходит моему характеру и моим интересам.

2) Что больше всего вам нравится в тестировании?
Я обожаю анализировать и изучать программы, например на прошлом месте работы мне больше всего нравилось работать с 1с, я даже смог поставить одну из версий себе на домашний компьютер, для более детального изучения программы, без всяких ограничений.

3) Какими достоинствами должен обладать эффективный тестировщик?
Честность, внимательность (для поиска багов), общительность(так как нужно будет много общаться с персоналом), обучаемость (без этого никуда), умение работать с большим объемом информации и умение расставлять приоритеты, и, конечно, стрессоустойчивость.

4) Ваше самое большое профессиональное достижение (не обязательно в области тестирования).
Создание и поддержание базы для логистики и закупа, которой пользовались все менеджеры компании. По этой базе, я мог закупить все, что мне нужно максимально дешево, и с любой точки России доставить товар с отличным соотношением цены, качества и риска.

5) Почему вы ушли (уходите) из своей предыдущей компании?
Мне нравилось работать в прошлой компании, но я хочу опробовать себя как тестировщик ПО. Так как данная сфера ближе к моим интересам, характеру и увлечениям. На этой должности я буду получать гораздо большое удовольствия от работы.

6) Приведите пример сложной ситуации, с которой вы столкнулись в своей карьере, и какой выход из нее вы нашли?
Из-за текучки кадров, мне часто приходилось брать обязанности других на себя, например доставка или закупки. И чтобы свести всю свою деятельность в единую систему, в свободное от работы время я создал базу (excel), которая собрала в кучу всю мою старую и новую деятельность. Эта база не дала мне запутаться в огромном количестве работы. Так же она помогла избавиться от блокнотов и стикеров, а это значит, что покупатели всегда видели порядок за моим рабочим столом.

7) Что бы вы пожелали усовершенствовать в себе? Что вы для этого делаете?
У меня есть хобби — программирование. Хочу совершенствовать свои навыки в этой области, они же в дальнейшем помогут улучшить мои навыки тестировщика.

8) Что вы ждете от нашей компании?
Хороший коллектив, и профессиональное развитие

9) Какой минимальный доход вас устроит?
Можно посмотреть средний доход по региону на эту вакансию и назвать его. Но, если вы проходите собеседование в 2гис, то говорите что готовы работать бесплатно 24/7/365, как рекомендует Савин. Так как эта книга эталон для их отдела кадров и им будет приятно знать что вы ее уже прочитали.

10) Какими источниками вы пользуетесь для развития в этой области
Можно посмотреть в конец статьи и назвать все, что будет в списке «Источники, которые были использованы для написания статьи:»

11) Кем вы видите себя через 5 лет?
Тут на ваш вкус.

В принципе все. У вас все получится. Главное:

image

Источники, которые были использованы для написания статьи:
Роман Савин. Тестирование Дот Ком;
Wiki Тестирование программного обеспечения;
Флёнов Михаил. Язык запросов SQL;
Wiki sql;
Форум тестировщиков;
habrahabr.ru;
Книги для молодых тестировщиков.

комментарии (34)

+9
vilgeforce ,  
Курс SQL — эт хорошо, конечно. Правда, существуют более толковые статьи по нему и даже целые книги. Вот только я не смог во всей этой простыне найти ЗАЧЕМ тестировщику SQL…
–6
+3 –9
kotia ,  
когда тикетов очень много, фильтровать нужные быстрее всего по запросу
+4
vilgeforce ,  
А при чем тут SQL? Mantis/RT уже не в почете?
+4
Blandinka ,  
Создание и управление тикетами напрямую в БД? Только SQL, только хардкор!

Надо будет нашим тестировщикам предложить, а то все Jira, да Confluence :)
+2
vilgeforce ,  
Ы! Так и вижу через sql работу с конлюенсом. Он и через гуй-то не всегда очевиден :-D
–2
kotia ,  
advanced filters пишутся на каком-то другом языке?
+1
VitaliyNSK ,  
Если зайти на hh.ru, там во многих вакансиях требуют знание языка запросов SQL
+1
vilgeforce ,  
И вместо этой короткой фразы, вместо анализа зачем же оно может быть нужно — вводный курс по SQL. Зря.
+3
+5 –2
lair ,  
Тестовое задание и встреча с руководителем вряд ли уйдет за рамки того, что мы написали выше.

Правда? Тут нет большей части вопросов, которые мы задаем при собеседовании на вакансию тестировщика.

Можно посмотреть в конец статьи и назвать все, что будет в списке «Источники, которые были использованы для написания статьи:»

… после чего получить вопрос на содержание перечисленных книг и попасть в неловкую ситуацию.

1. Менеджер проекта — специалист, занимающийся вопросами поиска заказчиков проектов и исполнителей
2. QA-инженер — специалист, задача которого организовать процесс разработки таким образом, чтобы работа была выполнена в срок и на надлежащем уровне качества.
3. Продюсер — специалист, задача которого составить спецификацию (spec)
4. Программист — специалист, занимающийся написанием или корректировкой кода программы
5. Тестировщик — специалист, занимающийся поиском багов

Здесь хоть как-то правильно описан только программист, да и то…

Зачем абстрактному любому тестировщику нужен SQL — прекрасный вопрос. Ну и да, за такие таблицы, как у вас в примерах, тоже надо бить.
+2
IvanovSV ,  
тестирование опыта пользователя (usability testing) — суть в том, чтобы интерфейс был интуитивно понятен даже непродвинутым пользователям;

Одна из основных проблем как тестировщика, так и многих других участников проектов — им сложно мыслить как пользователь. И чем дольше люди работают в разработке ПО, тем дальше они от пользователя отдаляются.
–1
Darthman ,  
Тестировщик должен уметь думать и действовать как 3 вида пользователя.
1) по инструкции
2) методом тыка
3) опытный пользователь

Если он этого не умеет, то грош цена тестировщику такому.
+1
IvanovSV ,  
4) тупой пользователь (и это не методом тыка)
0
vilgeforce ,  
После такого тестирования останутся, думаю, только очень хитрые баги…
0
Blandinka ,  
и куууча запросов на изменение :)
0
Darthman ,  
Я примерно это и хотел написать, но почему-то стер и написал «методом тыка» :)
0
ANTPro ,  
0
kibal4iw ,  
Первую часть до sql-запросов для себя нашел полезной. Огромное спасибо за пример тест-кейса.

Вопрос — на сколько хорошо нужно знать sql тестировщику?
+1
Blandinka ,  
Вопрос — на сколько хорошо нужно знать sql тестировщику?

Настолько же, насколько любому другому грамотному ИТ-специалисту.
Реальное применение этих знаний сильно зависит от специфики работы тестировщиков в конкретной компании.
На моей практике выполнением прямых запросов в БД тестировщики никогда не увлекались. Особенно если баг появляется на живой системе заказчика :)
0
kibal4iw ,  
Спасибо
+13
Cenness ,  
Этот оператор относится к выражениям Булиан.

Божественно.
0
+1 –1
Evengard ,  
Есть Джулиан, а есть Булиан, его брат.
+3
Darthman ,  
Позволю себе не согласиться немного с Вами. Тестировщик это не человек, который ищет баги. У него цель не баги искать, а проверять корректность работы программы в различных условиях.
Допустим: тестировщик нашел 10 багов. Сидел и специально искал их, но все они появляются, когда он левой пяткой через десять окольных путей нажимает на красный левый пиксел в углу формы. Да, это баг, несомненно. И его даже надо бы поправить. Но вот незадача, пользователи врядли так вообще когда-нибудь сделают.
Что мы имеем в итоге? То, что тестировщик потратил кучу времени и сил, но не проверил то, что должен был.

Поэтому нахождение багов (именно нахождение, а не поиск) это следствие работы тестировщика. А цель его работы — проверка правильности работы программы в наибольшем количестве сценариев использования.
+2
AndreyBessolitsyn ,  
Есть три вида тестирования:
1) Проверка работоспособности функционала — это то, о чем вы пишете в своем первом предложении как о работе тестировщика.
2) Проверка ПО с точки зрения рисков — необходимо проверить не сам функционал, а насколько ПО устойчиво например при отключении Интернета, переполнении дисков и так далее.
3) Целенаправленный поиск багов — т.е. мы специально ищем ошибки. Ошибки ищем проверяя нестандартные сценарии, необычные способы использования, «странное» поведение пользователей.
+3
Darthman ,  
Я имею ввиду, что поиск багов это не самоцель. Софта без багов, наверное, не бывает вовсе. Однако, баги, на которые никто не наткнется никогда, искать бессмысленно. Если он не критичен и вылезет у 1 пользователя через два года, то никто не расстроится.
Увы, наверное, меня задело высказывание про цель тестировщика искать баги потому, что последний тестировщик, с которым я работал, так и делал. Он тупо искал баги. Он их находил, но левые. А то, что основной функционал местами работал неверно, он не заморачивался.
0
IvanovSV ,  
«странное» поведение пользователей.

А какое поведение пользователя вы считаете странным?
0
AndreyBessolitsyn ,  
Были у меня Вьетнамцы, которые роняли IP телефон быстро нажимая кнопки по 50-70 раз.
–1
VitaliyNSK ,  
Я дал определение бага. Баг это отклонение фактического результата от ожидаемого. То есть:
1) Когда мы проверяем функционал, мы ожидаем что он работает. И если по каким то причинам он не работает это баг.
2) Проверяем ПО с точки зрения рисков, например ожидаем что программа будет работать корректно при 5 секундных перебоях связи. Если программа падает то это баг
3) Вводим нестандартные значения в поля и смотрим как реагирует программа. Например ожидаем что будет появляться таблица с ошибкой, где написано введите другое значение, а вместо этого появляется «inf». Значит это баг
+1
lair ,  
Вопрос в том, на чем основаны ваши ожидания.

ожидаем что программа будет работать корректно при 5 секундных перебоях связи

А почему она должна это делать?

ожидаем что будет появляться таблица с ошибкой

А почему вы этого ожидаете?

Иногда бывают неверные ожидания. Иногда бывают неверные требования. Иногда бывают неоднозначные или неполные требования. Далеко не всякое неожиданное для тестировщика (и пользователя) поведение программы — это баг.
0
IvanovSV ,  
А почему она должна это делать?

Потому что так написано в ТЗ

Далеко не всякое неожиданное для тестировщика (и пользователя) поведение программы — это баг.

Это не баг, это фича.
Опять же к тому, что многие разработчики делают сферическую систему в вакууме.
Приведу пример: в одном нормативном документе прописаны требования к характеристикам рабочего места пользователя. Участвовали в написании данного нормативного документа разработчики одной системы. И действительно — в голом виде эта система будет на этих требованиях работать. Без неожиданного поведения. Вот только на реально живом рабочем месте, кроме системы будет стоять зоопарк разного софта (Випнет, Крипто-Про, Антивирус, Офисная программа, ява и т.д.).
И все. Система встает. Т.к. для одного модуля системы граждане пишут все на яве, при этом с учетом обновлений явы. А в другом модуле системы внезапно выясняется, что Крипто-Про JCP, имеющийся у заказчика не работает с явой последних версий.
А все вместе это еще и безбожно тормозит. Для пользователя мы видим неожиданное поведение программы — половина модулей отваливается. Для разработчика все в норме. Хотя в ТЗ на систему написано: поддержка всех видов подобных криптопровайдеров (и много чего другого написано).
Опять данная система, в ней отчетность. В которой ни одна цифра не бьется с другой. Запросил алгоритм создания отчетов.
С точки зрения разработчиков — по алгоритмам все отчеты создаются верно. Только в качестве исходных данных выбираются совершенно разные показатели. Результат — нет ни одного реально рабочего отчета.
И все это не баг. Это фича.
+5
pnick ,  
Человек ищет работу тестировщика в эНСКе и облегчает себе задачу трудоустройства вредными советами конкурентам. Что вы прицепились? (:
0
icepro ,  
И все же автору спасибо.
Ссылка на книжку получилась самым полезным куском статьи для меня.
0
olegafx ,   * (был изменён)
8. Front end — это непосредственный интерфейс пользователя (текст, картинки, кнопки, линки и прочие вещи, которые видно в окне приложения)
И правда. Сидим, картинки в окно накидываем. За это и деньги получаем…
0
igorpr ,  
Простой алгоритм подготовки и прочитать хотя бы одну книжку, это конечно хорошо. (Хотя книжка не самая классическая по тестированию).
Но как правило подобные «специалисты» срезаются на элементарных задачках. Например — протестировать чайник, где надо бы все перечисленные понятия и методы применить:)
0
rlabs ,  
Вот и выросло поколение, считающее авторитетом Савина…