Waterfall Methodology

I have told you in my previous articole about existing SDLC methodologies that can be used in the software creation process.

This article is the first one in a series of articles that describe in detail the methodologies mentioned before.

I will start with Waterfall methodology, as it is one of the most common and oldest ones (actually, it was the first SDLC model to be used), being encountered in many of the existing companies. It is a pretty inflexible methodology which supposes that all the requirements are well defined before the development start. SDLC phases are followed rigurously at a low level, meaning that each phase starts after the previous one has finished completely. Testing phase usually starts after the development is finished, so the advantage of early testing is not used.

The waterfall SDLC methodology was first introduced by Winston Royce in 1970 and it  was the first public documented life cycle model. 

The waterfall methodology is divided into the following phases:

  • Requirements gathering – Define the characteristics of the product and record them into the requirements document
  • System Design – Based on the requirements, the company must study the existing resources and decide whether some new hardware is needed or some software upgrades are required
  • Implementation and Execution – After the requirements are designed and the system preconditions have been met, the product is created based on the previously created specifications
  • Testing – The testing phase follows the implementation step, and has the purpose of finding potential defects of the software and to increase confidence into the end product
  • Release – After the testing is complete, the product is released into production, meaning that it is made accessible for the use of the end user
  • Maintenance – The process in which we make sure the preconditions in which the software works are met. It could be a hardware upgrade, a software version increase or any other type of maintenance.

Advantages of Waterfall methodology

  • Easy to understand
  • Easy to use and manage
  • Works very well for short projects
  • It guarantees predictability, so you can trust the timelines with reduced possibility to exceed deadlines
  • You know ever since the beginning what to expect and how would the result will look like
  • The entire process is well documented, so any new person being assigned on the project can easily understand what the project to be developed is supposed to do

Downfalls of the Waterfall methodology

  • It is very inflexible, so changing the requirements in the middle of the development process is pretty hard
  • If you have a high amount of risk that is identified, then waterfall might not be appropriate. A risk might imply changing the requirements and, of course, the code, so that you can mitigate it.
  • Defects are only found in the testing phase, when the product is already fully developed. So, instead of creating tests for a single future or module, you create tests for the entire project, which increases the risk of missing something.
  • Working software is available late in the SDLC process, so feedback can only be provided from user when many defects already appeared
  • Usually a series of test cases is followed blindly, and most of the times the tester doesn’t try to find some other test cases. If he does, this would mean to change the test plan, test deadline, test report, depending of the new number of tests that are to be found, and sometimes additional development resources need to be included in the project
  • If a requirements change necessity is detected during the implementation, then most of the times it must be treated as a separate project

When to use Waterfall methodology

  • Short projects with a low level of complexity
  • Projects with a low level of risk
  • Projects where the requirements are very well known ever since the beginning and the probability of requirements changing is small
  • The team is experienced and knows very well the technology to be used

Why is it called waterfall? Because the project phases are performed in a linear way, and the output of one phase is the input for the next one, just like the waterfall passes some location coordinates to enter some others.

According to Wikipedia, the earliest use of the term waterfall may have been in a 1976 paper by Bell and Thayer.

If you want to learn more about the waterfall methodology, you could take a look at Software Engineering Methodologies: A Review of the Waterfall Model and ObjectOriented Approach, and of course you could check the official syllabus provided by the ISTQB official website.

I will come back with my next article about the Agile methodology.

SDLC Methodologies

In my previous article, I have told you about Software Development Life Cycle, what it is and what are the roles in an SDLC. In this article I want to tell you about the methodologies that can be used in SDLC.

Let’s start with the beginning, and talk about what a methodology is. According to the Cambridge dictionary, a methodology is a system of ways of doing, teaching, or studying something. Another definition says that a methodology is a set of methods used in a particular area of study or activity. So just to make it simple, a methodology is in my opinion a set of guidelines for studying, teaching, working or performing other activities that need to follow a plan.

In IT, methodologies are a set of strategies and approaches which define the process of developing a software, creating a proper environment for delivering the expected results in the planned timeline.

In SDLC, there are various methodologies that can be used:

  1. Waterfall
  2. V-Model
  3. Incremental
  4. RAD
  5. Agile
  6. Iterative
  7. Spiral
  8. Prototype
  9. DevOps
  10. Lean
  11. Big Bang

The most common methodologies encountered in SDLC are Waterfall and Agile, but choosing the right one depends on the type of business you have. If for some projects Agile will bring success, for others it could not be such a good idea. So choosing the right methodology is the key to the success of the project.

Things to take into account when choosing the methodology:

  • Size of the project – If the project is very large, waterfall might not be very useful, because it is pretty inflexible and hard to manage
  • The changes that might appear during the process – If often changes are forseen, then you should choose a more flexible methodology, because changing in the middle of the development process in an inflexible one implies changing documentation, timeline, and even resources, which might increase the actual costs of the project
  • Cost of the eventual delivery delays – If the results must be delivered fast, then a methodology to sustain rapidity of the results would be suitable. Otherwise you might come across to making some promises you can’t keep and lose your clients
  • The size of the team – The larger the team, the harder to manage. You should take into account assigning tasks, making sure the deadlines are met and that the plan is followed
  • The technical knowledge of the team – If you don’t choose the right methodology in this case, you risk having a product that cannot be developed. You must create the proper environment to ensure that the team has the means to study and adapt during development
  • Lessons learned from previous projects (if any) – If you have passed through some previous projects, than you should make an analysis. What brought you success, what went wrong, what should you improve?

This are some minimal information about the SDLC methodologies. I will come back with some future articles in which I will provide detailed information about each one, so stay tuned.

Software Development Life Cycle

In your career as a QA you will bump into this process every single day without even realising. What is Software Development Life Cycle? Also known as SDLC, it is the process in which a product is defined, designed, tested and launched into the production environment for the use of the end user. Better said, it is a framework defining the tasks performed at each step in the software development process

The steps of SDLC

  • Concept
  • Analysis
  • Project management
  • Business requirements design
  • Technical architecture definition
  • Technical requirements design
  • Implementation
  • Testing
  • Release
SDLC Process Schema

Detailed description of the SDLC steps

  • Concept – The concept phase is the one in which the client comes up with the idea of the product. The general expectations are discussed, as well as the necessity of it. Let’s take an example to create a better understanding of this phase. I will make use of Goodreads. Most of you who like reading are aware what this platform is and what can you do with it. Let’s suppose for the sake of argument that this platform doesn’t exist yet. You are the director of a huge publishing house (just as a supposition, I don’t have the slightest idea regarding who initiated Goodreads) and you want to have a site on which authors can publish their own works and readers can keep the count of the books they read. So you come up with the idea and proceed to the next step
  • Analysys – You talk to your editors, you decide the necessity of the platform and think that it would be a good way to keep track of all the books you have by author, genre or title, and also offer your clients quizzes, quotes, events and other information they might be interested in. After the idea has been approved by the majority of the people interested in it, the next step comes into the story.
  • Project management – It is the phase in which resources are alocated: people, applications, tools etc. Timeline of the project is defined and budget is alocated so the business has control over what to pay.
  • Business requirements design – This phase supposes that a dedicated person takes the concept and “puts it on paper” (of course they are stored on electronic devices, we don’t live in the 19th century any more, but put it on paper sounded good). So this is the phase in which the final idea starts to gain a form. The business analyst must be sure to define all the functionalities that are expected from the final plarform. Every single button, every single filtering and every single text on the page must be documented. Every single non documented requirement is a not created requirement and a not created requirement is an unhappy client.
  • Tehnical architecture definition – In this step, normally an application architect analyses the requirements and their impact over the system. It updates the system architecture schema, makes sure that technical requirements are correctly defined, but also discusses with all the people involved into the process, making sure that deadlines are met and client exectations are fulfilled. I don’t know exactly all the responsabilities that an IT architect has, as architecture is the only phase I haven’t been directly involved in. From my observations, the responsabilities of an IT architect sometimes interwine with the ones of an IT manager. Correct me if I am wrong.
  • Technical requirements design – This is the step where the project technical definition is created. So basically a technical analyst is a person that tells the developer what is needed from a technical point of view. It could be a new table in a database, a new report, a new connection between two systems or a simple data transformation. Think about the construction of a building . The owner requires a new building, the architect creates the building schema for the engineer and the engineer tells the workers how to create the rooms, how to paint the walls, where to put a door and where to leave the entrance open,where to put parquet and where to put floor tiles. So basically, a technical analyst is like that engineer.
  • Development – After the technical analysys is done, the developer takes the requirements and developes the application. In this phase, beside the direct requirements of the technical analyst, the developer must take into account also the additional needs for creating the product. They have to define the sources for the tables, create the necessary procedures, define the connections, take into account performance, security etc, and put these information together (for knowledge about tables and procedures and what are they used for, I recommend you techonthenet.com).
  • Testing – After the product/application has been developed, it must be sent to the testing team (or QA team) for review. The role of the tester is to try to pass through as many scenarios as possible. He has to think about everything that the end user might try, every situation that could cause problems and put himself into the shoes of the end user. Returning to that Goodreads platform, a tester has to make sure that he can add books, filer them by name, title, author, genre, create quotes, mark a book as read, reading or want to read and many other functions that could be tried by the end user. He is responsible with the finding of product defects and reporting them to the development team. After the testing is complete and the product is ready to use, the next final phase starts.
  • Release – Is the process of putting the application/product into the production environment. What is a production environment? It is the fancy naming of launching the product to the market. If before the release the only people having access to that product were the ones that were developing/testing it/other people in the company, after the release the final client also has access to it. And returning again to Goodreads, if John Nash, a random reader from Canada would have tried to access goodreads.com before the release, he would have received a message: “This site can’t be reached“. But after being released, John Nash would have seen the homepage of Goodreads.com and would have been able to use it, add books as an author, mark books as read and use some other functionalities that have been defined.

Are all the above steps used?

Well, it depends on the company. Generally speaking, all the above steps are used in big companies, corporations, but they can also be used in medium companies. It all depends on the structure. Sometimes the business analyst and technical analyst are one and the same person, sometimes they don’t exist and their job is done by the development team. The same thing happens with the IT architect. He is not always present in a company. Who will always exist in an SDLC are the business owners, development and testing team.

Why do we need SDLC?

Well, it is because we need some control over what happens when developing a product. If we don’t use some guidelines and don’t have some goals to reach, then everybody would do what he or she thinks and in the end we will have a product that is not working, or even worse, a product that is working but does completely other things than expected. You can find a picture with what happens many times even in a SDLC process:

This image has already become viral in the IT world, and it reflects pretty well the reality. So basically this is why we need SDLC. To make sure that image one actually coincides or it is at least close to image twelve.

When to use SDLC?

Allways. It is a useful solution for delivering the right results and have a control over the development process. It is a guideline that will help you deliver the right results in the expected time.

How to use SDLC?

There are various methodologies that can be used with SDLC like Waterfall, Agile, V-Model, Incremental etc. But I will discuss them in the next articles in more detail while leaving you read, understand and remember what I have told you in this one.

What is QA?

I will start my first blog article with an introduction to QA. As much as a QA tester might laugh at the fact that some don’t know the answer to this question, it is absolutely normal for somebody who has never interacted with this domain and never thought he or she would.

So, QA stands for Quality Assurance and is the process of testing an application, web site, game or any other product that one wants to launch for own use or sell it as an individual product to the public.

Usually the QA phase is the subsequent of development and there are dedicated people who perform this kind of task. In order to become a software tester, first of all you need to want to do so and be motivated. You can’t be a good software tester if your motivation is “I want to do this because they pay good” or “I want to do this because I can’t do something else”. I mean at the beginning might be a good motivation, but unless you start to enjoy what you are doing, you won’t be able to be a great tester. Good, yes, but not great.

QA is about searching, investigating, being patient and being willing to dig up until you find the problem, or at least until you do everything you can for it. And moreover, QA is about breaking an application into pieces and actually being glad to do it. Why? Because if you don’t, the end user will and it will be thousand times worse if he does.

People often ask me: what does it take to be a QA? Well, there are many qualities you need to have. Below you can find a graphic with what it takes to be a QA Analyst.

Source: alexsoft.com

I would add to the above graph the following:

  • patient
  • willing to novelty
  • solution driven
  • passionate
  • ambitious
  • motivated
  • team player
  • attentive to details
  • pron to constructive criticism

Probably there are more qualities, I mean there certainly are, but these are the ones that come to my mind for the moment. It sounds like a job interview, doesn’t it? Well it might, but knowing these makes you prepared for that interview you are so unpatiently wating for. Don’t worry if you don’t have all those qualities. Some can be developed throught time. And for those that cannot, there are solutions that can cover up that lack so you can enjoy a happy successful life as a Software Tester.

Do I have all those qualities? Maybe I do, maybe I don’t. I would have to ask my boss for this. My personal opinion would be that I don’t. I don’t think I am a great tester. As a matter of fact, I think that there are few actually great, amazing testers on the QA market. But I do my job and I always try to improve myself. I think this is what actually matters in the end. Nobody demands perfection. Employers usually demand from you willingness to be provoked, to search for information when you don’t know and to deliver results in time. So if this is what you are doing now, it is more than enough.

The most important thing to remember about being a QA tester is that testing can’t be learned over night. It takes practice, patience and ambition. If you wait long enough and study long enough you will get to the top of the QA members.

So, you may ask, what future brings you the Software Testing? Here is a schema I have designed for you to understand how you can grow in this field, professionally speaking.

As you can see, you can start as a Junior QA Engineer, then climb up the lader until the point where you will have to choose the direction, whether being a QA architect or a QA manager. Honestly, I haven’t seen in Romania available QA architect jobs, but it seems that the position actually exist, so if you scroll that job application and see this, you’d better know where it is actually positioned in the QA hierarchy. Whatever the path you want to choose, you will have to know that climbing up the professional lader of QA means taking on more responsabilities and working more. So you will have to think carefully before making the decision of accepting a higher role. As appealing as it would sound l and as much as it would tickle your ego, a higher position implies stress, responsability and a lot of work. It is wonderful if you can do it and be successful with it, but if you don’t, going back to a lower level might have a pretty harsh psychological impact over you. You don’t want that, so be patient. Think throughly before accepting any offer and remember that the most important thing is for you to feel good and accomplished. It matters neither other’s opinions nor demonstrating something. The only thing that matters is you.

So that being said, I will leave you play your game…pardon, prepare yourself to be a Software Engineer and hope this article brought some light for you about what Software Testing really is. I will come back with a series of articles in which I will provide a more detailed approach into testing, so keep in touch.