In TID we tend to have a few problems with how we do software testing.

• Someone does some development but they forget to run and update the tests, so next time someone comes along they are broken and no one can remember why.
• Testing takes a lot of development time, but we still have simple bugs in the code which only turn up with manual testing or after going live.
• Our tests don’t help us enough when refactoring because they are too fragile and rely too closely on the internal structure of the methods, class or package.
• We are often updating our tests when making even small changes to code.

These problems indicate that we have holes in our test strategy that we should be aiming to resolve.

The Shotgun Test Strategy

With a shotgun test strategy, you […] assume that everything and anything can and will be buggy. However you accept that you cannot test everything. Since you lack any solid idea on where to find bugs, you test wherever and whatever comes to mind. You attempt to randomly distribute the test effort, like pellets from a shotgun, within the given resource and schedule boundaries.

– Pragmatic Software Testing (Rex Black)

This sounds very similar to the strategy that I have followed in the past, except I don’t even feel like I have necessarily made efforts to randomly distribute the test effort. Often the main determiner of whether something gets tested is how easy it is to test. When I know I can’t test everything in as much detail as I want, I fall back to testing as much as I can with the time available, even if that is not a very useful place to be adding tests.

This results in a great deal of tests, but little planning as to what gets tested and some rather obvious holes in test coverage. Examples of this include:

• View-Models in Aurelia projects are mostly untested because it’s difficult and we don’t understand it.

A cause of this is that we use technology stacks in which unit testing is not straightforward out the box, and we have not put effort into working out how to write testable code in these environments. PHP frameworks in use (Laravel and CakePHP) and Javascript front-end frameworks are the worst culprits here.

As a result I believe we should put some research and work into working out the best way to make sure our framework code is testable at a unit level. This may require a change in how we write the code for these, including making more use of abstractions layers.

Long Term Value of Tests

In theory the value of tests come in several parts:

1. They confirm that the code you have written does what you expect it to do at the time of development.
2. They act as regression tests to confirm that you have not broken the system when adding new features or fixing other bugs.
3. They allow refactoring with confidence that the system will still do the same thing afterwards.

Currently our tests do 1 reasonably well and do 2 in a limited sense, and are often almost useless for 3.

Writing unit tests along with the code allows us to use them as verification of the code we are writing, which is good as it allows us to quickly check assumptions and behaviour. Where this falls down is when we have well tested units but have neglected to test the interfaces and boundaries between units. Mocks (and other testing helpers) are good as it allows us to test a unit in isolation, but when a unit requires an excessive amount of mocking that is often a sign that it may have complex interfaces behind which bugs in the code missed by unit testing may hide. It also makes the tests more complex, which increases the chance that there are errors in the tests hiding errors in the actual code.

On 2, it is useful to be able to run tests when making changes in the system to check that you have not broken anything, but a problem that frequently arises is when changes in the system do cause regression tests to fail. Often these failures are red herrings, and the new code is still correct but has broken the tests because they were fragile and reliant on something working in a specific way when we didn’t really care about the code behaving in that way. Number 3 is very similar, but in most cases refactoring causes test failures anyway, some of which may be legitimate and some erroneous. When there are legitimate and illegitimate test failures happening at the same time it can be very difficult to rely on your unit tests as confirmation that you are doing things right or wrong.

One solution to this problem is to test at multiple levels. Currently unit tests are the priority for testing business logic. However often higher level integration tests for testing subsystems are used, especially when using frameworks which make pure unit testing difficult, or when retro-fitting unit tests to code which was not written with test-ability in mind (for example legacy code). A more appropriate testing strategy might be to use a multi-level testing strategy where all code is tested with unit tests for detail, integration tests to check that the subsystem is behaving correctly from the perspective of the external observer, and system level tests which test from the very outside of the system (at a UI or API level with a full stack in an operational server environment). Higher level tests should be less fragile and less likely to break (unless the external interface changes, which should be a relatively rare occurrence).

Integration and system tests should be fully Black Box tests, where the system internals are ignored and inputs and outputs are checked only via the specified endpoints that are part of the system interface. This is to remove any dependence on implementation details. UI tests should be run against a deployed test system. To facilitate this we should investigate UI testing technologies, for example Selenium and PhantomJS.

Continuous Integration

We have a number of systems which are under relatively continuous development, the key example being Choices. There would be some value in trying out Continuous Integration for a small number of systems such as this. There is risk that maintaining the CI system and making sure that the tests keep working in it becomes a task unto itself, and we should be careful to avoid this.

A CI system would be able to catch any deployments where the tests were not run properly beforehand. Despite the fact that our development processes include the instruction to run all tests before committing, this is still something that causes occasional problems, and CI would prevent these.

Добър ден! Днес ще си говорим на български. Още миналата седмица щях да пиша на български, но не можах поради технически проблеми.

Тази седмица се занимавах само и единствено с работа по моя проект. Трябваше да довърша втория спринт в сряда, но го довърших в петък, понеже мислех, че трябва да го довърша в четвъртък. На практика дори не го довърших… 🙁

Изображения

Не очаквах да ми отнеме толкова дълго време да работя върху прикачването на изображения към въпроси и отговори. Оказа се, че всъщност трябваше да направя всички тези неща:

• Да се науча как се качват изображения в PHP/Laravel/HTML
• Да се науча как се правят тестове за изображения в Laravel
• Да се науча как да генерирам нови елементи с JavaScript
• Да се науча как да render-вам изображение от файл, вместо просто да слагам файла в публична папка, което би било риск за сигурността
• Да измисля как да дам на потребителите да изтриват избирателно вече качени изображения когато редактират въпрос или отговор
• И така нататък

Съответно първоначалните ми предположения колко време ще отнеме бяха изхвърлени през прозореца. Очаквах да ми отнеме ден или най-много два, но в действителност ми отне… не искам да знам колко дни. Дори днес, докато демонстрирах проекта пред други стажанти, имаше бъг и изображенията не излизаха като хората. ААААА!

В крайна сметка се получиха добре, ама беше много досадно.

Други нови добавки

Останалите подобрения на системата включват:

• Студентите могат да “харесват” публични въпроси
• Студентите могат да си изтрият въпрос, ако не му е отговорено още
• Студентите могат да си редактират въпросите
• Лекторите могат да си редактират отговорите
• Лекторите получават имейл когато има изпратен въпрос
• Студентите получават имейл когато е отговорено на техен въпрос
• Лекторите могат да направят въпрос публичен или таен пост фактум
• Потребителите могат да “тагнат” предишен въпрос като споменат номера му (например #15) и това автоматично се превръща в линк към стария въпрос
• Лекторите могат да отбележат въпрос като спам или обида

Всъщност е бил доста продуктивен този спринт!

Другата седмица – последният спринт

Другата седмица и началото на седмицата след това са последните дни от стажа ми. плача.гиф

Ще бъде голяма лудница, тъй като имам да довърша следните неща:

• Свързване на системата с Banner
• Използване на пресния ни плъгин за single sign-on, който работи с mod_auth_mellon
• Умно търсене на въпроси
• Качване на сайта на сървърите, които сме помолили да ни предоставят
• Козметични поправки и довършителни работи
• Непредвидими проблеми :)))))))))))))))))

Доволна съм от постиженията дотук, дано да го докарам до състояние в което да е готово за употреба!

Благодаря за вниманието, да живее България и киселото мляко!

Quickest ever!!

This week I was purely working on sprint 2 tasks. It is literally time for me to leave so excuse the fact that I’ll use a screenshot to describe what I’ve done:

Blog Post 7

Hello again!

This week’s blog post was supposed to be special. I was going to write it in Bulgarian. Unfortunately, Ubuntu is being funny and not allowing me to use the cyrillic alphabet. Next week I guess!

Last week I thought I was almost done with Sprint 1. I was wrong and it took me until Thursday to do it. 🙁 Still better than the expected which was the end of Friday!

Czech out my progress at this link if it works

University Bootstrap Template

Last week I started using the University Official Bootstrap University Branding Template. At first I was finding it hard to fit my design ideas into the style of the template, but after a lot of effort I managed to make things look presentable. Since last week I’ve made a bunch of improvements and some new pages.

The pages I’ve made are the following:

• Login
• Home
• My modules
• View module
• View question
• My unanswered questions
• My answered questions
• Ask a question
• Universal HTTP error page

Bugs

This week I discovered a bunch of bugs and had to treat them. Yuck! At least they’re out of the way now.

The Wonders of Test-Driven Development

Ever since last week when structure was established into my project, I’ve been following the principles of test-driven development. I’ve noticed the following things:

• It can save a ton of time
• It can be frustrating
  • When you’re a noob and you don’t know how things will work, how do you know what the test should do?
  • PHPUnit doesn’t spit out any error messages so it’s annoying to debug tests
  • Tests are boring
• However TDD is still the way to go for sensible reasons

I’ve had 1 persistent issue with my testing: it deletes the live database every time. I understand there is a way to configure it so that the tests have their own database. I tried doing that but suddenly half my tests were failing for no reason. Oh well! One day I might try again.

Current level of functionality

Things the system can currently do include the following:

• Student can ask a question
• Lecturer can answer a question & choose whether to make it public
• Student can see all their own questions & all other public questions
• Lecturer can see all the questions on their module
• Students can like & unlike questions
• Students & lecturers can see how many likes a question has

Screenshot Dump

Weekly screenshots!!

Weekly Rayna!

This week I developed some web. I’ve come such a long way that I barely remember the week.

Kanban Chart

Before this week my development process was none. I was simply trying to accumulate as much functionality as possible by stacking chunks of code on top of each other. This was making me anxious, as you might have noticed in previous episodes of the blog. It was time to establish some structure!

I was introduced to the wonders of SourceKettle and Kanban. I used to think SourceKettle was a GitHub alternative similar to iGit. Now I’ve discovered that it has advanced task management features and the draggy feature (dragging tasks between columns!!). You could say I’m a Kanban fan.

My Kanban chart was quickly populated with all the tasks that would make my system basically usable. This was going to be my first sprint which was estimated to take 2 weeks.

I think I’m almost done with this sprint so I might have some time to spare. Woooohoooooooooo!!!

Web Dev

How do I explain what I did without making it 100% boring… I made the back-end for asking questions, answering questions etc etc etc, then I made pages for asking questions, answering questions etc etc etc.

On the front-end, I am now using the University template which uses Bootstrap 3. It doesn’t exactly inspire my artistic senses, but it’s starting to look decent. I still have the option to abandon the UoS theme and plop all my stuff onto a blank white page and I think it would look better. I hope I’m allowed to do that. 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂

Screenshot dump

Lecturer module page – split into Unanswered questions & Answered questions (ignore the ANSWERED labels – I was playing around):

Student module page – split into My Questions and Public Questions:

Answered question page:

Unanswered question – lecturer view:

Ask a question page:

Next Week

Next week I will keep going until I finish this sprint and I will start the next one. Yay!

I only have 4 weeks left :'(

Heyyyyy there, it’s time for another weekly recap of what I’ve done at work!

Getting a blessing from ECS

On Monday morning Patrick and I went to Highfield to meet up with Nick Gibbins, Director of Programmes for Computer Science, who has been the primary voice of the lecturers in this project. I expected him to mostly disapprove of my proposition, given that he was a fan of the Stack Overflow idea where students can answer each other’s questions. To my surprise, he agreed that a system where lecturers are the only ones to answer questions is feasible and would be useful. He also agreed that for Stack Overflow to work, students would have to all jump ship from their current platforms at the same time and migrate their communication on there. The only compromise we had to agree on was to drop the anonymous questions idea, because it would cause problems however we decide to implement it.

This approval of my system idea gave me internal peace after a long phase of uncertainty over the project. Phew!

Starting development

I finally started coding. I hadn’t started doing that beforehand because of my anxiety over the concept – I didn’t know if anyone was going to want the system I had in my head. I also didn’t know what the exact exact requirements would be.

I used my previous dummy Laravel project (as seen in Weekly Blog #2 I think) as an example and adjusted it to fit the new system. I quickly ran into things I didn’t understand or didn’t know how to do – e.g. many-to-many relationships between models. Due to the fact that I’m new to Laravel, I was doing things in a random order to accumulate enough code to get it to do something. The system actually has some complexity to it so it took me a while to get it to a semi-semi-semi-usable state where things are hooked together.

So far I’ve got it to a point where:

• users can be created (through the command line)
• modules can be created (through the command line)
• courses (instances of modules) can be created (through the command line)
• users can ask questions through the web interface!
  • and it populates the list of courses in the drop-down with the user’s modules
• courses can be viewed through the web interface, including all their questions
• questions can be viewed through the interface
  • if it isn’t answered, you can answer it
  • if it is answered, the answer is displayed

Testing

I was instructed that I actually should be doing test-driven development, aka I should be making tests before I develop the respective features. I knew that!

Kev was very helpful and he explained a lot to me about how testing works in Laravel and PHP in general. It was a lot to wrap my head around but I’ve started creating some tests and I’ve made a long long list of tests that I need to write. Wooooooooooohooooooooooooooooooo

Next week

• Make a KANBAN CHART!
• Finish my tests such that they cover my currently developed functionality
• Convert my process to test driven development from now on

See you then!

Hey everyone and welcome to your favourite blog!

This week has been pretty uneventful and honestly not my most productive week. I’ll try to pick up the pace next week and really do a lot of hands on stuff.

Selenium continued

Recap: 7000 records on Pure have a link that needs to be removed; we are only allowed to do it through the web interface. Last week I made a script that more or less does the job. I tested it on 50 records and it worked. I spoke to the relevant person and they came this Monday to see it in action. They were very impressed because it looks like a phantom that uses the internet.

Here’s what needs to happen from now on:

• Patrick needs to approve the code
• Appsman team need to confirm that we’re allowed to run Selenium on Pure
• A person from Pure needs to confirm the same thing
• The code will then be tested on the dev version of Pure where the database has been copied fairly recently
• If all goes well, it can run on the live Pure :O

After I showed the script to the person I’m making it for, I worked on cleaning it up and making it more aesthetically pleasing to the programmer.

Q&A System Planning Continued

Last week I emailed Nick Gibbins with an idea for a system which allows students to send questions to lecturers anonymously. It also allows lecturers to share their answers with everyone so that people don’t keep asking the same questions. His feedback was that the anonymity feature should be dropped. I personally am quite fond of that feature because it has no equivalent currently. So I decided to propose a system with optional anonymity. I am having a meeting with him on Monday to see what he thinks of my idea.

Here are the features I’ve settled on:

• Website linked on the module pages of the ECS Intranet
• Students can send questions to the module team regarding the module
• Students can tick a box which makes them “anonymous” i.e. hides their identity from the lecturers
• Lecturers can answer a question
• Lecturers can make an answer public which shares it with everyone on the module
• Lecturers can dismiss a question if it isn’t worth replying to
• Lecturers can report a question which temporarily bans the sender from using the system
• Lecturers can tag a previously answered question in their reply to a question
• Students can tag a previously answered question in a new question
• Students & lecturers can control what email notifications they receive

I’ve tried to achieve a balance between students and lecturers so that my system doesn’t get completely rejected by teaching staff. Here are some of my arguments as to why:

• Appealing to students because
  • It sends questions directly to lecturers, which is valuable
  • It allows anonymity, which means shy people are more likely to ask a question
  • It keeps track of all the questions that have been asked and answered in the same place
• Appealing to lecturers because
  • It allows them to share their answers with everyone so that they don’t have to answer the same question multiple times
  • Pages for modules will be set up with no action needed from lecturers
  • It isn’t truly anonymous so offensive users can be identified
  • It can be switched off entirely by the module leader

I also made a big set of interactive wireframes which I highly recommend checking out.

>>>WIREFRAMES

PRO TIP: click on the play button on the top right for immersive experience

I also started writing down the formal requirements (user stories) in a word document by following another requirements document from our team. I did the wireframes first to make it clearer for myself what I wanted to do.

Tiny bit of Laravel and mod_auth_mellon

I also watched a couple more Laracasts which were on authentication. It looks like Laravel makes it really easy to set things up.

On Wednesday, me and Kev had a meeting with Clayton who explained to us what mod_auth_mellon is and how we might use it to authenticate our users. Kev understood everything and I understood almost nothing due to my lack of prior knowledge about that stuff. Oh well! I’ll learn it as I go.

Staff Party

I was the only person from TID Web who attended the Staff Party on Wednesday. I went with a bunch of interns and we had a good time. I got two ice cream cones because the second time I was able to cut the line to where my friends were. The lines were crazy long – I guess it was hard to find a second ice cream tricycle for the occasion.

THE END – SEE YOU NEXT WEEK

Recap

Last week I did some hardcore data gathering. I interviewed 8 students and 3 lecturers to see if I should make a system for asking questions anonymously in lectures. Then I discovered Meetoo – a system already purchased by the university which does exactly everything that I was about to implement.

I figured another worthy idea was to make something like Stack Overflow but simpler and more geared towards students. Lecturers and students were fans of that idea generally, but I didn’t gather quite enough evidence that it was worth making.

At the end of the week that was pretty much the only idea I had for my project, and I wasn’t exactly sure of it either. Oh well!

This week – questioning everything

On Monday and Tuesday me and Patrick were trying to figure out what I should do. Because most of my data gathering was focused on something else, I didn’t really have enough evidence to back up any project idea, so we were questioning everything. Here are the main points that we came up with in our discussions:

• The Stack Overflow idea has been attempted before in different ways, mainly STACS Overflow, which was ECS-exclusive and was discontinued due to lack of interest from students
  • It likely won’t be successful this time around either
  • The fact that students can answer questions means that lecturers are less likely to engage with it
• Making a system for ECS students is more likely to be impactful than trying to make a system for the whole university
  • Because we can integrate it with the ECS Intranet where students will find it
  • Because I have way more ECS friends that I can interview (including interns)
• Alternative idea – questions are sent privately to the lecturer and are only posted publicly if the lecturer chooses to publicise them
  • Forces lecturers to engage
  • May fail for that reason
• Anonymity => students say mean stuff anonymously

After MUCH debate we settled on the following idea:

• Tab on the module page on secure.ecs
• Send a question to the lecturers for the module anonymously
• Lecturers can choose to:
  • answer
  • dismiss
  • report
  • if answered, they can choose to post the question & answer for everyone to see
• If a lecturer reports a student, the student receives a ban from the system
• The module leader can choose to disable the Q&A system altogether

I made a very detailed document describing this idea on Google Docs, but it seems to have been reverted to a very old version. How?? Anyway..

I emailed Nick Gibbins (Director of Programmes for Computer Science) to ask for his opinion on this idea. He had some criticisms, but generally wasn’t 100% opposed to it, to my surprise. He was more of a fan of the Stack Overflow idea, but if I have to listen to the facts, it’s been done before and it wasn’t popular, so my hands are tied. 🙁

He also proposed to drop the anonymity part, because if someone abuses the system very badly a la Professional Development snafu, they would have to be de-anonymised to face justice, which might defeat the purpose of the anonymity. I think optional anonymity (tick box) is a good option to encourage people to not be anonymous.

It seems that the idea as a whole could work. Yay!

Selenium

So there’s this problem on Pure where 7500 records point to a link which no longer exists. We aren’t allowed to fiddle with the database, so they have to be removed by hand.

I timed myself doing it by hand and it takes 20 seconds per record at the fastest. That means 38 hours in total of intense clicking.

Thankfully Selenium exists and I had explored it a little bit while working for the Quality & Test Team. As far as I’m aware, Selenium should be allowed, given that it’s the same as a super fast person clicking around.

I was given access to a sandbox version of Pure to play around in. First I made a program which creates records, because that part is even more tedious and time-consuming. I left it cooking overnight and I had ~500 records the next day. I then made a script which removes a link that partially matches a string. I tested it on 50 records and it worked flawlessly.

The only thing left to do is to modify it so it works with the live version of Pure (slightly newer) and the real records. Oh and also getting approval from the people that have given me this task.

Next week

• Meeting people who will hopefully approve my Selenium script
• Making a start on the Q&A project in Laravel
• Learning what an authentication melon is (mod_auth_mellon)

Thanks for the attention – like, comment & subscribe!

Recap

Last week was my first week as an intern. I spent most of it learning Laravel from scratch. I also planned my requirements gathering for my project, which would involve 2 focus groups with students and interviews with as many lecturers as possible. These were meant to be done this week.

My project was going to be a system for asking questions anonymously in lectures, which addresses the intimidation of raising a hand in a lecture to ask a potentially dumb question.

Focus Groups – gathering info from students

Focus Group 1

My first focus group had 3 students from archaeology, English-and-film and computer science respectively. We brought pizza as an incentive for the students to participate.

We learned the following things:

• Students are, in fact, intimidated and not likely to ask questions by raising their hand in a lecture
• Another problem is when lecturers ask students a question – students are too scared to answer for fear of being dumb
• Therefore, students would like to be able to ask or answer questions anonymously online during a lecture
• Another useful feature would be to indicate that they don’t understand at a certain point
• Paying attention in a lecture is crucial, so a distracting app might do more harm than good
• The key features that students value are anonymity and getting answers from the lecturer

The full notes of what they said can be found here, and the report (which includes their wireframes) can be found here.

Focus Group 2

The second focus group had 4 students all from computer science, all Bulgarians – it was a Bulgarian programmer pizza party.

They provided the following extra information:

• They too never ask or answer questions by raising a hand (with small exceptions)
• They agreed with all the previous points, except the below point
• They thought in-class quizzes were unfeasible because they’re extra effort for lecturers that they don’t need to put in currently
• As computer scientists, they were leaning towards a Stack Overflow style question and answer platform, where students can answer and upvote questions and answers
• They suggested that students shouldn’t be able to downvote questions, as there is no reason to discourage people from asking questions

Full notes of focus group 2, report of focus group 2

Discovering that an app like this already exists

It had been said to me by some students that an app similar to what I’m planning to make is already available on the MySouthampton app, called Meetoo. I kept that in the back of my mind with the intention of researching it later.

Well, maybe I should have researched it earlier because once I looked into it, I discovered that it had 90% of the main features people asked me about:

• People can ask questions (potentially anonymously) during a lecture
• People can upvote questions to push them to the top
• The lecturer can launch a poll with a question and people can vote anonymously on their phones
• Stats from the poll can then be displayed immediately afterwards

They even had a video on YouTube of Southampton students praising the app! Ugh!

With this in mind, I went to do my lecturer interviews with a somewhat reduced level of confidence.

Interviews – gathering opinions from lecturers

It’s not that I didn’t try to find any lecturers from outside of ECS – the 6 lecturers that I emailed just didn’t reply to me. I don’t blame them – they have no connection to this so they probably wouldn’t prioritise it over other tasks etc.

I interviewed 3 lecturers from ECS – Nick Gibbins, Kirk Martinez and Klaus-Peter Zauner. I showed them wireframes for 3 different ideas for systems:

1. A system for asking questions anonymously during lectures (like the one that already exists, sigh)
2. A system for asking questions anytime anonymously online (like Stack Overflow but simplified and mobile friendly)
3. A system which only has a button which says “I don’t understand”

All wireframes of the system can be found in the report linked at the end of this section.

The opinions were pretty consistent and can be summarised to this:

• It is hard to see how System 1 can be done in a way that’s convenient for the lecturer
• It is preferred that the students ask questions by raising a hand
• System 2 seems like a good idea if executed correctly
• It should encourage students to answer each other’s questions
• System 3 could be useful but faces some of the challenges of System 1, mainly having to adjust the lecture flow to fit it
• System 3 might put too much pressure on the lecturer & give too much control to the students that might not know what’s best for them

I could not get a definitive answer of whether System 2 is worth implementing, but the general opinion of it was positive.

The detailed report of the lecturer interviews can be found here.

Conclusions from the data gathering

• The initial idea exists and is provided by the university (Meetoo) and is satisfactory as it is
• There is some interest in the idea of anonymous questions anytime with written answers (stack overflow style)
• I’m not sure if I need with more data gathering

I’ve learned a lot but I am confused. Maybe this is what wisdom feels like.

Bonus – Accessibility workshop!

The team went to an accessibility workshop in Highfield, where they taught us some stuff about accessibility. Yay!

I learned that there are some handy guides for accessibility online, there is incoming legislation which will make it more mandatory, and that there is no way to 100% assess accessibility in an automated way, although tools exist for it.

Next week

I’m not really sure what I’ll do next week. Possibilities include:

• Another focus group with students with a focus on the stack overflow idea
• More interviews with lecturers, hopefully from outside ECS
• Writing up requirements properly
• Trying to make a Hello World in Exchange Web Services
• None of the above

Have a nice weekend!

Introduction – about me

Hi, I’m Rayna (pronounced similarly to China) and I am the new TID intern. I just finished my 2nd year studying Computer Science and I am an aspiring web developer, as demonstrated on http://bit.do/raynaslinks – the best website in the world. Last summer and through the academic year I worked for the Quality & Test Team in iSolutions, so I’ve been here for a bit.
My main project for these 12 weeks will be a system for anonymously asking questions in lectures. Other tasks of mine will include manually removing an obsolete link from thousands of records in Pure, as well as anything else my team wants me to do.

What I did in my first week

My first task was to set up Linux alongside Windows on my work laptop (because I wanted Linux). It took a few hours of mainly waiting and unsuccessful attempts at making a bootable flash drive. In the end I had a healthy new Ubuntu and unaffected Windows. Then I had to set up Laravel, which was straightforward.

I spent most of the week watching and following the official Laravel tutorials (Laracasts) to familiarise myself with Laravel. I developed some understanding of it and I was able to produce a stub of my intended project with very limited functionality.

The screenshot below shows the initial screen, where you can type in the “lecture code” (the lecture’s number in the database) and it opens the lecture’s page.

On this screen you can see the title of the lecture along with the lecture code, as well as all the questions asked so far. You can also add a question. There are no users and logins – the prototype is very simple.

I also planned my requirements gathering process (described in the next section), contacted people to participate and prepared questions to ask them & wireframes to show them to spark a conversation.

What I will do next week

Next week the requirements gathering will begin. We’re putting together a focus group on Monday with students from different disciplines (excluding ECS). The focus group will aim to capture their current experience asking questions in lectures, their experience with any existing solutions for anonymous questions, and their expectations from an ideal system with that purpose. Later in the week another focus group will (probably) happen, where ECS students will be interviewed. The reason for the separation is that ECS students tend to have loud opinions on technology which may overshadow or contrast with the views of less tech-oriented students. Some students might be asked to participate in individual interviews later in the week also.

The information gathered from students will be used as a basis for interviews with lecturers (assuming students will agree with the idea of the system). We will aim to interview lecturers from different disciplines (e.g. heath sciences + ECS + humanities) to capture a more broad set of experiences and requirements. Lecturers will also be shown wireframes and will be asked for any comments or criticisms.

On the technical side, I shall be trying to “help” my teammates with their endeavours which involve:

• Automated Testing
• Pure
• Team City

Another big task will be analysing the data from the focus groups and interviews and writing up formal requirements, as well as making wireframes of the design of the “final” system.