Automated Acceptance Testing: A Literature Review and an Industrial Case Study <s> Communication <s> This report describes experiences of introducing executable acceptance testing in senior software engineering courses. Students in an agile environment completed a five iteration project with significant portion of requirements specified as executable acceptance tests. Furthermore, students were required to write their test suites for an additional component. Ability to learn and utilize the FIT acceptance testing framework is evaluated to find out if FIT tests can be used to replace requirement documents. The results of a survey of students' perceptions and experiences were encouraging. <s> BIB001 </s> Automated Acceptance Testing: A Literature Review and an Industrial Case Study <s> Communication <s> This research investigates the process of Executable Acceptance Test-Driven Development (EATDD) in the context of specifying functional requirements using the FIT framework, when developing line-of-business applications. ::: It is guided by three key research questions: (1) how business and technology experts utilize EATDD in the software development lifecycle; (2) what kind of benefits and limitations EATDD manifests, and (3) to what extent improvements in software quality (if any) are associated with EATDD? ::: The research employs methods of quantitative and qualitative inquiries. Based on the findings of two academic observational studies, one academic quasiexperiment, and three industrial multi-case studies, the following main conclusions are drawn: (1) the use of Executable Acceptance Test-Driven Development is correlated with the enhanced communication in software teams; (2) executable acceptance tests are suitable for specifying functional requirements and are in fact unambiguous, consistent, verifiable, and usable (from both the business experts' and technology experts' perspectives); (3) EATDD provides sufficient evidence of requirements traceability in regulated environments; and (4) current state of tool support negatively impacts the maintainability and scalability of the artifacts produced in the course of EATDD. ::: In addition, our contribution includes emerged conceptualizations and the sociotechnical model of the EATDD process. These not only help to explain the ways how EATDD is used in practice, but also form a base for future investigations. <s> BIB002
Being stated as one of the core benefits, it would be interesting to see what is found about the use of Fit for communication. One problem lies in letting the tool drive the collaboration and not vice versa. Interestingly, Gandhi et al. noted in their study that one group claimed that using Fit initially hindered communication [16] . They focused too much on preparing 'syntactically correct Fit documents' for the development team, and didn't focus on developing the most appropriate specification. Melnik reports about one team where the project manager said that "We value conversation more than the actual tool itself [Fit]" BIB002 , p. 188, and that Fit helped them with this. Read et al. found in their study that 41% of student groups developing software had no contact with the test suite development team during development BIB001 . In another study by the same authors the Fit suite summary was by some student groups being used as a project dashboard  . Since the tests were stored at a centralized server, project members and instructors alike could check the project progress whenever they wanted. It seems viable that also project customers could use such a feature to keep track of project status.