Если, не раздумывая задать вопрос – кто отвечает за качество программного обеспечения, то первым ответом в голове будет фраза – исключительно [highlight dark=”no”]тестировщик[/highlight], а кто же еще! Но не всё так просто, как может показаться на первый взгляд.

В IT-сфере есть некоторые особенности, которые всегда встречаются на стадии финального тестирования программного обеспечения перед его непосредственной сдачей в релиз. Они заставляют думать о процессе тестирования не только в разрезе технической проверки ПО, но и как о составной части определенного этапа создания и внедрения ПО.

Качество ПО

Должны ли программисты тестировать свой код?

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

Если программист знает, где слабая часть продукта, а тестировщик этого не замечает – [highlight dark=”no”]нужно ему обязательно подсказать.[/highlight] По итогу, QA-инженер будет максимально признателен, а разработчик лишится надобности дополнительно исправлять уже разработанный и сданный код. Тестировщик покроет всё тестами, и программисту больше не придется волноваться.

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

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

Если код не заработает на этой стадии, нет необходимости передавать его тестировщикам. Обратно прилетит большой баг-репорт с массой дефектов, о которых вы и так знаете. Это еще больше замедлит выпуск программного обеспечения.

Пропуск бага в рабочей среде – виноват тестировщик?

Пятьдесят на пятьдесят. Всегда когда в рабочей среде обнаруживается дефект, отделу тестирования есть о чем поговорить.

На практике есть сразу несколько причин, почему некоторые баги всплывают исключительно на рабочей среде:

1. Эта «часть» ПО никогда не была выведена в приоритет для тестов. Порой бывает так, что про баг, найденный в рабочей среде, никто и не мог подумать. Это итог неверной коммуникации между программистом и тестировщиком. Не было настроено должное взаимопонимание в вопросах того, как важно протестировать ту или иную область ПО. Если есть уверенность, что некоторые критические области ПО не были покрыты тестами, нужно поскорее сообщить об этом команде разработчиков;
2. Тестировщик не обладает достаточными знаниями для тестирования определенной области. Это тоже глобальная проблема обоих лагерей. Программист создал функцию, но забыл уведомить проверяющего про её специфику функционирования. Если вы как программист видите важный аспект ПО, стоит в первую очередь уведомить главного QA-инженера об этом моменте. Обойти данный этап возможности нет;
3. Программисту все равно. Разработчики тоже люди. И у каждого из них есть своя жизнь и за пределами офиса. Есть программисты которые ценят не только свой труд, но и заботятся о том, чтобы тестировщик проверял ПО высокого качества: они помогают найти баг, информируют о специфике проверки и так далее. А есть люди, которым все равно. Они, может и не будут пользоваться этим ПО каждый день, и им все равно что с ним в конечном итоге случится. Другими словами, их абсолютно не волнует как продукт будет работать в рабочей среде;
4. Тестировщику все равно. А вот и обратная сторона медали. Не все тестировщики испытывают интерес к проектам, на которых они работают. Некоторые просто хотят побыстрее закончить тестирование, создать читабельный отчет и поставить точку. Качество покрытия тестов их не очень заботит, они не желают поддерживать коммуникацию с разработчиками. Программисты и тестировщики должны постоянно обсуждать природу багов, но подобная когорта тестирощиков с полным равнодушием отнесется к подобным митингам и прочему;
5. К проекту привлечены неквалифицированные тестировщики. Еще проблема может крыться в том, что на проекте трудятся не совсем квалифицированные тестировщики. К примеру, стоит провести тесты на проникновение, а всё что есть в руках менеджера проектов– группа тестировщиков, которые могут выполнять только ручное тестирование. В данном случае они банально не будут понимать, что конкретно от них требуется. Остается либо выбирать более квалифицированных тестировщиков, либо возлагать подобные работы на программистов;
6. Полное отсутствие исследования поведения пользователей. Программист знает как создать ПО, а тестировщик – как его проверить. А что делать с пользователями? Пользователь – это ведь живой человек, который будет время от времени взаимодействовать с программным обеспечением. Он не будет его ломать. Просто все люди разные, обладают разными целями, и все это они желают достичь с помощью создаваемого ПО. Тестировщик может привыкнуть к багу и банально осознать, что он возникает нерегулярно, а значит, – не обладает статусом критичности. Пользователь подобного никогда не будет терпеть. Если ПО ломается, пользователь его либо удалит, либо забудет и обратится к альтернативам. Это жизненная реальность. Наличие исследования пользователей или привлечение тестовой группы на проект – стратегически важная вещь при разработке и тестировании многофункционального веб-продукта;
7. Неграмотно выстроенный процесс коммуникации. В идеале, на проекте должен быть банальный процесс сортировки дефектов, с помощью которых программисты смогли бы трезво оценивать баги, зафиксированные тестировщиками (да и просто банально расставлять приоритеты по их исправлению). Если возникает техническое недоразумение, тестировщик и разработчик должны сразу начать диалог, дабы решить проблему в зародыше (это в идеале). Если менеджером подобная коммуникация не выстроена, то обе стороны просто будут имитировать вид серьезной занятости, а проблема не будет решаться. В конечном итоге баг всплывет в рабочей среде;
8. Мало тестировщиков. Программное обеспечение может быть сложным и должно быть проверено сразу на нескольких платформах и браузерах. Пары тестирощиков для этих целей может быть недостаточно. Стоит либо нанять еще людей, либо же изыскать возможности перераспределить человеческие ресурсы, чтобы все было крайне качественно проверено;
9. Программисты заняты работой. В компании может быть всего 4 программиста, но они отличаются хорошим уровнем технической осознанности и готовы решать даже самые сложные задачи. Но их всего 4, а проектов много, сроки жмут и времени на достаточное обсуждение ПО с отделом QA – у них банально нет. Это очень важный и распространенный критерий, почему продукт попадает в рабочую среду с большим числом дефектов;
10. Качество – не главное. В ПО есть пара багов. Один визуально заметный, второй нет. Но ПО не пришлось по душе конечному пользователю. Отзывы исключительно негативные. Почему? Никто просто не хотел изначально создавать исключительно качественный продукт. Программисты писали код, тестировщики – проверяли, но никто не уделял должного внимания процессе проверки качества. Создание веб-продукта должно объединять отделы, делать из них одно целое. Если в компании подобного настроения не прослеживается, на качество ПО всем все равно.

Краткие итоги

В сегодняшних реалиях IT-сферы, программное обеспечение становится все сложнее и сложнее. Найти виноватого в провале всегда просто. Вина может быть на тестирощике, менеджере или программисте. Или на всех вместе. Суть заключается в том, что [highlight dark=”no”]не стоит искать виноватого[/highlight], если изначально можно [highlight dark=”no”]взять контроль качества на себя.[/highlight]

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