На последней конференции ETalks QA 2010, которая была посвящена «контролю качества программного обеспечения и всему, что с ним связано», в конце было выступление Александра Калугина. Это выступление переросло в круглый стол, который перерос в afterparty и продолжился уже в такси по дороге по домам. Речь зашла о том, что должен делать по настоящему полезный QA-отдел для общего успеха. Спецам по качеству было предложено обосновать свое существование. Также было сказано, что одного тестирования не достаточно. Ну, пусть лучше Александр сам расскажет в своем блоге.На самом деле, QA бывает и правда трудно объяснить, за что ему платят. Как говорил один выдающийся борец за качество — «У каждой ошибки есть имя, отчество и фамилия». Это действительно так, но означает ли это, что для обеспечения качества достаточно подобрать правильные кадры? Тот же самый борец за качество утверждал — «Кадры решают все!» Тогда можно будет забыть про тестирования от билда к билду, процессы QC, их аудит и кстати еще многое другое, что в том же CMMI описано. Было бы здорово! Тут должны обрадоваться те парни, что вложили в фирму деньги и очень не любят платить налоги с ФЗП.
На деле всем так повезти не может. Проверка соответствия продукта и спецификации требований (то есть, проверка качества) часто является очень трудоемким процессом и требует такого же внимания и сосредоточения, как и работа, например, аналитика. Это становится непрерывным процессом, которому нужны люди.
Можно обратиться к признанным мастерам качества — японцам, и их идеологии «кайдзен». Там есть несколько замечательных принципов. Нам особенно пригодятся следующие два:
Да, качество достигается не просто тестированием. Но вот именно от QA я, как их заказчик, прежде всего жду качественной проверки соответствия требований и продукта. Мнение QA о том, что «когда-то так мы уже делали и это не понравилось» мало интересуют. Замечания о былых недочетах в архитектуре и потенциальных проблемах в производительности меня интересуют немного более. Только это все есть в отчетах о тестировании, если они хорошие. Так что все эти выводы и без участия QA есть кому делать. QA должен быть профессионален в своей области и будет с него. Грамотные запросы к аналитикам и отчеты разработчикам — этого достаточно. Да, при таком подходе QA превращается во вспомогательную службу, а это всегда объект для экономии. Да, тут мало сотрудничества и team spirit.
Я в течение своей карьеры не очень-то уверовал во взаимовыгодное сотрудничество внутри коллектива и считаю, что за интеграцию должны отвечать специальные люди. А вот тем, кто просто хорошо делает свою работу, я очень благодарен. Это пока еще такая редкость.
Recent Comments