SQA Project: Back To Basics
What’s up?
So in my second to last semester (hopefully) of college, I took one of the most important classes in the Computer Science field, the Software Quality Assurance class (later abbrv. as the SQA class) . The name itself is pretty self-explanatory; it basically revolves around how we as developers can maintain the quality of our deliverables reasonably ‘up there‘ during and after the development process of the software.
The concept itself has already been repeated multiple times across lower level mandatory classes like the Web Development class, in which we study Test Driven Development for the first time, or the Software Engineering and the Software Engineering Project class, in which we study the theory to different kinds of Software Engineering processes/methodologies and its practical application respectively.
The project
The SQA class’ syllabus gave us a mandatory class project, in which members of the class are obligated to propose and implement (if accepted) at least 2 issues each person to a common project that will be worked on across 2 sprints (as in one of the Scrum processes). The project itself is not build from zero. Instead we are given an unpolished, and to a certain degree, unfinished software from one of our colleagues last semester’s SE projects, in the hopes of being able to ‘complete’ the shortcomings of said software.
Finding the right issues
The issues that we can propose can be anything from fixing bugs, refactoring codebases, refurbishing features, or even implementing new features that will fill the software’s hollows without changing its main purpose. I, upon the announcement of the project, actually had zero ideas as to what the software’s main idea is about. So I did what I always do when I have my hands on source codes of new projects like this, which is to start it up on my local environment and seeing it by myself. But, why didn’t I just read the README?
I usually avoid reading the README first on some projects just for the sake of surprises. But for this particular project, my reasoning was that I wanted to see what a user would see and feel upon laying their eyes on the software without having any prior knowledge about it, hence seeing flaws or defects people that understands the software may be blinded to.
Okay, after seeing the software’s landing page for the first time, my first thought was.. it was pretty simple. As a matter of fact, it was waayy too simple. I couldn’t have imagined how I’d be able to propose new issues to this software without over-complicating its purpose. There is no way they’d give us such simple project and expect us to ‘work it out’, right? After connecting some more dots, I figured that there must be something more. So I typed a random path value to the URL bar, wondering if the 404 page would give me something.
Ok that wasn’t surprising at all. Look at the list of URL sub paths offered by the app! It has tons of paths to traverse as a user without giving proper way to access them (without knowing the URL paths, of course). We can easily recognize the paths: a login page, a registration page, a dashboard for each type of user, an upload service, and many more. How can I easily access this features? That’s it! That’s the first issue!
The Navigation Bar
Ok so I wondered how the original developers fail to recognize they are missing something this basic and important. It’s like the biggest elephant in the room, and from user’s experience point of view, not having one just doesn’t make sense! The 404 page is my basis to implement this issue, as it properly lists all the path and the sub paths offered by the app, without having to manually check the source code one by one.
I realized that most path in the list are presented well in the dashboard page, so what I needed to do is only to provide links that redirects to the dashboard page and the login page to access said dashboard. There are a couple more trivial pages that doesn’t have proper access, so I listed them in the Navbar too.
Now for logged in Contributors, the navbar must be slightly different, as they can now access their dashboard and their own profile pages. They also won’t be needing the registration and the login page anymore!
As for the admins, they’d have to be able to access the administration page, so here goes!
And that’s it! No more opening up 404 page to manually enter the URL paths, and no more wondering on why the project appears too simple at glance!
The second issue
Now that I have access to all the paths, I can freely traverse to each and every one of them. I finally stumble upon the material upload page and notice it might be missing something! I wonder what it is.. But that of course will be implemented in the next sprint and will also be a material for my next blog.
For now, that is all that I have to share. Thank you for checking out this slightly long post, hope you find enjoyment while reading them!
Written as a blog review assignment for my software quality assurance class.
