Как тестировать документацию. Простой алгоритм
5 мин
Туториал
Мы все знаем прелести раннего тестирования и честно стараемся ревьюить требования, архитектурные проекты и прочую документацию. Выискиваем неполные описания, инструкции, которые приведут к ошибкам и вопросы без ответов.
При этом у меня бывает, что на тестировании документации сложно сфокусироваться, особенно если это затянувшееся коллективное ревью, автор рассказывает детали, а скука обволакивает и затягивает в сон. Я попыталась себе помочь, и зафиксировала некоторые азы рецензирования. Держу их перед собой. Добавим чашку кофе, и ревью превращается в осмысленное мероприятие.
Тем, кто формирует свой стиль работы, пригодится. Делюсь!
В компании я занимала должность QA Engineer-а. А знаете, что значит быть тестировщиком на таких проектах? В первую очередь, это значит выполнять много физических упражнений! Да-да, это тебе не в кресле целый день сидеть. Тут нужно и в самолет забраться, и спутниковый приемник в пустыне установить, и МРТ сделать, и пожар потушить. Причем по кругу много раз. Потому что, когда ты вдруг обнаружил, что в самолете датчики не работают, сообщил об этом разработчикам и отправился в пустыню монтировать сателлит, а там ветер незапланированно стих, и ты забиваешь на эту поломанную пустыню и отправляешься на завод тушить пожар, тебе вдруг говорят «мы починили самолет, проверь, пожалуйста» и принимаются «исправлять ветер в пустыне». И так несколько раз в день.